But programmers are game players, and this turns work into a big video game with a leader board. Instead of making the code better, the programmers concentrate on writing lines of code or solving bugs or committing to the repository or whatever is being counted. If bug fixes are rewarded, suddenly reports of tiny bugs proliferate, along with the fixes. One gets points for reporting the bug, and the other gets points for fixing it. Or if lines of code are counted, the programmer who could solve the problem with 10 lines of code suddenly decides that 5,000 lines of code will be more flexible or feature-compliant — anything to add 5,000 lines to their total.
Measuring the productivity can actually make the code base worse by encouraging long files full of feature-rich, overly engineered code.
There is no real solution for this problem. We need to track bugs. We need to organize our workflow and coordinate the creation of the software. It's impossible to measure elegance.
Programming productivity obstacle No. 4: Prima donna developers
As far as programmers are concerned, there is only one coworker worse than a boss: the other developer who created the last iteration of the code but no longer works on the project. Just as every home contractor will disparage the skills of the last carpenter, every programmer can quickly identify the horrible, inexcusable, completely brain-dead behavior of the last generation.
This may be true, of course, but it's rarely as bad as the programmer makes it sounds. If anything, it's often not a problem caused by lack of skills. There are different styles, and they change over time. The last generation didn't have access to the same libraries that we do today. They couldn't read the latest book on best practices.
This prima donna attitude about prior programming efforts can often slow down a project. The mixture of pride and self-interest can lead programmers to throw away perfectly adequate code just so they can rebuild it "the right way."
Programming productivity obstacle No. 5: The "fix it later" mind-set, aka "technical debt"
There's never enough time in the day or days in a project plan to build what we need to build. We cut corners, patch code, and take out the virtual duct tape. A smart manager once called this "technical debt" after figuring out the bean counters understood that "debt" was something that must be paid off. Bean counters understand "debt" even if they don't understand code.
Every project has some technical debt. Sometimes it can be paid off quickly, but often the next generation shows up and finds it's starting off in a hole. They need to build what the last generation never did. It's like the national debt but not as big.
Sign up for Computerworld eNewsletters.