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

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.

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".

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.

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.

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.

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.

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...

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.

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.

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-...

Get it free here:

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

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] 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) 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.

(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

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.

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.

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.

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.

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.

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.

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.

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.

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

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

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.

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.

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.

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.

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.

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.

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?

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.

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

https://codeclimate.com/

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

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.

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