programmers productivity

It's Not About Lines of Code
By Charles Connell

Everyone wants programmers to be productive. Managers of programmers want maximum productivity -- it gets the work done faster and makes the managers look good. All other things being equal, programmers like being productive. They can get home earlier, reduce stress during the workday, and feel better about their finished products. Programming productivity is even in each country's national interest, since it advances the country's position in the worldwide software industry.

Unfortunately, the standard definitions of software productivity are incorrect. They miss the essence of software development. This article examines some of the usual definitions for programmer productivity, shows why they are wrong, and then proposes an alternate definition that accurately captures what programming is really about.

Lines of code per day -- This is the classic definition of software productivity for individual programmers. Unfortunately, as other authors have noted as well, the definition makes little sense. Imagine a programmer named Fred Fastfinger who writes 5000 lines of code, on average, each workday. Now assume Fred's code is of such poor quality that, for each day of work he does, someone else must spend five days debugging the code. Is Fred highly productive? Certainly not. What we want is many lines of good code.

Lines of correct code per day -- This definition adjusts for the problem of a programmer producing lousy code. In the above example, using the new definition, Fred's productivity becomes 833 lines/day (5000 lines, divided by one person-day to write the code plus five person-days to fix it). But even this definition is lacking. Suppose Fred cleans up his act and begins to produce 1000 lines of correct code per day by himself. Imagine his code is completely bug-free, but contains no comments at all. Is Fred productive now? Probably not. The code may be correct based on the current specification, but we know software requirements always change. The next programmer to take over Fred's code will find it impenetrable, and possibly will be forced to rewrite the code in order to add any new features. (Even Fred will likely find his code opaque in a few months.)

Lines of correct, well-documented code per day -- This definition gets closer to what we want, but something still is missing. Imagine both Fred and another programmer, Danny Designer, are given similar assignments. Fred now writes comments and he completes his program by writing 1000 lines of well-documented, correct code per day for five days. Danny also completes his assignment in five days, but he writes only 500 lines of code per day (all correct and well-documented). Who was more productive? Probably Danny. His code is shorter and simpler, and simplicity is almost always better in engineering. Danny's code probably will be easier to extend and modify, and likely will have a longer lifespan, because of its compactness.

Lines of clean, simple, correct, well-documented code per day -- This is a pretty good definition of productivity, and one many experienced, savvy technical managers would accept. There is still something about this definition though that misses what software engineers ultimately are trying to do. Imagine Fred, Danny, and a third programmer, Ingrid Insightful, are given similar assignments. Fred and Danny head right to their desks and begin writing good code. Something about the assignment bothers Ingrid however, so she decides to go outside for a walk. After a lap around the park, she buys a decaf mochaccino, sips a little, and lies down under a tree. Soon she falls asleep. A half-hour later, Ingrid wakes up with a start and realizes what bothers her about the programming assignment: this new feature is suspiciously like an existing feature. She strolls back to her desk, nods to Fred and Danny, and looks over the code base. Sure enough, the new feature she was asked to create is actually a generalization of another special-case feature.

Ingrid opens up the source code for the existing feature and begins deleting large sections of it. Before long, she has generalized the existing feature so it is simpler, more intuitive, and includes the new capabilities she was asked to add. In the process, she has reduced the code base by 2000 lines. Around 3:00, Ingrid says goodbye to Fred and Danny, and heads to her health club to work off the mochaccino.

Who was more productive on this day? Certainly Ingrid. Fred and Danny are not even finished creating their features yet. Ingrid's feature works completely, she has simplified the entire program, and the user interface is improved by reducing the apparent feature count. But note Ingrid's productivity included writing negative 2000 lines of code and spending little time in the office. While this example may seem fanciful, it is actually quite realistic. Getting away from a problem sometimes is a good way to solve it. And programmers who understand the big picture make smarter decisions, because they are able to reuse code and combine features effectively.

Ability to solve customer problems quickly -- This is the true definition of programmer productivity, and is what Ingrid accomplished in the example. I use the term customer very loosely. The customer may be a group of users in the same organization, a fighter pilot whose aircraft depends on the software, the world at large (for open source programmers), or yourself when writing a software tool. What software engineering really is about is solving problems for the people who will use the software. Any other definition of programmer productivity misses the mark.

This definition raises a difficult question though: If a programmer can be highly productive by writing a negative amount of code, how do we measure productivity for software engineers? There is no easy answer to this question, but the answer surely is not a rigid formula related to lines of code, bug counts, or face time in the office. Each of these measures has some value for some purposes, but managers should not lose site of what software engineers are doing. They are creating machines to solve human problems.

About the Author

Charles Connell is president of CHC-3 Consulting, teaches software engineering to corporate and university audiences, and writes frequently on computer topics.