Low-Productivity Programmers

The range in productivity says that some programmers are much more productive than others, which implies that we'd like to find ways to hire and retain the best programmers. But that's only half the story. In DeMarco and Lister's study, 13 of the 166 programmers in the coding war games didn't finish the project at all that's almost 10 percent of the programmers in the sample. In Curtis's study, 6 of the 60 professional programmers weren't able to complete the "simple" debugging task, again 10 percent.

What are the real-world implications of working with programmers who can't complete their work? In the studies mentioned, the results from programmers who didn't finish their assignments were excluded from the results of the study. On a real project, "excluding results" usually isn't an option, and so those programmers who can't finish would require either huge amounts of time to complete their work or someone else would have to complete their work for them. On real projects, these 10 to 1 differences in productivity might well translate into productivity vs. anti-productivity eventually someone else will have to redo the work of programmers who can't finish their assignments. In other words, having the lowest-productivity programmers work on a project actually moves it backwards.

Low productivity in itself isn't the only problem. Strained to the limits of their abilities by the coding activity itself, low productivity programmers are either not able or not willing to follow project coding conventions or design standards. They don't remove most or all of the defects from their code before they integrate it with other people's work, or before other people are affected by it. They can't estimate their work reliably because they don't know for sure whether they will even finish. Considering the absence of direct contributions to the project and the extra work created for the rest of the team, it's no exaggeration to classify these programmers as "negative productivity programmers." The study data suggests that about 10 percent of professional programmers might fall into this category. A team of seven randomly selected programmers therefore has about a 50/50 chance of including at least one negative productivity programmer.