Suggestions that the manpower devoted to development and maintenance of our products is inadequate are often greeted with the claim that one is advocating a ``human wave'' approach to software development. An image of ranks of mediocre programmers stretching off the horizon is summoned up, and contrasted against our hardy band of Stakhanovite geniuses able to achieve a greatness to which no large team can aspire.
I believe this is one of the central myths of the software business, destructive of products which must, as demanded by the market, grow to such a scale that a handful of individuals can no longer do all the work by themselves. Further, it avoids facing the issues of structuring a product and project in ways that can accommodate additional human resources, including those not immersed in every detail of the entire program.
There is no indication that the user demand for additional capabilities in products is going to abate in the near future. Forget something as complicated as CAD, where it's obvious to anybody that we've hardly scratched the surface of modeling the real world--just look at spreadsheets and word processors over the last five years, and see how they've grown to meet escalating user requirements.
Although software development methodology, improved tools, and faster machines have increased the productivity of individual programmers, it just isn't realistic to expect these advances to allow a tiny group to maintain an ever-growing product. Indeed, overwork and the necessity to stay immersed in the details of the product just to keep up may cause developers in that environment to lose sight of developments which could benefit their work, or simply lack the time to step back and implement them.
Nobody is arguing for mediocrity. It's a cheap shot to assume that the work of a larger group need be inferior in quality. By subdividing a product along functional lines and parceling out work in a manner that takes advantage of individuals' expertise rather than forcing each person on the project to learn the intimate details of every corner of the product, it may be possible to increase the net productivity of many individuals.
But regardless, in a market which expects products which are far more comprehensive than those of a few years ago, surrounded by much more support material, and closely integrated with other applications and the underlying software system, the old drag racing maxim applies: ``there's no substitute for cubic inches.'' A development team with 3500 cubic inches of neurons will, unless things are utterly screwed up, leave the lean, mean team with only 1500 in the dust and smoke, regardless of how bright the smaller team is, how many hours they work a day, and whatever the marginal efficiency and better communication they benefit from by being so few.
An ultimate determinant of how much software goes in the box as well as the quality of that software is how many man-hours were expended to create it. I believe this is a little-appreciated but important factor in the success of Japanese products. A new product launched by a Japanese company typically embodies several times the engineer-years of a comparable product from a U.S. or European company. The refinement and freedom from problems that customers have come to expect is simply a reflection of all the work that went into initial design, finding problems, and fixing them before a customer ever saw the product. Attempts to surpass the quantity and quality of a much larger team through pure cleverness and long hours seldom work outside the pages of fiction.
Learning to do things on a grander scale is part of growing up in an industry. Certainly nobody would suggest that Autodesk should try to run its business today with the staff that sufficed in 1986.
What makes us think we can develop modern software that way?
Editor: John Walker