Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

15 workplace barriers to better code

Peter Wayner | June 25, 2013
What's standing between you and the next generation of great software?

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.

 

1  2  3  4  5  6  Next Page 

Sign up for CIO Asia eNewsletters.