Mohamed E. Fayad, Mauri Laitinen, and Robert P. Ward

Software Engineering in the Small
Smaller-sized software companies are developing significant products that need effective, tailored software engineering practices. n 1968, the NATO Software Engineering Conference in Garmisch, Germany [6] initiated the concept of software engineering, identifying the problems with producing large, high-quality software applications. In 1975, De Remer [2] introduced the terms, “programming in the small” and “programming in the large” to differentiate the development characteristics of large-scale software development from detailed programming (for example, data structures and algorithms). The principal source of large-scale software at the time was development contracts issued by the U.S. Department of Defense. Since then, virtually all software engineering literature has concentrated explicitly and implicitly on the model of DoD contract software development. Since the late 1970s, the microcomputer revolution has dramatically increased the quantity of software produced, the average

I

size of programs, and the number of companies involved in software development. Much more software is produced for internal use, commercial applications, and the mass-market than for deep-pocketed government and large industry. Using the number of units sold, mass-market software dwarfs the other forms of software sales. The growth of the software industry has produced many small companies that do not do contract software, but rather compete in other areas. This gives rise to at least four significant development issues that have not been adequately addressed in software engineering literature: company size, development mode, development size, and development speed. We discuss these issues and then discuss some of the shortcomings of current software engineering thinking for small companies.

Company Size Definitions of “small” businesses vary by industry and by govern-

ment agency from 100 to 500 employees or more. These bounds are somewhat broad for our purposes. Based on census data, we define companies of 50 or fewer employees as small. According to the U.S. Census Bureau’s “1995 County Business Patterns,” using Standard Industrial Codes (SIC) to categorize business types, the vast majority of software and data processing companies fit our designation. The data in the Table shows that for companies whose primary function is developing software, those with more than 50 employees comprise only a few percent of the total. SIC categories 7371 and 7372 denote computer programming services and prepackaged software respectively. These two subcategories make up 45% of the total industry. We suspect that these figures are conservative. The American Electronics Association (AEA) [1] reports the rate of small startups has continued to grow and
115

COMMUNICATIONS OF THE ACM March 2000/Vol. 43, No. 3

the prepackaged software segment of the industry has grown dramatically. Moreover, these numbers do not include companies whose primary product is not software but have major software investments. While large companies have a greater total employment, every small software company must have at least one person versed in software development.

divert the focus from satisfying a market need. It also downplays the extensive involvement software development people have in product specification.

Development Mode Much software engineering literature implicitly assumes the contract model for software development in the sense of identifying a customer for whom the work is being done. The usual approach for noncontract software development is to name some internal department as the customer. But this doesn’t always work well. For enterprise-wide software, the customer may be every department in the company, not one well-focused group. In addition, internal development rarely uses a firm written contract to develop software where all parties freely agree to the terms and conditions. Organizations that develop prepackaged software, especially small companies, generally do not use the contract model. For small companies, survival rests on finding actual, paying customers. The idea that prepackaged software is being developed for an internal customer, usually marketing or product management, does not accurately reflect the way small companies think about product development. Using an internal surrogate “customer” requires resources and time a small company cannot afford, and it can
116

Development Speed While hype abounds about faster development, many software markets have become fiercely competitive and have demanded faster software product delivery. As a result, some new rapid development strategies have been developed [3–5]. Among the new approaches are phased development and delivery, overlapping design, development, and testing, and use of third-party components and application frameworks. These strategies have significant impact on software engineering practices Development Size While a 100,000 source line program was a significant undertaking 20 years ago, the typical shrinkwrapped software product today embodies at least that many lines of code. While it is extremely difficult to identify a cost figure, it appears that smaller groups are developing larger programs. This suggests that smaller groups need some of the software methodologies developed for large-scale projects, but they don’t need all of them. A major problem with the largescale methodologies is they do not scale down well. While contract software is no less important than it was, there are many more types and modes of development that deserve serious investigation from a software engineering standpoint. Mass-market software companies have their own set of development and mainte-

nance issues relating not only to their size but to dealing with the large volume of shipped products. For example, specialized forms of development and testing are needed for the effective distribution of maintenance and feature updates. Startup companies have development needs that are almost in a class by themselves. As we discuss, development speed is a primary concern while development for reuse may be consciously avoided. These specialized needs are combined with the challenges of framework and component integration.

How Software Engineering Overlooks Small Groups Looking at the software engineering literature, it is surprising that the organization type and size play so small a role in discussions of the development process. For example, according to the American Electronics Association, startup companies play a significant part in the booming software economy, but literature discussing the issues of startups in terms of software engineering methods or economics is virtually nonexistent. Startups are typically small companies where resources are limited, competition is fierce, and time to market is a primary driver of development. These characteristics have a number of implications for traditional software engineering concepts:
• Developing for reuse, a prominent issue in software engineering, may not be an advantage. The added cost, and especially the increased time needed to assure reusability, are less impor-

March 2000/Vol. 43, No. 3 COMMUNICATIONS OF THE ACM

tant than releasing the product. Note that reusability will be important if the company is successful. This brings up some interesting issues. Engineering for reusability in subsequent releases may cost more than usual and may require a more extensive redesign. Even so, it may be the only viable way to meet initial release requirements. While this model comes closer to Brooks’ “Plan to throw one away” recommendation, little research has been done on this issue.

zations. For example, it is usual for startup organizations to care only about the time and resources required to accomplish the goal, and the cost of software is a secondary consideration. Since there is no particular benefit to calculate cost by source line, it is not used. Again, in startups, even though reuse might play an important role if the company is successful, it has far less value than other characteristics, such as time-to-market. Although direct reuse is often not so important to startup programs, the Table 1. Breakdown of data processing • There is no historical cost benefits of using companies by number of employees. base for estimating commercially available Number of % of companies Total number Number of project costs and components and framecompanies employees in this size range of employees time. The initial works are. It is now cus48,773 65,411 1- 4 64.9 project is the most tomary to use a GUI 9,846 65.055 13.1 important, but it has 5- 9 and development envi6,724 10- 19 90,857 8.9 the most variability ronment framework. 5,392 20- 49 164,403 7.2 and the least data to When available for a 50- 99 2,348 163,607 go on. In particular, particular segment, 3.1 100- 249 estimation models components also allow 1,498 227,155 2.0 based on similar developers to focus on 250-499 387 131,779 0.5 projects are not easy the core development. 500-999 129 87,496 0.2 to apply to innovaCost over time. It is > = 1,000 75 121,7712 0.1 tive projects with true that software tends Total 75,172 1,117,475 100.00 new teams. Note that to become costlier over this situation is time. There are multiple entirely counter to the standard causes for this, but among those ished” or “beta” software is recommendations for effective most prominent are increased size shipped to customers. While software estimation. (For examand functionality, multiple hardware we may decry this latter trend, ple, see [5].) and operating system platforms, and it appears to be what many • Clear and stable requirements the requirement for backward comdevelopers do and what even are unlikely to exist. First, the patibility, which increases the analymore customers want. company must develop its own sis and testing costs. In addition, as Examples of Software requirements rather than relyproducts become more widely used, ing on even the initial specifica- Engineering Mismatches the cost and complexity of customer The following are a few examples support usually increases and the tions of a customer. Second, of other areas in which the competing products can force demand for changes and corrections the organization to make major assumptions made in software increases. Problems reported by cusengineering literature about the requirements changes during tomers must often be researched by development environment do not either development or maintenance mid-development. match actuality. • Resources are severely limited. personnel, even if the end result is Software cost considerations. Many recommended practices, that a problem is merely a misunCost per source line is not always such as having separate QA derstanding. Moreover, marketing and development teams, having meaningful in many small organicosts for prepackaged software component librarians, project managers, and such are not part of the startup’s landscape. Many elements of larger project management are not only not needed but could be detrimental. • Incremental development and release is a increasingly popular mode of development [4, 7]. This suggests that full analysis and design does not occur before the first customer shipment. In extreme cases, “unfinCOMMUNICATIONS OF THE ACM March 2000/Vol. 43, No. 3

117

increase as the product becomes more popular. Even if per-unit costs decrease, the total cost (and the risk exposure) increase. Note that in many cases, the cost of distributing corrections and updates can be extremely expensive. Also note that for a small prepackaged software company, maintenance costs are not usually borne by the customers and thus can significantly affect the company’s profitability. This reality in turn helps dictate the way software is developed. The usual life cycle discussions don’t adequately address these areas.

As we point out, the majority of software development organizations are small, but they are developing significant products that need effective software engineering practices tailored to their size and type of business. Furthermore, we assert that existing practices developed for large, contract-based systems do not serve the small organization adequately. In the next “Thinking Objectively” column we will discuss the difficulties of scaling down. c

4. Marco, I. and MacCormack, A. Developing products on Internet time. Harvard Bus. Rev. 75, 5 (Sept.–Oct. 1997). 5. McConnell, S. Rapid Development: Taming Wild Software Schedules. Microsoft Press, Redmond, Wa., 1996. 6. Naur, P. and Randell, B., Eds. Conference on Software Engineering. NATO Scientific Affairs Division, Garmsich, Germany, 1969. 7. Redmill, F. Software Projects: Evolutionary Vs. Big-Bang Delivery. John Wiley & Sons, NY, 1997.

References
1. American Electronics Assiociation. Cybernation: The Importance of the High-Technology Industry to the American Economy, 1997. 2. DeRemer, F and Kron, H. Programming in the large versus programming in the small. SIGPLAN Not. 10, 6 (Apr. 1975). 3. Fayad, M. and Laitinen, M. Transition to Object-Oriented Software Development. John Wiley & Sons, NY, 1998.

Conclusion Software engineering in the small is an important area overlooked not only by the literature but by software engineering societies and computing institutes as well.

Mohamed Fayad (fayad@cse.unl.edu) is J.D. Edwards Professor at the University of Nebraska, Lincoln. Mauri Laitinen (mdl@sierra.net) is a principal in Laitinen Consulting at Lake Tahoe, Calif. Robert P. Ward (robert.ward@ moai.com) is a program manager for Maoi, a provider of Internet commerce solutions.

© 2000 ACM 0002-0782/00/0300 $5.00

118

March 2000/Vol. 43, No. 3 COMMUNICATIONS OF THE ACM