As a sign of its increasing maturity, the software engineering community has begun to accommodate the needs of different development organizations. Organization size, customer needs, product cost, time to market, and product safety all affect the way software will be built. If it is a part of a line of products, compatibility with other products becomes a primary design issue. As our community has become more comfortable with the methods and processes required to build software, we recognize that the methods developed for large systems are not optimal for all systems. In particular, development done by small groups does not always fit into the development model originated to cope with large, contract-based software.
Software engineering originally targeted large, contract-based development for defense and industry, and the discipline has achieved significant improvement in that area. Although contract software is no less important than it was, there are so many more types and modes of development that deserve serious investigation from a software engineering standpoint.
There are three reasons to advance the study of software engineering in the small:
• changes in the industry,
• underestimates of the number of small companies, and
• the differences in small group development methods from the standard models.
Although the predicted Y2K cataclysm fizzled, even those people who hitherto hadn't paid much attention became acutely aware of how much the industrialized world relies on computers and on the software that runs them. That growing awareness of our dependence on computers forces us to recognize the importance of engineering reliable software.
The last decade has changed both the character of the software industry and the composition of the companies engaged in development. Mass market, the Internet, and game software are large industry segments, subject to intense competition. With PCs doing the complex computing tasks that once required mainframes, small companies have sprung up to create all sorts of software. Groups of six or fewer software developers now commonly create products in excess of 100,000 source lines in 18 to 24 months.
Mass-market software companies have their own set of development and maintenance issues that relate not only to their size but also to dealing with the large volume of shipped products. For example, effective distribution of maintenance and feature updates requires specialized forms of development and testing. Startup companies have development needs that are almost in a class by themselves. Development speed is a primary concern, even as development for reuse might be consciously avoided. These specialized needs combine with the challenges of framework and component integration that plays an increasing role in modern software building. Traditional software engineering has paid little attention to these industry segments that small companies often perform.
Underestimating the Number of Small Companies
The overwhelming majority of companies developing software are small—a fact that's often overlooked. According to the US Bureau of the Census 1995 County Business Patterns, almost 90% of software and data-processing companies have fewer than 50 employees. 1
The rate of small startups continues to grow, with the industry's prepackaged software segment growing especially dramatically.
We suspect that these figures are conservative. According to the American Electronics Association, the growth in software employment has increased dramatically in the last few years. 2
Because industry statistics often omit temporary workers, the growth in software-related work is greater than officially reported. Moreover, these numbers do not include companies whose primary product is not software, but who still develop software for in-house use or for sale. We expect that the 2000 census data will show an even larger shift toward small companies.
Here's the critical point: at least one person in each company should be versed in appropriate software engineering techniques. Given the preponderance of small and very small companies, we find it all the more compelling that we pay attention to their development needs.
One Size Does Not Fit All
Small groups, especially those developing mass-market and Internet software products, rarely work according to the published formal contract models. Although they are intensely interested in best practices, software engineers in small organizations find it difficult to separate the methods useful to them from the methods needed only to coordinate multiple large groups.
These differences surface in three main ways:
• Management is so richly structured in large organizations that it is difficult to adapt to the small. The specialized functions, reporting arrangements, and metrics are hard to scale down.
• Software architecture reflects organization architecture. In software engineering circles, this is known Conway's law, which states, "Organizations which design systems are constrained to produce systems which are copies of the communication structures of these organizations." 3,4
• Many methods such as inspection and testing were created to work on larger, nondistributed groups. These methods need serious reworking to adapt them to smaller groups and groups where the members are not physically colocated.
Although software professionals have known for years that large-scale systems needed the discipline of software engineering to build software that met time, cost, and performance goals, they have only recently started looking at the particular needs of different types of development. We now realize that small-scale software engineering is not just a degenerate case of large-scale software engineering but an important subfield in its own right. We trust that the articles presented here will spur further research work in the field (see the " Articles
has more than 29 years of experience in software development and software management. He was one of the founders of Autodesk, Inc., a world leader in the development of computer aided design and modeling software. At Autodesk, he held positions as director of Quality Assurance and director of Software Development. As software development director, he managed the development of the AutoCAD group of products. Previously, he held software management positions at Control Data and Information Systems Design. Currently, he has a consultancy in Lake Tahoe, California. He has written for a number of publications, including CACM and is a co-author with Mohamed Fayad of Transition to Object-Oriented Software Development, Wiley & Sons, August 1998. He is a member of ACM and IEEE Computer Society. Contact him at Laitenen Consulting, PO Box 61, Tahoe City, CA 96145; firstname.lastname@example.org.
is the J.D. Edwards Professor, Computer Science & Engineering, at the University of Nebraska, Lincoln. He received an MS and a PhD in computer science from the University of Minnesota at Minneapolis. He coauthored OO Enterprise Frameworks
and Software Stability
(John Wiley and Sons, New York). He is a senior member of the IEEE, a senior member of the IEEE Computer Society, a member of the ACM, and editorial advisor and a columnist for The Communications of the ACM
. Contact him at the Dept. of Computer Science and Eng., Univ. of Nebraska, Lincoln, Ferguson Hall, Lincoln, NE 68588-0115; email@example.com; www.cse.unl.edu/~fayad.
is director of product engineering at Ofoto.com. He has more than 15 years experience as a software engineer, primarily developing business applications. He is a member of the IEEE and the ACM. Contact him at firstname.lastname@example.org.