The product had to ship yesterday. The users are screaming about a missing feature. The boss's boss says we better get moving or else the ax will fall. Nothing ever seems to work as well as it could.
No one is happy with how quickly developers change the world, and 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 just program.
Here are 15 real-world roadblocks to programming progress, each of which is getting in the way of building the next generation of software. Our informal survey was surprisingly easy. When the developers suspected they were talking with a sympathetic ear, they poured out their complaints.
Programming productivity obstacle No. 1: Meetings
The most common complaint as to what is keeping you from your code is meetings. If the programmers are to be believed, they are all chained into dark conference rooms for weeks or even years as the bosses prattle on about minutiae. While the programmers usually blame managers for ruining the meetings, they will occasionally turn on their own and blame some other programmer for going on and on about bugs or features or architectural strategies.
While some of the complaints are foolish -- the same programmers will grouse if the bosses keep them in the dark and don't communicate -- they all flow from the difficulty of diving into the abstract world of software. A short-order chef or a barista may be able to juggle different requests, but switching the brain into the right mode for manipulating abstract algorithms often takes time. Switching back out of that space for a meeting can delay work for another hour or so.
Programming productivity obstacle No. 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?
Programming productivity obstacle No. 3: Trying to measure productivity
There's always a management team inspired by some book that says, "You can't manage what you can't measure." They start counting commits to the code repository or lines of software or bug fixes. They think that counting is measuring, and measuring must be good.
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.
Programming productivity obstacle No. 6: Nonprogrammer managers
There will always be smiling, happy folks who majored in anything except computer science involved in your programming project. Perhaps they married the boss's kid; perhaps they were in the right place at the right time. But the boss made them manager, even as they're trying to figure out the buttons on their BlackBerry. What's worse, they don't have a single ounce of Asperger's in them, so they insist on staring at your eyes throughout the meeting.
There are some programmers who 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. But others recognize that these guys just call meetings and get in the way. They can give little guidance, and the best they can offer is a bit of quality testing.
Programming productivity obstacle No. 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.
Programming productivity obstacle No. 8: Macho programmers, aka "brogrammers"
While it is always enjoyable for programmers to blame the suits and glad-handers over on the sales team for every problem and any disruption, the programmers must also admit that some of the problems can lie with themselves. Programmers are hired for their computer skills, not their people skills.
Programmers are bad at communicating, and they're not known for thinking of feelings or ego. They can latch onto some technical argument like a pitbull will lock onto a steer's leg bone. It doesn't matter if the client wants something different; the programmers get hung up on the technical arguments, and they'll still be hashing it out at the company picnic in two years.
While programmers can often filter out each other's idiosyncrasies, teams can fail when programmers knock heads. It's common for two people with different political views on, say, dynamic languages or NoSQL to end up on the same team. The decision on what is right for the project becomes a referendum on everything these programmers have held dear. Then nothing ever gets accomplished. Everything is tied up in the next battle of the 100-year war.
Programming productivity obstacle No. 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.
Programming productivity obstacle No. 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.
Programming productivity obstacle No. 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.
Programming productivity obstacle No. 12: Distraction-rich environment
One client insisted that I come into their office every day. Then they insisted that I use their PC, which could not be customized for a week. Then they didn't have any office space, so I was plopped into a converted conference room with six interns, who would spend half of their day talking about what happened the night before. The other half was devoted to figuring out what they would do that evening. While it was entertaining, I got little work done.
While sales and marketing teams can function and even thrive with some background noise, programmers often need library-like silence. The idle chatter, distracted tapping, or ringtones will snap the programmer's brain out of the abstract work zone and back into reality. Then it takes a few minutes to get the brain where it needs to be.
One developer told me he hated his new desk because it was three feet closer to the air-conditioning vent, which was, he said, incredibly loud. Three feet and it was ruining his concentration. This may be humorous, but it's true.
While many businesses indulge programmers with kinetic toys like ping-pong tables, they often forget that developers need silence to concentrate. Yet they pack the programmers into big rooms and assume this is collaborative fun.
Programming productivity obstacle No. 13: "Cultural fit"
Do you want your own office? Or do you want to be in a team room where you can shout out your questions? Do you like to start work early in the morning, or do you want to stay late?
Every team works better if the people have a similar style. The teams that can't find a common ground quickly fail. The communication never happens, and they end up working at cross-purposes.
While it's tempting to generalize and say quiet offices or bullpens are superior, it's better to leave that to the team. I've found it's great to have everyone in earshot when you're doing plenty of low-grade upkeep and building out infrastructure. If someone yells to someone else, it's not much of an interruption when you're waiting for a compiler or a build to finish. Sometimes I'll even know the answer. A general call to everyone can be very efficient.
But if I'm creating a complex algorithm with many moving parts, the interruptions, talk, and even keyboard tapping really keep me from concentrating. That's when I want my own quiet office.
Programming productivity obstacle No. 14: Clinging to legacy tech
There are 680 job listings on Dice.com with Cobol in the title out of 70,000-plus listings. That's still close to 1 percent. The defenders will say it's a great technology that still gets the job done. Why rewrite that dusty deck of punch cards just to move forward?
They have a point, but they often forget about the costs of keeping this ancient code around. Everything usually needs to be translated, often with custom code. Some of the code was written before ASCII, which means converting the input and output. The 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 with screenscraping, reformatting, and jury-rigging together systems like this, but after some time they spend more work refreshing the glue logic and less time writing new logic.
Programming productivity obstacle No. 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, like, soooo 2012 to him. He's moved past thinking of Haskell as a language, and he's back to using it for an ironic reference to "Leave It to Beaver."
The latest tools are fun to play with, but they can't be used in a respectable development shop without spending hours recoding the work you did last week. The people on the cutting edge are always tossing away entire sections of the API and rewriting them, forcing those of us downstream to rewrite our code too. I'm still cheesed off when I try to juggle Python 3.0 code with Python 2.7 code, and as things go, Python is a relatively stable code base.
In many cases, the new tools haven't been battle-hardened. Node.js, for instance, can be wicked fast, but only if you relearn all the lessons about deadlocks that lead people to create threads in the first place. There's often no free lunch, and these tools can produce wonderful results by cutting a corner. However, those shortcuts come back to haunt us.