

Ask HN: How can I prove to my coworker that his code is complex? - filipedeschamps

Currently, I think the code of my coworker really complex, but for now, this is just an opinion only.<p>Is there any metric that will transform my opinion on a proven fact?
======
bontoJR
It's a nontrivial task, I wouldn't waste too much time in trying to prove that
someone's code is complex. I tried in the past with the result of being
appointed as "lazy" or "basic" developer. I heard arguments like: "if you
think this is complex then you are not so good" or other very unnecessary
arguments.

Don't prove he's writing complex code, it would be interpreted as "being
wrong", but instead prove that you can come up with easier and cleaner
solution. Write your own, test it and then propose it to the original author,
see if he can admit that your solution is cleaner, easier to understand and
easier to handle. I did this few times with very good results on feedbacks.

~~~
DamnYuppie
This is the path that I eventually started to take as I progressed as a
developer. Most people when shown a better way are open to it as long as it
isn't presented in a manner meant to convey superiority.

~~~
bontoJR
Yes.

...and one thing that can also happen is, when discussing a secondary
solution, a third one can come up that is even better.

------
kazinator
You mean _unnecessarily_ complex, of course. That might appear self-evident,
but it is better to articulate it in situations like this.

Why is it unnecessarily complex? Is it because it is handling cases which you
think do not occur? Or is it implementing requirements that you think need not
exist (i.e. implementing a more complex, undocumented version of the
_specification_ than the one that is actually documented?) Or is it
implementing the right specification, but without an effective program design
that would reduce code and process duplication, or without the effective use
of existing code, of the programming language, of libraries and of tools?

You need a more specific argument than "your code is too complex".

------
rwallace
No. ( _I_ don't believe cyclomatic complexity is meaningful, so it's not
likely your coworker will believe it :))

The following assumes you've already politely expressed your opinion to your
coworker and he's disregarded it.

It's important to understand what you're proposing to do here. You want to
think of it in terms of fact, but what you are actually proposing to do is
start a political fight.

Now, I don't know whether you're right or wrong. I also don't know whether it
would be a good idea for you to start a political fight over the issue. I do
know three things that are relevant to this situation, however:

1\. Whether you're right and whether it's a good idea for you to start a fight
are separate questions. It's important not to assume an answer to one
automatically implies an answer to the other.

2\. It's practically never a good idea to start a fight without carefully
thinking through the costs and benefits - all of them, not just the immediate
ones - and how you plan to win it.

3\. In the modern environment, the usual outcome of a fight is that both
parties lose.

~~~
davelnewton
At the same time, if standing up for code quality implies a "fight" then there
are several issues, only one of which is the actual code quality.

CC _does_ matter, even if in a limited sense: the more that can happen in a
chunk of code, the harder it is to reason about. I guess I'd always thought
that was obvious, because it's the same way with _everything_. Dismissing it
out of hand is disingenuous.

That said, metrics matter at different times, and in different ways. Sometimes
things are just complex at the method level.

In any case, if coworker is _disregarding_ input, there's a systemic issue at
the personal level. I hope you're just using hyperbole when you say the only
course of action is a fight: that's an extreme escalation pretty early in the
process.

If the coworker _disagrees_ with the opinion, why not just have a conversation
about what both parties mean by "complex"? List the tradeoffs that are being
made (e.g., deep vs. wide) and why making or not making them makes sense.

People can discuss differences without "fighting" in any sense of the word. If
they can't, they shouldn't work together, because it's stupid and a waste of
time.

------
5h
I've come up against this many times over. When it stems from over-enthusiasm
for using recently discovered features or concepts I've reliably changed a
trend-toward-complexity by picking a small section & re-writing it in a
simpler/more elegant fashion, then proposing to the author something along the
lines of "can we make it _all_ that simple"? The subtle (or not so subtle)
creation of a challenge towards simplicity has worked well with coders near
the beginning of their career.

~~~
acjohnson55
^ This right here.

I've come to learn that the best way to make your point in any programming
debate is to go the extra mile and produce something people can see. Rhetoric
and metrics are nice, but what really makes an impact is presenting an actual
example of a refactoring.

For the original poster: Is the original code tested? What do the tests look
like? Overly complicated unit tests are an indication that things aren't well
factored. If you can present a simplification of tests along with your
simplified revision of code, that may really speak to how your solution is
better.

------
hamidpalo
You're thinking about it wrong. It's not about the complexity of code or any
measure thereof, but a simple communication issue.

Telling someone that their code is too complex can very easily be interpreted
as a personal affront, especially by more junior developers. It can very
easily communicate that they are a shitty developer and don't know what they
are doing. When that happens you will get nowhere.

In that situation, the other person feels that they have to defend themselves.
They get myopic and unable to see whatever argument you present. They simply
will not accept it, or if they do they will resent you for it.

The best way to go about it is to acknowledge their efforts and validate their
thinking. Look at why the code is the way it is, and try and understand why
it's written that way. Approach the situation not as "I am right, you are
wrong" but as "I don't understand this part, can you explain it to me." When
they explain and you think it's complex say something like "Ah, yes! That's
what I thought it did. It seemed a bit complex so I was wondering if it did
anything else. Have you considered x or y?"

The more opportunities you allow to the other person to save face, and the
more you value their efforts and work the further you will get.

------
sdegler
The simplest way is to provide an alternative implementation that is more
correct, more succinct, and is easier to read.

+1 rich hickey talk

Of course that is not the least resource intensive solution. Code reviews may
help.

~~~
k__
This.

You could talk all day and no one will listen.

What also helps in the long run are stricter coding guidelines.

When we forced stuff like early returns instead of nested ifs much of our code
just got easier to follow.

------
Sealy
How did you come to the conclusion in the first place that his code is
complex?

The answer to this question may provide your answer to your coworker.
Ultimately if its only an opinion, then you don't have much to go off...

------
jerf
To be honest, the technical aspects raised by the question pale in comparison
to the human aspects. Even from a position of authority over a coder it can be
very difficult to solve the problem of "excessively complicated" code. To
"solve" this from a peer position, unless your coworker is an extraordinarily
humble person, is going to be quite the trick. It is likely that the
cost/benefit analysis (and in engineering you are never more than a few
minutes away from a cost/benefit analysis, even here in the "fuzzy human
stuff" domain) is unlikely to work out in your favor with any sort of strong
approach. You are unlikely to experience any positive outcomes, what ones you
could are fairly minimal, and the negative outcomes (w.r.t. your employment)
are almost unbounded, including the ability to outright work your way into
losing your job.

All you can really do is write good code yourself, keep learning how to write
better code, and use this as an opportunity to learn how to deal with
complicated code because goodness knows you'll never stop encountering
overcomplicated code, unless this industry changes a lot.

If that sounds a bit defeatist... well... it's hard to express my true
feelings in text here. I've been doing this for just shy of 20 years now and
have no intention of stopping, so it's not like I'm burned out or anything.
Yet... you can not escape the fact that you shall always be working with
people whom you wish would code better. I find it helpful to remember that A:
among the set of people I really wish would code better is my past self, at
times even as recently as last week and B: there are certainly plenty of other
people who wish that I would code better, for their personal definition of
"better". In fact, I know that even as my code tends towards the "simple" side
and I find some people's overcomplicated, they consider my code oversimple. (I
mean, I'm still on my side and can defend it, but, well, insert any well-known
saying about opinions here, right?) A certain amount of zen and a certain
amount of humility is called for here in the long term, I think.

~~~
mistermann
Considering the disappointing realities of human nature and office politics, I
think your defeatist attitude is 100% the correct strategy. It may be worth
politely and discreetly trying once to make things better, but in my
experience if the individual / organization shows no interest (or just as
likely, _outright hostility_ ) to the philosophy of trying to do things
simply, the best recipe is to shut up, collect your paycheque, and constantly
look for better opportunities elsewhere.

------
grandalf
Often times people who are good at dealing with complex code become
programmers, and they themselves write complex code.

Since so many projects contain a mess of complex code, programmers like these
will always find jobs and you may end up with one as a coworker. It's not a
bad thing but ideally they have enough of an aesthetic sense about code
readability to use their powers for good.

------
grandalf
Chapter 1 of the below book is all about coupling in systems, and illustrates
how coupling leads to significantly more system complexity:

[http://www.amazon.com/Event-Based-Programming-Taking-
Events-...](http://www.amazon.com/Event-Based-Programming-Taking-Events-
Limit/dp/1590596439/ref=sr_1_1?ie=UTF8&qid=1430830310&sr=8-1&keywords=event+based+programming)

Get it free here:

[http://en.bookfi.org/s/?q=taking+events+to+the+limit&t=0](http://en.bookfi.org/s/?q=taking+events+to+the+limit&t=0)

------
kaydev
Hi all,

there are some complexity KPIs that have proven to reflect the complexity of
your source code. Code in nesting level N and the cyclomatic complexity (aka.
McCabe complexity)
[[http://en.wikipedia.org/wiki/Cyclomatic_complexity](http://en.wikipedia.org/wiki/Cyclomatic_complexity)]
are two of them.

Especially "nesting level complexity", that is the amount of code in nesting
level N+ (e.g. the amount of code in nesting level 7+), is a complexity KPI
that can reflect unnecessary complexity in your code.

However, just having the "numbers" is not enough to convince your co-workers
(I talk my own experiences here ;)). What you need is a visualization of these
complexity KPIs. I used the following online-platform
([https://tp.softwarediagnostics.com](https://tp.softwarediagnostics.com)) to
discuss issues like yours with my co-workers in an objective and transparent
manner. They provide a freemium version of the platform that lets you analyze
and visualize the nesting level complexity of your source code in a convenient
way. Maybe it can help you in the discussion with your co-workers.

------
rachbelaid
(IMHO) Complex code is difficult to test so if the code can be tested easily
without over using factory or tight coupled setup required then maybe the code
is not so complex and maybe it's just an hard problem. Writing test can help
to highlight an over complex code and an alternative code will have much
simpler tests. It's not a metric but it's probably easier to agree on clean
test

------
fsloth
Code is written for humans. I don't think there is any proven metric for
elegance.

When I was a junior dev I made a god awful complex thingamajic for basically
calling a dozens of functions with different input parameters. Our lead just
said "o god, not like this _just call the functions_ " and he was correct.

Unless you are in a senior/junior position trying to prove your colleague
wrong will likely result of him thinking you are arrogant and will make
efforts to improve things in years to come difficult.

Communication usually fails. If you say "your code is too complex" despite
your best efforts to be polite he might hear "I am an arrogant twat and just
want to put you down for the fun of it".

Some times best people lead by example. If you can write your stuff elegantly
and show it to him he may appreciate the more simple approach. Or not.

Unless it's an obvious antipattern like coupling of code and data we are, up
to a point, discussing aesthetics. Experienced programmers often grow to
appreciate simplicity if only of the categories of bugs code eliminates by
just being simple. But this takes time.

~~~
stefs
> I don't think there is any proven metric for elegance.

there is:
[http://www.osnews.com/images/comics/wtfm.jpg](http://www.osnews.com/images/comics/wtfm.jpg)

i'm not even joking.

~~~
fsloth
Oh, had forgotten about that one. Actually, I think that image is posted on a
wall at a floor in our office :)

------
dferlemann
No one wants to hear that they are wrong, even if you proved it unless you
already have their respect, or you are their boss. All programmer will hear is
that "you are not doing good enough job," but the "good" is vague and graded,
and lazy. Instead, show him how you would have done it. You know, as a
learning opportunity.

------
msellout
First you need to define what you mean by "complex" as that could refer to
many things. A useful definition for the term will be focused on informing a
decision. Why did you ask the question?

Further, definitions that rely on one or many observable phenomena are more
useful than definitions which rely on subjective experiences.

------
JoeAltmaier
Maybe you don't understand the problem she's solving? Or maybe the co-worker
designs in a way different from your comfort zone. How about trying to learn a
few new design patterns. Then that 'complex' code will become familiar.

------
an_ko
I do this by reading the code's logic aloud, and while doing so, noting the
_things that I have to remember_ to understand it. This includes things like
"what was the name of that variable", "what does this function do", "has the
parser read a comma", etc. Complex code results in larger "mental stacks",
simple code smaller ones.

This isn't really "proof", but in my experience, such a demonstration is easy
to understand and leads to constructive conversations and good results.

------
swalsh
Good code should be no more complex then the problem it's solving. Though
sometimes easy problems prove themselves to be complex. If you can think of a
simpler way to accomplish the same task while achieving the same thing,
introduce the idea.

Chances are though, you don't have time to fix it, unless its young code, and
you have some room in your schedule (which you don't, no one ever does). I'd
just make sure the code review process is fixed so we can catch it earlier.

------
nimblegorilla
Every developer has a different idea of what complex code means. Cyclomatic
complexity is one metric, but vastly different code could have the same score.
Sometimes we have to trade simplicity for flexibility, speed, or other goals.

The idea that you can prove code complexity shows that you are a newer
developer. I'm not sure what goal you want to achieve by proving someone else
wrote complex code. There are probably better ways to achieve that goal.

------
starkmike
Readability should be paramount above complexity. Write code for future you,
and future developers that will be working on the project. You might
understand the complexity now, but what about after not working on it for 6
months or more.

I don't know of any metric for code readability, but it should be as simple as
possible. Readable code is WAY better than complex code anyday. Great
programmers know this.

------
TimSchumann
Have you considered the possibility that you're asking the wrong question?

------
frou_dh
Both watch Rich Hickey's excellent presentation on the matter and establish
whether you agree on the definitions.

[http://www.infoq.com/presentations/Simple-Made-
Easy](http://www.infoq.com/presentations/Simple-Made-Easy)

------
drKarl
Yes, there's a metric for that, and it's called Cyclomatic Complexity.
Depending on the programming language there may or may not be tools to perform
an anylisis on Cyclomatic Complexity on your code. I know for Java there are
some tools.

~~~
dalke
Unfortunately the OP and possibly co-worker would need to believe that the
results of a CC analysis were meaningful. Also, some problems are irreducibly
complex.

One solution is for the OP to come up with a shorter, cleaner, better, etc.
solution. Actually _presenting_ that version to the co-worker can be
interpreted as directly confrontational ... though presenting metrics instead
would more likely be interpreted as a side-handed attack, rather than a direct
attack.

But if the OP can come up with better code, then that would answer to the OP's
own satisfaction if the co-worker's code really is overly complex. Personal
enlightenment (I tell this to myself) was all the OP was asking.

~~~
dvanduzer
A question I'm asking myself more often as I get older: What is the value of
changing somebody's mind?

To that end, rather than prove someone else's code is complex, we can
emphasize the virtues of simplicity with what _we_ do. Refactoring someone
else's code in smaller increments would be the passive aggressive middle
ground.

There are more opportunities with code that hasn't been written yet. Maybe
suggest watching this lecture as a group and then just discussing it without
any additional agenda: [http://www.infoq.com/presentations/Simple-Made-
Easy](http://www.infoq.com/presentations/Simple-Made-Easy)

~~~
spacemanmatt
Having worked a couple decades in the trade, occasionally with some very
unstable people, I have seen one suicide. I doubt it had anything to do
directly with work but it's been a reminder to be nice to people, even when
they are wrong.

------
tremols
Complexity is not a problem if something is achieved with it. That said, a
complex problem will often require a complex solution and sometimes the
simplest solution is the most appreciated, efficient or elegant.

Poor maintainability /extensibility / modularity /scalability, bad
encapsulation, abundance of side effects, spaguetti and raviolli code - among
others - are perhaps the real problem you're seeing behind your coworker's
complex design.

It is not a war that can be easily won though, you can see how in the java
ecosystem unnecessary complexity is the norm. And outside java too we see
unnecessarily complex frameworks or libraries gaining heavy traction.

------
dragonwriter
There are all kinds of complexity metrics that exist that you could use to
quantify the complexity of the code at issue, and for many of those metrics
there are also commonly-cited standards for levels of complexity that are
sources of concern.

But its still, ultimately, a matter of opinion that the particular measure and
standard are really too complex for the purpose the particular code is serving
in the particular project, so while you can get some facts, the _relevant_ bit
still boils down to a matter of opinion.

OTOH, the best proof that code is too complex is to demonstrate simpler code
that does the same thing.

------
brudgers
If it's someone else's code, there are bigger challenges in the workplace than
code complexity. The idea that it matters to whom something about the code is
proved is a symptom of them.

------
christopherslee
Software is all about tradeoffs, and there are so many ways a single problem
could be solved. What works for me is to show them an alternative way that the
code could be written.

Then you can have a practical discussion about the differences and what the
differences are. Maybe their code is complex because they are considering more
scenarios.

Sometimes, (not always), complex code is difficult to test. When I hear "the
test is hard to write", it's a small to me that the code might be too complex.

~~~
beyti
These are the ones I really agree on. 1\. If you can show an easy way, show it
to him and hope for the best for him to next time he'll pay attention to use
an easy to understand code if possible. 2\. If your company goes for testing,
show his/her code is hard to test.

Other than these aims in particular, you'll probably be ignored.

------
mkagenius
I have been on the other side of table where a coworker told me that my code
was complex.

But at doing that he appreciated the code that it worked as expected and how
quickly I made it work, he taught me that in long run though, how a complex
code would lead to various bugs.

Show him examples, show him how to refactor that and convert the same code
into a beautiful code.

So, my advice would be to give something back to the developer in case you
want him to listen to you.

------
soldergenie
Sure, you can prove it is complex by measuring cyclomatic complexity. But, the
harder part is to prove that complexity matters. (I don't think it does
myself).

Have you considered that maybe it doesn't matter? Is his code well tested,
easily maintainable, ships with few bugs, and is produced on time? If so, who
cares about complexity?

------
interdrift
You got two options :

1.Give him a better solution and prove that it can be done better 2.Let him
drown and drag you in too.

~~~
JoeAltmaier
Actually, at a paid job, you can't really redo your coworkers tasks and also
get your own done. Not being paid to do that.

~~~
interdrift
What you are saying is true, but it's still very relative since it depends on
the situation you are in.

------
piercebot
Code Climate has a scoring algorithm that looks at the quality of your code,
including its complexity.

[https://codeclimate.com/](https://codeclimate.com/)

------
btbuildem
Do you mean "too complex for what it's trying to solve?" \- you can prove that
with a simpler, cleaner solution to compare against.

------
a3n
Don't bother, it's just an argument with no useful outcome likely.

Do good work. Improve yourself. Don't worry, none of it really matters.

------
gorbachev
Ask him to change it in some meaningful way and document the struggle.

