I'm using these products simply as examples, without implied endorsements. Since discovering Squeak and inSORS, I've found quite a few other Power Programmer groups and individuals writing great code very productively. Data compressors, video codecs, security products, speech recognition technology, even developer tools are attracting Power Programmers. Few of them use the tools and methods of corporate IT, or even of large software companiesand they don't seem to be missing them a bit. Nor do they pay much attention to the codified processes and principles of software quality management, whilst still producing stable, efficient code fast and efficiently.
With developer productivity and development process effectiveness high on a lot of CIO agendas these days, I'm starting to think again about applying the practices of Power Programmers more widely. I started by going back to my original data from the Seventies and Eighties. If just a few people were writing most of the code, what did the others do? Maybe if I could just identify the right people, I could get by without the rest.
As you might imagine, things were not that simple. Very few of the people on my teams contributed nothing at all, but a lot of them didn't contribute very much. I would have gotten a few additional points of productivity by eliminating a few people who were, in effect, "defect generators"just no good at writing code.
I also discovered that although experience mattered, several of the Power Programmers were actually quite junior. And there was some work Power Programmers just wouldn't dotesting, documentation, release management and so onthat needs to get done if projects are to be commercially successful. The less accomplished programmers often ended up with in these roles.
Finally, I discovered that the results of Power Programmers correlated strongly with the ability of the project managers coordinating them. My best managers knew how to get the most out of their Power Programmers, without overtaxing the less-talented people. Project managers who went strictly by the book never got the same level of performanceand usually lost their Power Programmers pretty fast, either to other teams or to other employers. This gave my release managers a hard time. They never really knew where their best teams were on the schedule, yet these teams almost never missed a deadline. The teams that did report precisely where they were on the schedule were often late and needed frequent resource adjustments (although we never missed a release date in five years).
What can we learn from this? I'm not yet ready to suggest that we can replace the whole software development process with Power Programmers. But I am just about ready to suggest that we have gone too far in trying to normalize performance in software development, and that we may be following a blind alley as far as future capability models go. We may have simultaneously made software development so restrictive, and yet so complex, that programmers good enough to do what we need can't tolerate the methods and measures we make them use.
In some areas of software development, automation will be the right answer. But automation has its limits, and examining flexible manufacturing analogies to see where we can leverage the very real capabilities represented by Power Programmers looks like a really good idea right now.
It won't be easy. We will have to change a lot of things in corporate IT to attract and (to the extent possible) retain Power Programmers. And we'll probably have to upgrade significantly our management and measurement processes. But there are some things you just can't pull off with brute force, some problems you can't solve with average people, no matter how well trained and equipped. For these problems you need the most talented people you can find. You need to find a way to incorporate some Power Programmers.
Then sit back and watch in admiration. The results may amaze you.
John Parkinson is chief technologist for the Americas at Cap Gemini Ernst & Young. Please send comments on this story to firstname.lastname@example.org.
This article was originally published on 04-01-2003