15 Programming Productivity Killers

The product had to ship yesterday. Users are screaming about a missing feature. The boss’s boss says we better get moving or the ax will fall. Nothing ever works as well as it could.

Everyone wants the code to flow like water from a fire hose, but no one wants to give developers what they need to get the job done. The same boss who wants the job finished yesterday won’t hire more people, buy faster machines, or do any of the dozens of things that make it easier for programmers to get work done.

Here are 15 roadblocks to programming progress. Our informal survey was surprisingly easy. When the developers suspected they were talking with a sympathetic ear, they poured out their complaints.

1. Meetings

The most common complaint? Meetings. If the programmers are to be believed, they are all chained in dark conference rooms for weeks on end as bosses prattle on about minutiae. While the programmers usually blame managers for ruining meetings, they occasionally turn on their own and blame another programmer for going on and on about bugs or features or architectural strategies.

While programmers will also grouse if bosses keep them in the dark, at issue is the difficulty of diving back into the abstract world of software. A short-order chef may be able to juggle different requests, but switching the brain into the right mode for manipulating abstract algorithms takes time, and meetings can delay work for another hour or so.

2. Reply All emails

If meetings are bad, the alternative may be worse: endless emails passed around for all to see. Wading through the replies takes hours, and no one is happy with the result. Then the developers with the worse attitudes will simply say “tl;dr” with some kind of odd pride.

Some teams try banning emails for one day a week. Others get rid of them altogether. This solves the problem of overloading but at the cost of communications. Suddenly people aren’t working together. This is supposed to be good?

3. Trying to measure productivity

There’s always a management team inspired by the maxim, “You can’t manage what you can’t measure.” They start counting commits or lines of software or bug fixes. They think that counting is measuring, and measuring is good.

But programmers are game players, and productivity measurements become their leader board. Instead of making code better, they concentrate on writing lines of it or solving bugs or committing to the repository or whatever is being counted. 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.

4. Prima donna developers

As far as programmers are concerned, there’s one coworker worse than a boss: The developer who created the last iteration 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 brain-dead behavior of the last generation.

It’s rarely as bad as the programmer makes it sound. And it’s not often caused by lack of skills. There are different styles, and they change over time. The last generation didn’t have the same libraries we do today. They didn’t know our new best practices.

This prima donna attitude can slow down a project, as pride and self-interest lead programmers to throw away adequate code just to rebuild it “the right way.”

5. The ‘fix it later’ mindset, 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.

6. Nonprogrammer managers

There will always be smiling, happy folks who majored in anything except computer science involved in programming projects. Perhaps they married the boss’s kid or were in the right place at the right time. But the boss made them manager, even as they’re trying to figure out their BlackBerry.

Some programmers like these glad-handers because fooling them is easy. If you tell them the Johnson DB is failing big time, they’ll believe you and pass this ominous news up the chain. Someone has to take the flak from the upper managers. Others recognize these guys just call meetings and get in the way. They give little guidance, and the best they offer is a bit of quality testing.

7. Programmer managers

While programmers may grouse about having to interact with nonprogrammer managers, they often quietly say that managers with programming talent can be worse — sometimes much worse.

The former geniuses might decide to micromanage the project and rip out large swaths of code because they had a new vision. Or maybe they’ll prattle on about how they did the same thing in half the code back when they programmed in 8080 assembler or C or Java. In any case, they can get more obsessed with technical details than with the big picture, though they were hired to keep their eyes on the latter.

8. Macho programmers, aka ‘brogrammers’

Programmers also admit that some of the problems lie with themselves.

Programmers are often bad at communicating and are not known for thinking of feelings or ego. They can latch onto some technical argument like a pit bull will lock onto a leg bone. It doesn’t matter if the client wants something different; the programmers get hung up on the technical arguments.

Programmers can often filter out each other’s idiosyncrasies, but teams can fail when programmers knock heads. It’s common for two people with different views on, say, dynamic languages or NoSQL to end up on the same team. Decisions become referendums on everything these programmers have held dear. Nothing gets accomplished. Everything is tied up in the next battle of the 100-year war.

9. Selfish or cowboy coders

Did you just get a null pointer from his code? That’s your job to catch that. And you better think twice about passing in a zero because the self-absorbed coder doesn’t check for divide-by-zero errors. That’s your job.

The narcissist coder’s work is supercool and superfast but only because it leaves much of the bulletproofing and testing to you. That’s your job to handle the mundane chores so that it doesn’t crash.

Many teams end up finding this out too late. The blocks of code work fine during the early tests, but after someone starts pushing real data through them, everyone realized that no one was checking for problems. Oops.

10. Poor documentation

Writing documentation takes time. But we’re paid to write code. We’re often measured by the lines of code we generate. You want results. We’re just doing what you want. Don’t worry, we’ll remember it all and write it down eventually.

Sometimes there’s plenty of documentation, but it’s for a version of the code that is months or years old. Did I say that this method stores the data in the Foo table? My bad. That was two generations ago, and we haven’t had time to work through the code and fix those old notes. But we’ll get to it — honest.

11. Slavish devotion to documentation

While we’ve all experienced projects with no documentation, it’s common for projects to fail with too much verbiage and too little coding. I’ve had several people show me a shelf filled with binders and say, “They were paid by the pound for their documentation.” Reading it all would take a year.

Programmers often handle the requirement to write a comment like they handle discussing “Battlestar Galactica” or “Dr. Who.” They write endless pages filled with minute details without summarizing or getting to the point. This can be deadly in the documentation when they don’t offer much abstraction or understanding, just a regurgitation of what the code does. They’re not illuminating; they’re just transliterating the code into English.

12. Distraction-rich environment

One client insisted I come into their office and use their PC, which could not be customized for a week. They didn’t have any office space, so I was plopped into a converted conference room with six interns, who spent half their day talking about what happened the night before and the other half figuring out what they would do that evening. It was entertaining, but I got little work done.

Programmers often need library-like silence. Chatter, tapping, or ringtones snap programmers out of the abstract work zone and into reality. Then it takes minutes to get the brain where it needs to be.

Many businesses indulge programmers with kinetic toys like ping-pong tables but forget that developers need silence to concentrate.

13. ‘Cultural fit’

Every team works better if the people have a similar style. Teams that can’t find common ground quickly fail. Communication never happens, and they end up working at cross-purposes.

It’s tempting to generalize about what’s the best working environment, but it’s better to leave that to the team. Sometimes having everyone in earshot when you’re doing plenty of low-grade upkeep and building out infrastructure can help. If someone yells out a question, it’s not much of an interruption when you’re waiting for a build to finish. A general call to everyone can be very efficient.

But if you’re creating a complex algorithm with moving parts, the interruptions, talk, and even keyboard tapping can knock you off track. That’s when you want your own office.

14. Clinging to legacy tech

There are 680 job listings on Dice.com with Cobol in the title out of 70,000-plus listings. Still close to 1 percent. Defenders will say it’s a great technology that gets the job done. Why rewrite that dusty deck?

They have a point, but they often forget the cost of keeping ancient code around. Everything needs to be translated, often with custom code. Some of the code was written before ASCII, which means converting input and output. Old systems often count the blank space characters just to figure what is in the database. That’s even more conversion.

Programmers can do a great job screenscraping, reformatting, and jury-rigging systems, but after some time, they spend more work refreshing the glue logic and less time writing new logic.

15. Lust for the latest and greatest

We’ve all been in meetings with this guy. He refers to Java as something “my grandfather wrote.” Node.js is soooo 2012 to him.

The latest tools are fun to play with, but they can’t be used in a respectable development shop without hours recoding what you did last week. People on the cutting edge are always tossing away entire sections of the API and rewriting them, forcing those downstream to rewrite their code too.

In many cases, the new tools haven’t been battle-hardened. Node.js can be wicked fast, but only if you relearn lessons about deadlocks that lead people to create threads in the first place. Often, the cutting edge can produce wonderful results by cutting corners — shortcuts that come back to haunt us.