Are We Engineers or Craftspeople?
Summary: What is software engineering, and should we care? (6 printed pages)
A saleswoman and her sidekick from a systems-integration company came to see us. They told us all about their processes, quality, maturity, experience, and success, and they neatly summarized it all with the phrase, "We do software engineering." When they had gone, a row broke out.
"Software engineering is a lot of ****," opined the applications-development manager.
"Just because you can't stick to our processes," retorted the quality manager.
"We should look seriously at Agile development. They say software development is a craft," said the systems technical manager.
"Don't give me that XP ****," snapped the applications-development manager.
"If we don't have traceability, how can I build a BI system?" the data administrator asked, joining the fray.
It became quite heated. Finally, the CIO called everyone to order. "You're the architecture guy," he said, looking at me. And, therefore (I could see them thinking), you do not have any real work to do. "You find out about software engineering and report at the next staff meeting."
Let's start with a working definition. Software engineering is software development using engineering disciplines. The questions are: What are those disciplines? Do they apply to software development? And should we care?
Mechanical engineers, for instance, create engineering drawings using computer-aided design (CAD) systems. Software engineers create diagrams, use repositories, and build models. (Well, some of them do.) Do not be confused by the word model. A model is a simplified representation of a real or imaginary system; all designs are models, but no models are designs. So, is the creation of a design model engineering? In St. Paul's Cathedral in London is a model of the cathedral created for the architect Sir Christopher Wren, which he used to sell his design to the project stakeholders (as we might describe them). It is a marvelous, large wooden model of the cathedral. You can see it by clicking here. Like those created for today's software projects, the model is not what was built to be used by real people. Although it can be an important part of the discipline of engineering, a model will not keep heads dry when the rain starts to fall. Modeling, by itself, is not engineering.
Bridge-building engineers must keep their drawings, and, for many reasons, their drawings must present an accurate depiction of what is eventually built. This provides traceability from drawing to implementation. Is traceability engineering? Civil-engineering drawings have to be accurate, because they are contractual instructions to the builders; the builders are not meant to deviate from the design and, in fact, must prove they were faithful to it. Although it can be a very important part of the discipline of civil engineering, traceability will not enable an automobile to cross open water. Traceability, by itself, is not engineering.
Software development, on the other hand, is not so clear-cut a task as building bridges. A major reason for this is that programming is also an acceptable design activity. Programmers frequently take in requirements directly (for look-and-feel preferences, for instance), act on opportunities to improve performance, and are in an optimal position to uncover and correct errors in the higher-level design. In contrast, bridge builders rarely meet their customers, have fewer opportunities to test their constructs, and rarely (one hopes) uncover engineering mistakes. Many a well-run IT department maintains a respectable tradition of traceability between code, development, and production configurations.
What is rare, however, is traceability to design models and diagrams. Given the dynamic nature of software development, many people feel that maintaining such traceability is a burden that does not outweigh the benefits. While software development shares characteristics with classical engineering, such as modeling and traceability, do issues like this make them different? I believe so, and I can think of three additional reasons why.
Firstly, software automates human intention, which is dynamic, fluid, and subject to constant change by its nature. Therefore, IT applications are under constant pressure to change a great deal after their initial release, whereas the structure of a bridge changes rather little after the first vehicle crosses its span. Typically, software designs provide little guidance in defining and implementing these changes. Lacking value and utility, developers have no incentive to keep their designs updated to reflect their recent changes, so that design and implementation quickly drift apart.
Secondly, engineering designs of three-dimensional, physical systems such as bridges are as easily understood in detail as they are as a whole. It is usually easy to understand, for instance, how a particular suspension cable relates to the entire design of the bridge. I think of this cognitive facility as a "zoom" capability, and it is very useful for those who are new to a design. In particular, it helps them place the part they might want to change into context. Let's face it: Software diagrams just do not have much of a zoom capability. Software components might connect to each other along too many dimensions, and connect in ways that have no analog in our physical existence. Worse, yet, their potential connections to peers might not even be known at the time the design was crafted. Modern software-diagramming techniques are not zoom-capable.
Thirdly—and, perhaps, most importantly—people have come to distrust the accuracy of design diagrams.
The preceding discussion suggests a common equation: Engineering equals planning. D-Day in the Second World War was an impressive piece of planning, but that had nothing to do with engineering. A refining touch would be to add the notion of a software-development life cycle to the concept of planning. Would this make software development engineering? Imagine working alongside a fashion designer, planning for your next show. It would be easy to imagine a clothes-development life cycle—decide trends, brainstorm ideas, sketch selected ideas, make detailed sketch, create mock-ups, and make final article (I am inventing this, I have no idea what they do). Would this turn a fashion designer into an engineer? I do not think so.
I visited the application-development manager and asked him what he thought software engineering was. He dragged out a huge book called Software Engineer's Reference Book (edited by John A McDermid; published by Butterwork-Heinemann, 1991). The second paragraph of the introduction reads, "If software engineering is to become a true engineering discipline, it too must have an appropriate foundation in science and mathematics..." In the third paragraph: "Computer and software systems are usually modeled by discrete mathematics, and the scientific basis for the discipline include automata theory and formal language theory..." Software developers today do very little mathematics, even if they call themselves software engineers, and many of them have not even heard about automata theory. Is mathematics the key for turning software development into an engineering discipline?
Computing does have a scientific tradition of mathematical proof—proof that programs are complete and correct. The big problem is that these proofs are long-winded and hard to understand. Furthermore, to prove something, you have to show that the program implements the requirements; and, to do that, you must first recast the requirements in a formal language. This is a nontrivial step. Even when the problem is clear-cut—for instance, defining what a sort function does—the exercise is not easy. In some circumstances, it is even difficult to know where to begin. For instance, how do you express in a formal language a requirement such as: "Display a list of products on a Web page for the user to browse and, oh, by the way, can you provide a search function, too?"
Civil engineers do not prove that their designs are mathematically correct. What they do is test their designs against criteria that they know might cause failure. The list of criteria evolves over time. A famous example is the Tacoma Narrows Bridge. This suspension bridge collapsed unexpectedly in 1940 because of unanticipated wind effects. The wind on that catastrophic day was not particularly strong, but it set up a mechanical resonance in the structure. Until that time, civil engineers did not think that mechanical resonance was a problem that needed testing for; they do today. The analysis criteria for testing suspension bridges were expanded. Mathematics for engineering is a tool for testing, but not all testing requires mathematics. A wind-tunnel test is not a mathematical test of proof, although civil engineers might incidentally use mathematics to scale up their test results to the real thing.
While we are about it, what else does engineering fail to do? It does not guarantee that a thing is built to time and budget. The over-budget, past-due Channel Tunnel between England and France proves just that. The "Chunnel" engineers could not guarantee customer satisfaction. Plenty of poor car designs prove that, too.
Engineering is associated with a professional ethic that is enforced by peers, through professional societies, and through the threat of litigation. Executing due diligence is important, but it is not engineering, either. Doctors have professional bodies and live with the threat of litigation, but they are not engineers.
Engineering is not just the act of modeling. Engineering is not defined only by the characteristic of traceability. Engineering is not planning. Engineering is not dependent upon mathematical proof. Engineering does not guarantee customer satisfaction. Engineering does not exist solely as a bulwark against the threat of litigation. Modern software development even has a weak relationship with all of the aforementioned. How, then, do we define engineering? More importantly, what is software engineering?
You can design and build things without engineering; but engineering allows you to make things that are bigger, more complex, and safer than you could attempt without it. You can build a house without engineering, but you would be foolish to build a skyscraper without engineering. Engineering is the art of scale.
I believe that, of the various characteristics of engineering previously mentioned, three are salient in this definition.
Mature Engineering Disciplines Provide Design Decomposition from Top to Bottom
As discussed earlier, engineering designs of physical systems tend to be zoom-capable. Requirements that constrain any level of a design must originate from the results of the higher layers of the design and, ultimately, from the stakeholders. Engineering is not a sausage machine: One set of requirements is not fed in one end, only to expect a finished product to emerge from the other. Engineering is hierarchical and incremental, enabling the practitioners to proceed with confidence from the highest conceptual levels to implementation details.
When building a bridge, pillar-strength requirements would depend enormously on the kind of bridge being built. First-level design decisions include bridge style (arches, suspension, pontoons), location, capacity, and so on. Only after these higher-level decisions are completed are the pillar requirements investigated—size, weight, special requirements for their foundations, and so on.
In contrast, almost all software modeling is low-level modeling of implementation components; the top level is missing! I remember one project in which I had to provide the implementation for a large government system. At one point, I was presented with a logical database diagram. What I saw was a roll of paper about two feet by three, filled with little boxes and lines and almost completely incomprehensible. While I could review a particular table structure or a specific foreign-key constraint, the contextual understanding of how that table fit into the larger system remained elusive.
Mature Engineering Disciplines Use Analysis Techniques (Which Might or Might Not Be Mathematical) to Test Each Level of Design
Engineers working on the high-level design of a bridge design can calculate the load for each pillar given the high-level requirements of span, capacity, and so on. They can do this without knowing the detailed design of the pillars, and probably will do so before the pillars are designed. In fact, the results of these load calculations are probably a requirement to the lower-level detailed design of each pillar. Software designers are bad at this. Very little analysis and testing are performed until the bottom implementation layers have been constructed. Put another way, program testing tends to show that programs meet detailed specification, but cannot show that the specification itself was correct.
Mature Engineering Disciplines Have Implicit Requirements, as Well as Explicit Requirements
Implicit requirements are those that engineers automatically include as a matter of professional duty. Most of these are requirements the engineer knows more about than their sponsor. For instance, the original Tacoma Narrows Bridge showed that winds are a problem for suspension bridges. The average politician is not expected to know about this, however. Civil engineers would never allow themselves to be in a position to say, after a new bridge has collapsed, "We knew wind would be a problem, but you didn't ask us to deal with it in your requirements." These implicit requirements, which engineers have learned as the result of the experience of the generations that have come before them, are what allow them to progress with confidence in scaling their designs. Software engineers, however, still lack a useful body of historical knowledge upon which to base implicit requirements such as acceptable performance, data-loss tolerance during error recovery, privacy-protection guidelines, and so on. (What is acceptable performance? If you do not know, how can you expect a business manager to know?)
Engineering, in general, can be defined exactly. Software "engineers" may try to dispute this claim, but they would be incorrect to do so. The vagueness of software development might not be inherent to the problem of building software. Instead, it might be a reflection of the lack of historical knowledge, and innovation in technique and tool, which could yet help the discipline of software engineering to mature.
Many of the characteristics often cited as required to make software development into an engineering discipline could equally well be applied to projects that no one would consider as "engineering." These include:
- Good project management.
- Development life cycle.
- Development frameworks.
The preceding still have value and, in many situations, are essential for project success; but they help make a craft activity more disciplined, instead of turning a craft activity into engineering.
The characteristics of engineering are:
- Top-to-bottom design. In contrast, software design is almost all low-level, and it is often hard to see how the entire system works.
- All designs (high-level and detailed) are analyzed or tested to check for correctness. In contrast, software development relies almost entirely on testing the product only—in other words, the program code.
- Implicit requirements. In engineering, there are some basic requirements—such as the fact that a bridge should not fall down—that do not need to be specified by the stakeholder.
Engineering does not guarantee that development will complete on time and on budget, or be a commercial success. Furthermore, engineering is not vital for small- to medium-size development with well-understood requirements. Where engineering is missed, it is so in large, complex projects.
There are two important questions that should be applied to all levels of design, from high-level to detailed design. These are:
- How do I know that the design is correct?
- What are the implicit expectations that the stakeholders have in this system?
Observe, too, that as you move down from high level to detailed design, you accrue additional stakeholders. For instance, a stakeholder who is concerned about IT systems administration will become interested in the development only when the application architecture is complete and the technical architecture is up for discussion. Thus, an additional question for every level of design is: Who are your stakeholders?
There are numerous books about project management, frameworks, IT architecture, and software-development methodologies. As pointed out, these are not really about engineering, although many claim to be.
A more in-depth discussion of these issues can be found in the following Internet paper, which is available for free:
- Britton, Chris. "Making IT Application Design an Engineering Discipline." IT Modeller Web site. 2006. Discusses the issues of levels of design and correctness, in more detail.
Architecture frameworks—A way of organizing and clarifying the tasks associated with software development—mainly, to make sure nothing is forgotten (for instance, all viewpoints are taken into account) and work is not duplicated.
Models—A simplified representation of a real or imaginary system. All documented designs are models, but not all models are designs.
Repository—A database for holding software-design artifacts. There is an overlap between repository and configuration management tools. Broadly speaking, configuration management tools concentrate on holding artifacts that are used to define a production or systems-test system (such as program source and configuration parameters), while repositories are used to hold design artifacts for existing or future systems (such as the logical database structure and process diagrams).
SDLC (software-development life cycle)—The stages of software development, structured to allow you to see the flow from one stage to another. An example of an SDLC might be: inception, architectural design, detailed design, programming, systems test, production. The word "cycle" in the title implies iterative development.
About the author
Chris Britton, formerly of the architecture group at Unisys, is now an independent architecture consultant who spends most of his time building the modeling tool Polyphony. With Peter Bye, he has coauthored the book IT Architectures and Middleware: Strategies for Building Large, Integrated Systems, Second Edition (Addison-Wesley, 2004).
This article was published in Skyscrapr, an online resource provided by Microsoft. To learn more about architecture and the architectural perspective, please visit skyscrapr.net.