10x Software Productivity Variance – What?

This article by Larry O’Brien got me fired up…

Not because I disagree with the notion of some software developer being 10 times as “fast” delivering software as the average developer. Because that is not what productivity means. Productivity is about leverage, not speed.

An example of productivity:
A Terex TA400 articulated dumptruck has a top speed of 5 mph, and a capacity of 38 metric tons. In order for a pickup truck with 500kg (1/2 metric ton) capacity to be as “productive”, it would have to be able to deliver payload at a maximum speed of 375 miles per hour. Lets say that the pickup truck had a max loaded speed of 80mph, then the TA400 would have abou 4.6 times the productivity of the pickup. Of course this assumes peak productivity, and optimal conditions (temp, road, etc) – that is – the exercise is theoretical. My point? Productivity is not about working faster, its about tooling. Even your customers know that – otherwise they wouldn’t be paying for software…

Is software productivity measureable?
What makes matters worse, is that software developers are not dump trucks. They do not work in isolation, hauling loads from here to there. In fact, we do not even have metrics that we like to measure their output. Source lines of code (SLOC) are not a measure of software size, scope, or complexity. Function points get us closer, but are rather complex to calculate. And every software paradigm (language, pattern, etc) has a different factor in handling different types of complexity.

If I can’t measure a software developers output, how on earth can I measure his productivity (output/time)? One can neither say that the best software developers are an order of magnitude more productive or not, because we still don’t have an objective measure of output. Period.

Where does leverage come from?
The best software developers don’t just hammer out features, they understand and classify the problems, and simplify the solution through the design and construction of patterns, models, frameworks, paradigms and processes that REMOVE THE REPETITIVE WORK from the software development process. The thing is, these frameworks not only make them more productive, but they tend to make entire teams more productive. That wizard-ass software developer may not actually be able to deliver “code” that much faster than the average developer, but through his specific genius, he can make himself, and whole teams of other developers easily 10 times more productive through the development of reusable abstractions (patterns, models, and frameworks).

Where does productivity come from?
The best way to be more productive is not to find a way to do the work faster, but to get the same result with less work!

My Heroes of Software Productivity
So here is my salute to Neil Pappalardo, Martin Fowler, Erich Gamma, Adrian Holovaty, Edgar F. Codd, Kent Beck and the rest of my heroes of software development. Not only were you able to be more productive, you made the rest of us more productive as well.

No Comments

Post a Comment