The new book “Making Software,” edited by Andy Oram and Greg Wilson, is subtitled, “What really works, and why we believe it.” The book has dozens of articles on subjects as diverse as “Why is it so hard to learn to program?” to “What does 10x mean? Measuring variations in programmer productivity.”

These articles are often written by people closely connected with the question—for instance, Barry Boehm, whose research in the 1980s indicated costs rising exponentially over project time, addresses the question of whether Extreme Programming’s claim of flat costs can be justified and, if so, under what circumstances.

The book is a tremendous resource and will become a touchstone in debates about productivity for years to come. Unfortunately, with 30 chapters spread over 600 pages, there is enough substance here to sustain most any existing bias. A colleague says he found himself bookmarking half the articles to send to management and scrawling “bull!” in the margins of the other half.

At the risk of succumbing to confirmation bias myself, I was particularly interested in Steve McConnell’s chapter (“What does 10x mean?”). McConnell is the author of “Code Complete” (the best book on code construction) and the former Editor of IEEE’s “Software” magazine, and he is as credible as any on the subject of developer productivity. On the other hand, issues of individual and team productivity have been an interest of mine since my days as editor of “Computer Language,” and I’ve long felt comfortable saying that we don’t really have the data to be certain.

In articles such as “No Silver Programmers,” I’ve argued against the likelihood of “super programmers.” It is my belief that great differences in individual productivity are more a matter of incompetents staying employed (or, more generously, floundering on tasks that are forever beyond them). I think being 10x more productive than a competent professional developer is likely impossible, just as not even the greatest golf pro can finish a golf course in 10 strokes.

The reality of incompetence is, I am sad to say, a matter of simple observation. As application size increases, complexity rises non-linearly. People who have apprenticed writing programs with a dozen functions and a few score execution paths are not necessarily capable of working beyond “department level” applications. Their progress may not be just slow, but nonexistent. Are there people who are “10x as productive”? Ten times, a thousand times, a million times—you’re multiplying by zero.

Not only may they make zero progress, they may be actively counter-productive. No matter their assignment to less-complex, less-critical modules, their “contributions” to the codebase are net losses because of their integration and maintenance costs. A colleague of mine disputed this today, saying, “If you decompose the project properly, you can always break it down to the point so that everyone can contribute.” But the challenge, he acknowledged, is that the effort to decompose the problem to the point of being explicable to an untalented programmer might be close to the effort it takes to write the code!

Bad programmers are not good programmers who are slow. I once worked with an exceptionally talented programmer whose work habits were not the greatest, and then he and his wife had a child, reducing his productivity to something less than average. But what he produced was excellent and he was a worthwhile (if frustrating) member of the team. Work habits, tools, domain knowledge—all of those things can certainly affect productivity by factors of more than 100%. Multiply them out, throw in innate talent, and again it’s fairly easy to conceive of that order of magnitude difference between individuals, even having gotten rid of the incompetents.

But does that difference sustain itself over time? In a team of competent developers and with however many applicants getting by the first-level screens, what’s the distribution of productivity going to be when averaged over a half-year, a year or a career? For this question, I do not believe we have anything like sufficient data—there are too many variables and undefined terms (“what is productivity?” being a non-trivial place to start).

My personal belief is that, over time, most programmers who are competent at a given scale and domain are more alike than different in their productivity. I think that differences in productivity of “just” a factor of two or three justify whatever rock star/guru/ninja appellation you prefer.

The answer may lie somewhere within the cross-references and sometimes seemingly contradictory articles of “Making Software,” but “what really works” is not reducible to a PowerPoint slideshow (although “incremental and iterative” would fit). Even if it fails to deliver an action plan, “Making Software” is unquestionably the best book on productivity I’ve read in several years. You should certainly read it.

Larry O’Brien is a technology consultant, analyst and writer. Read his blog at www.knowing.net.