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.