Why Do So Many Developers Love Bafflingly Complex Code?

Science Daily reported on a new paper on this topic called “The Hidden Perils of Career Concerns in R&D Organizations”. The problem can be summed up like this:

  • Great developers want to demonstrate their talent, so they create highly sophisticated code that does amazingly complex things, which might not actually be what the customer needs...
  • Terrible developer want to mask their incompetence, so they create enormously obfuscated code that nobody can understand so they must be called upon to make any changes...

Well that sucks... according to the authors, both groups apparently have a strong incentive to make overly complex code! At least they do so in the majority of software development firms. I'd add a third point:

  • High maintenance developers need validation that they solved a tricky problem, so they force other developers and users to do complex configuration and initialization of their code to force them to appreciate the complexity of the problem...

They say the solution is more short-term incentives tied to the success of a project. I got not problem with that... but when it comes to code complexity, "success" cannot be determined for years after product delivery. Only after people need to patch, upgrade, and modify the solution can you really tell how successful you were.

I'm a fan of the old fixes: peer review, customer usability tests, and no code ownership. All three encourage simplicity, and discourage needless complexity.

UPDATE: Lively debate in the comments thread... so I wanted to update with my latest revelation. Great developers only write overly complex code when they don't get recognition of their talent. If they don't get verbal or monetary recognition from their manager and/or peers, they will seek out ways to prove their excellence. In other words: bafflingly complex code. They also do so because of honest mistakes: their code makes sense to them, so they believe it makes sense to others. The curse of knowledge, if you will.

So what's the ultimate solution?

  • Peer review all code for new developers: both great and not so great. The time you spend up front will more than make up for easy code maintainability in the future.
  • Have a training program in place to mentor the less skilled developers. Make sure they know they add value to the team, its just that they don't have enough experience yet to solve the tough problems.
  • Make sure your highly skilled developers get the recognition they deserve... especially if they are working on a project that is beneath their skill level.
  • Let highly skilled developers spend some spare time helping out open-source side projects, if their current task is too tedious or too simple to occupy 100% of their time. That will give them the recognition they need, and you still get your project on time.
  • Transfer ownership of code about every six months. This will ensure that code makes sense to everybody.
  • Force the developers to watch people try to use their solutions. In silence. Let them see hard proof how tough their systems are to use, maintain, or customize, to encourage them to solve the usability problem as well.

This post is already too long... I may expand on this at a later date.


I agree about the "no code"

I agree about the "no code" ownership, especially for open source. And when I see code from other people I want them to write as simple as possible, so i have to spend as few time as needed to fix up something / change it


good developers love bafflingly simple code, if your code is bafflingly complex then you are doing it wrong.

I came here to say that

I view myself as an engineer, and the goal of any good engineer is to solve complex problems with simple solutions. Any problem can be reduced, and most solutions can be refactored.

I've been writing code for 25 years, and when I think about some of the stuff I wrote in my younger years I cringe. I wrote complex code out of ignorance, not brilliance. Today, when I see complex code I really wonder if the author knows what they are doing.

Keep It Simple, Stupid.

Interesting topic but I

Interesting topic but I disagree with the premise. I believe most of the good developers I know prefer simpler code.

Terrible developers don't write "enormously obfuscated code" to mask their incompetence. They do so unintentionally, because of their incompetence.

don't mistake "great developer" with "enlightened developer"

I know plenty of great developers who aren't enlightened... those are the guys who know instantly how to do anything in code, but don't realize how obfuscated their solutions are.

The problem is called the curse of knowledge. Its not that they try to make their code hard to grok, it that they understand it perfectly well... and so expect other to do so as well.

I blame a lack of empathy...


Unless you enjoy the harsh sound of your toes being pounded on by a 25-inches sledgehammer, then you'd also fall under the category of developers who love complex code. Seriously? I'd take simple, easy-to-maintain code any day of the week!


Its obvious to the creator...

but not always to the next guy.

What's the old rule... any code you wrote that is more than 6 months old, might as well have been written by somebody else.

So, an enlightened developer should always code for "the next guy."

But obviously, that's easier said than done. Especially if you have a deadline.

The solution should be as simple as possible but no simpler

Without knowing the requirements, how do you judge? Great developers are probably solving a more complex problem -- because they see the 10% of cases where the simplistic solution will fail. Everyone else finds solving the 80% case hard enough, they discount the rest.

What's better? A cheap and cheerful solution that seems to work until it doesn't, or a more complex solution that just works? I used to think the latter.

Couldn't agree more.

I couldn't agree more with you about some developers not seeing the whole problem, and so they don't code to prevent it. As long as it works good in their tests, they're happy and send it off to the client. Making something that you can trust won't break is what developers should really be doing. It's technically what they get paid for. Not making their code look pretty and be understandable by the Jr. developers...


Great developers do not want to demonstrate their talent, show-offs and incompetent people who think they are geniuses do.
I agree on terrible developer code masking, that's a sad truth.

Complexity is also sign of poor execution

There's a great blog post about the 10 traits of a rockstar software engineer.


"Instead of spending weeks designing complex, unnecessary infrastructure and libraries, a good engineer should ask: What is the simplest path to solving the problem at hand?"

A bad developer can't solve problems, a good developer can implement a complex solution, but a great developer can solve a complex problems in a simple fashion.

I didn't have time to write a short letter, so I wrote a long one instead. - Mark Twain

defining great...

In the article, I was using 'great' to mean a developer who could write complex code. Tomas sez:

Great developers do not want to demonstrate their talent, show-offs and incompetent people who think they are geniuses do.

Depends... everybody wants recognition for hard work. Its a human trait. If you're a great developer, and you don't feel the need to demonstrate your talent, then you're probably working on a good team...

In other words, your manager and team gives you the recognition you need, so you don't feel obligated to demonstrate.

Now... on a typical dysfunctional team, your manager has no clue what the difference is between good code and bad code... so great developer will feel the need to write complex code.

the author of a stellent

the author of a stellent book is complaining about wasted complexity? hah.


You're saying the book is overly complex, or the software is overly complex?

Either way, what insight would you give as to the reason for the complexity?

the secretary test

I love the last suggestion: "Force the developers to watch people try to use their solutions."

I'd love to be there if said people are their bosses' secretaries. How many painful-to-use code with illegible documentation could have been prevented if the Secretary Test is part of the SDLC. *LOL*

and its very cheap...

all you need is a half dozen guinea pigs, and a camcorder. It works wonders.

AJAX in new SiteStudio

I'm quite amazed with the verbose AJAX rubbish in the SiteStudio upgrade. It performs terribly slow!

I've seen that sometimes...

Its only slow in certain networks, and I haven't tracked down why yet. In demos and on my workstation, its pretty snappy.

You might want to install a HTTP packet sniffer, and see what the heck is going on, then send the output to Oracle support.

Keep things simple!

Skilled coders need to be recognized but at the same time be told that coding is to simplify things and not to unnecessarily complicate them. There are places where complex coding is needed to get better end results but not always.

Nice post

Brian those are nice solutions to decrease complexity in code.

I like the last one . . .

"Force the developers to watch people try to use their solutions. In silence. Let them see hard proof how tough their systems are to use, maintain, or customize, to encourage them to solve the usability problem as well.

Most people aren't great developers...

Ignoring the complex code theme and focusing in on code ownership:
Most people aren't great developers.
And that's why I don't agree with the "no code ownership".
As an ideal, fine, no problem, I wish.
If you were surrounded by great developers, there'd be no problem with no code ownership (plus you'd learn lots of great stuff from them).
In practice, most developers can't be trusted to do the right thing over the quick hack and the solution is code ownership.

last line...

I'm assuming you meant this:

In practice, most developers can't be trusted to do the right thing over the quick hack and the solution is no code ownership.

I agree, no code ownership is one good way to force your team to communicate clearly about what they are doing and why. Specifications are always off, and documentation is always playing catch-up, so there will always be gaps when trying to communicate "what's in the code." Lack of code ownership is a good way to keep the churn going.

However... that also means you'll need to be able to have some kind of standardized way of changing "other people's code," so you don't run afoul of conway's law

The reason is simple - people

The reason is simple - people need to feed somehow their unwarranted self-importance.
But overly complex code is just a first stage. The second stage is when developer spends days to simplify already working code an forgets about goal of his job altogether.

Pharmacie en ligne

Notre pharmacie travaille en ligne, en acceptant les commandes des clients en régime de 24 heures sur 24. Vous pouvez faire la commande même la nuit, étant entièrement assuré à ce que déjà le matin la demande sera travaillée. Nous comprenons que la livraison des médicaments doit être assurée le plus vite possible, en effet, une souvent telle commande est faite par ceux qui est malade et a besoin des préparations médicinales notamment aujourd'hui, et non dans quelques jours. À la base de notre travail est le soin de nos clients et l'assistance dans leur lutte avec la maladie ou l'indisposition. Avec l'aide de la livraison des médicaments vous pourrez ne pas vous inquiéter, où acquérir la préparation nécessaire médicinale. En outre la rapidité d'intervention de l'exécution des demandes se rapporte à un des avantages clés concurrentiels http://veille-pharmaceutique.com/



Recent comments