For novel ideas about building embedded systems (both hardware and firmware), join the 27,000+ engineers who subscribe to The Embedded Muse, a free biweekly newsletter. The Muse has no hype and no vendor PR. It takes just a few seconds (just enter your email, which is shared with absolutely no one) to subscribe.
By Jack Ganssle
The April 1 issue of CIO Insight has an interesting opinion piece by John Parkinson. Parkinson has collected years of productivity data that shows 75 percent of his company's delivered code came from just 5 percent of the programmers. 100% of the best code - that having the fewest defects - came from the same highly-effective developers.
This isn't new news; the legend of the superprogrammer is almost as old as the computer itself. In my career I've worked with developers of all stripes and capabilities, from total losers who survived just a short time on the job to a few that surely deserved the superprogrammer moniker.
DeMarco and Lister showed that teams can act like superprogrammers; their classic book Peopleware (a must-read) demonstrated that simply taming interruptions can triple developer productivity.
Parkinson admits he later lost sight of the superprogrammer elite as he found it easier to use tools and processes to improve the average programmer's productivity a bit, than to chase down the rare and elusive miracle worker. Further, these folks tend not to stick around for along time, making it even harder to build a functional organization around them.
I wonder, though, if Parkinson's loss of the superprogrammer stems more from the changing nature of products than from an inability to recruit and hang on to these folks. His data comes from projects built 20 years ago when software was small. Times have changed; projects today are huge, often comprising millions of lines of code. Old timers remember when the PC's 640k RAM limit seemed infinite. Older timers might chuckle at the memory that the 8080's 64k address space was originally viewed as far bigger than any real embedded project could use.
Caper Jones, in an unpublished 1977 study for IBM, found that the very best developers are much more productive than the worst programmer. when working on small projects. The best developer will complete a 1k line of code (LOC) effort 6 times faster than the lousiest. The productivity delta falls to 2x on a 64k LOC project. Beyond a few hundred thousand LOC both sorts of people perform equally well. Or equally poorly.
Jones' data meshes with common sense. A single person can completely build a small project. The superprogrammer employs his or her arcane art and techniques in a blitzkrieg development effort that requires no interaction with lesser peers. As projects grow in size, more people are needed, memos, meetings and mail eat into the work day, and the personal interaction eschewed by so many of the best developers becomes as important as raw programming ability.
So superprogrammers aren't all that valuable, unless one is wise enough to use them exclusively on small jobs. That never happens. In my travels as an embedded lecturer and gadfly I see a universal pattern that puts the best people on the toughest - read biggest - projects. Neglecting Caper Jones' data and the evidence of their own disastrous development efforts managers thus manage to make everybody equally ineffective.
But one thing is certain - most of us consider ourselves either superprogrammers or well above the mean. I'm told surgeons have egos that fill an operating theater. Trial lawyers, too, seem to have an astonishingly inflated sense of self. Engineers fit the same mold. We're driven in large part by our desire to solve problems, and our sure knowledge that we're smart enough to do so. Take the poll; I bet that most of us rate ourselves way above average.
I know I'll vote myself at the top. all evidence to the contrary.