In Nate Westheimer’s post about Hackers & The Canon of Consumer Facing Products, he notes that successful software seems to often originate with a single developer who was most acutely facing a need.
There will be exceptions, obviously. (Sometimes luck and resources converge just so.) As a developer who has worked on my own projects, though, some of the reasons for this effect are very clear. Many of the practices in software development are simply attempts at replicating the results of a single developer driven by personal necessity to solve a problem.
This includes principles under the lean or agile umbrellas. User-centered design, customer development, personas/scenarios, “dogfooding,” are all strategies for helping focus the product on the most critical user needs. They’re processes that serve as a proxy for actually being the user. Think of the practice of writing specs for software; it’s just an imperfect communication of user needs from those with the understanding to those with the capacity to implement it. All of this falls away if there is a single developer-user.
As the developer-user, I’m more likely to address the issues that hampered my product’s usefulness to me that same day, no matter what they were. I’d learn a completely new technology or set of skills if necessary. As a non-user, to some degree I’d be drawn to the work that was most interesting, glamorous, or familiar.
And finally, I think part of the effect is simply due to there being a single implementer. Fred Brooks long ago talked about how an individual can organize and prioritize the information that goes into a software product better than any team. His proposal of “the surgical team” aimed to replicate this effect for even large projects, by arranging a team so as to maximally leverage a single “surgeon.” The single developer, in his view, is the ideal in which there are no cross-purposes and no communication bottlenecks.
P.S. Fred Brooks also talks about the huge productivity differences between programmers. Joel Spolsky and others have followed up with attempts at quantifying the difference. Suffice it to say that the best developers can be much more effective than the “average.” But maybe it’s not just a function of the developer. Maybe the right inspiration–or pressing product need–can trigger more valuable work from any developer.