Beyond the Buzzword

Some people think that "software engineering" is just a buzzword that means the same thing as "computer programming." Admittedly, "software engineering" has been misused. But a term can be abused and still have a legitimate meaning.

The dictionary definition of "engineering" is the application of scientific and mathematical principles toward practical ends. That is what most programmers try to do. We apply scientifically developed and mathematically defined algorithms, functional design methods, quality-assurance methods, and other practices to develop software products and services. As David Parnas points out, in other technical fields the engineering professions were invented and given legal standing so that customers could know who was qualified to build technical products.^[2] Software customers deserve no less.

Some people think that treating software development as engineering means we'll all have to use formal methods writing programs as mathematical proofs. Common sense and experience tell us that that is overkill for many projects. Others object that commercial software is too dependent on changing market conditions to permit careful, time-consuming engineering.

These objections are based upon a narrow and mistaken idea of engineering. Engineering is the application of scientific principles toward practical ends. If the engineering isn't practical, it's bad engineering. Trying to apply formal methods to all software projects is as bad an idea as trying to apply code-and-fix development to all projects.

Treating software as engineering makes clearer the idea that different development goals are appropriate for different projects. When a building is designed, the construction materials must suit the building's purpose. I can build a large equipment shed to store farming vehicles from thin, uninsulated sheet metal. I wouldn't build a house the same way. But even though the house is sturdier and warmer, we wouldn't refer to the shed as being inferior to the house in any way. The shed has been designed appropriately for its intended purpose. If it had been built the same way as a house, we might even criticize it for being "over-engineered" a judgment that the designers wasted resources in building it and that it actually isn't well engineered.

In software, a well-run project can be managed to meet any of the following product objectives:

• Minimal defects

• Maximum user satisfaction

• Minimal response time

• Good maintainability

• Good extendibility

• High robustness

• High correctness

Each software project team should define the relative importance of each characteristic explicitly, and then the project team should conduct the project in a way that achieves its objectives.

Software projects are different from engineering projects that use physical materials. In other kinds of engineering, the cost of materials can contribute 50 percent or more of the total project cost. Some engineering companies report that they automatically regard projects with labor constituting more than 50 percent of project cost as high risk.^[3] On a typical software project, labor costs can contribute almost 100 percent of the total project cost. Most engineering projects focus on optimizing product goals; design costs are relatively insignificant. Because labor cost makes up such a large part of total lifetime software costs, software projects need to focus more on optimizing project goals than other kinds of engineering do. So, in addition to working toward product objectives, a software team might also work to achieve any of the following project objectives:

• Short schedule

• Predictable delivery date

• Low cost

• Small team size

• Flexibility to make mid-project feature-set changes

Each software project must strike a balance among various project and product goals. We don't want to pay $5,000 for a word processor, nor do we want one that crashes every 15 minutes.

Which of these specific product and project characteristics a project team emphasizes does not determine whether a project is a true "software engineering" project. Some projects need to produce software with minimal defects and near-perfect correctness software for medical equipment, avionics, anti-lock brakes, and so on. Most people would agree that these projects are an appropriate domain for full-blown software engineering. Other projects need to deliver their software with adequate reliability but with low costs and short schedules. Are these properly the domain of software engineering? One informal definition of engineering is "doing for a dime what anyone can do for a dollar." Lots of software projects today are doing for a dollar what any good software engineer could do for a dime. Economical development is also the domain of software engineering.

Today's pervasive reliance on code-and-fix development and the cost and schedule overruns that go with it is not the result of a software engineering calculation, but of too little education and training in software engineering practices.