Context:
Rapid growth is not anticipated after the first release
Forces:
Some select individuals are able to build entire projects by themselves.
Organization size affects the deliverable non-linearly. Communication overhead g oes up as the square of the size, which means that the organization becomes less cohesive as the square of the size while the "horsepower" of the organization goes up only linearly.
Solution:
Do the entire design and implementation with one or two people.
Resulting Context:
An organization limited to small developments. Though there is a singleton development role, other roles may be necessary to support marketing, toolsmithing, and other functions. The productiv ity of a suitably chosen singleton developer is enough to handle sizable projects; here, we establish 25KSLOC as a limit, but see the rationale below for further parameters.
The pattern is not "License to Hack". Don't give up technical review, validation,and verification at appropriate times in development (Review the Architecture, Engage Customers).
This approach is rarely applicable, as it doesn't resolve some of the forces (many of them applicable) mentioned in Size the Organization. Where those forces don't apply, this pattern is a big win.
Design Rationale:
There are numerous examples of successful single-person developments. The dynamics of this development are different from those for a small team. The productivity of a single individual can be higher than a collection of several productive individuals. We have seen single-person developments generate 25KSLOC of deliverable code in 4 months (a craft interface for a telecommunication system); two-person developments do 135 KSLOC in 30 months. Many of these adhered faithfully to all stipulated reviews and verification steps.
Success, of course, depends on choosing the right person. Boehm notes a 20-fold spread between the least and most effective developers. A telecommunications developer recently told me that "having the right expertise means the difference between being able to solve a problem in a half hour, and never being able to solve the problem at all."
This pattern reduces the "truck number" of the organization (the number of people whose absence would threaten the organization were any one of them hit by a truck).
Next: Size the Schedule