Stops, Not Speed, Determine Programming Velocity
Have you had the experience where you estimated the travel time from A to B, in say, 30 minutes, traveled all but one mile in 25 minutes, felt pleased about it and then got stuck in multiple red lights in that last mile and reached your destination 10 minutes late? You might shave a few minutes off driving real fast on the highway, but what really saves time is if you can avoid stopping (or getting caught for speeding!)
I sometimes see a lot of energy being spent by people in advocating faster typing speeds for programmers. You also see programmers spending time learning all kinds of keyboard shortcuts or getting programming tools that allow you to launch some action in one step instead of two. These are all good things to do and it is nice to have programmers be as fast as they can while they are programming. But it should also be evaluated in the context of how much time the programmer actually spends writing code.
An answer on StackOverflow estimates (based on data from Ohloh) that 1 person year corresponds to 4000 lines of code per year. Assuming 40 working weeks (just to be extremely liberal), that translates to 100 lines of code per week, 20 lines per day or 3 lines per hour! You can go to Ohloh and try other projects. The Mozilla Firefox project has 5.3 million lines of code with 1400 contributors. That is less than 4000 lines of code per person over several years. Of course, that is an average, and some people will be much more productive than others. But the point remains.
How much time do you spend writing code? In practice, that time is circumscribed by time in other coding activities such as writing and executing tests, debugging and fixing bugs, refactoring the code, making the code more performant. Some issues or bugs can consume several minutes or hours, especially if it is related to system software. For example, the recent release of JQuery 1.6 had major breaking changes that affected programmers who upgraded to take advantage of performance gains without reading the fine print. Suddenly things stop working mysteriously and searching on Google doesn’t help either.
A focus on reducing the “downtime” for programming will serve to improve programmer productivity. For example:
- Minimize requirements changes: Do “better” analysis upfront, get prototypes and early releases faster to customers, control changes, manage backlogs and so on.
- Improve code quality: The point to remember that it is way easier to avoid putting the bug in than removing it later. Use all techniques at your disposal as well as train yourself to write better code.
- Avoid interruptions: Meetings, phone calls, emails, instant messaging, etc. are all time killers. I don’t deny that tools like Twitter are invaluable at times, but they can be distracting.
It is as important, if not more important, to reduce the time spent in non-productive activities as it is to reduce the per-line cost of programming.
P.S. I know that Lines of Code is a bad indicator of programming effort which is actually my point. You want to write fewer lines of code and there, speed of typing in code is less important than the ability to refactor code.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)