I have twice reported on the mismatch between our use of the term software engineering and the practice of engineering.[2] As part of and following those reports, I have been researching the question of what "engineering" consists of in practice, where we went wrong with our interpretation of the phrase software engineering, and how we can put software engineering back on a solid footing. This section contains what I have learned so far.
Where the Term Came FromThe term "software engineering" was coined in 1968, at the NATO Conference on Software Engineering. It is fascinating to read the verbatim reports of that conference and compare what those attendees were saying with what we have created since then. The first thing to note is that the conference organizers did not deduce that software development was like engineering. Rather, they were deliberately being provocative in coining the term "software engineering." We read in the introductory note, "BACKGROUND OF CONFERENCE" (Naur 1968, p. 8):
Where We Went WrongThe second interesting thing to note in those proceedings is the mismatch between what they claimed engineering consists of and how they described their own methods and recommendations for developing software. For example, they make the following false comparison (Naur 1968, p. 12):
In fact, the Wright Brothers practiced engineering in its best possible sense: They used theory, experimentation, guesses, and feedback. The Wrights' account (Wright 1953, pp.1518) reads as follows:
But engineering is more than just calculating tables. It consists of interacting with a material (air, in the Wright Brothers' case). The activity, "doing engineering," is learning the qualities of the material and devising (inventing) ways to accomplish what one wants with the material. There are almost always conflicts, so a perfect solution is seldom available. Finding a solution that works adequately in a particular situation requires reframing the problem over and over as more is learned about the material, the problem, and the set of possible solutions. Donald Schön, a professor at MIT, refers to this constant reframing as having a "reflective conversation with the situation." In The Reflective Practitioner (Schön 1983), he catalogs, among others, chemical engineers tackling a new problem. These chemical engineering graduate students were asked to create a manufacturing process to replicate a particular patina on china that came from the use of cow bone, which would soon become unavailable. The students progressed through three stages in their work:
Their third stage shows their reflective conversation with the situation. As they learned more about the problem and the solution, they were able to make better moves in their game. Schön's account meshes perfectly with Pelle Ehn's description of software design as a language game (see Appendix B):
Engineering, then, proceeds as a cooperative game of invention and communication, in which the moves come from theory or inspiration and are checked with experiments that reveal more about the situation. How, then, did engineering become so misunderstood? Schön relates:
People mistakenly think that since engineers use mathematics in their craft, their predictions about how long a project will take (or how much it will cost) will be similarly accurate. However, civil engineers fail in the same way as the average software developer when put in similar situations. As just one example, the project to build a highway under the city of Boston was estimated in 1983 to cost $2.2 billion and be completed in 1995. It was still incomplete in 2003, with a cost estimate of $14.6 billion (Cerasoli 2001, Chase URL). The 600% cost overrun was attributed to the project being larger than previous projects of this sort and to its use of new and untried technologies. After studying this and other civil engineering projects, Martin Fowler quipped in a public talk, "Compared to civil engineers, software developers are rank amateurs at cost overruns." Popular expectations about engineering are faulty because popular understanding of engineering as an activity is faulty. Once we understand engineering as an economic-cooperative game, the difficulty of accurately predicting the trajectory of an engineering project becomes understandable. Reconstructing Software EngineeringIf we reconsider engineering as a cooperative game of invention and communication and as reflective conversation with a situation, can we create a better understanding of the term software engineering? I believe so, and I believe that we can fit software development in the proper engineering tradition by building on the foundations of craft, the cooperative game of invention and communication, and the lessons we have learned from lean manufacturing. The craft model captures individual behavior. The cooperative game model captures team behavior. Lean manufacturing theory captures the economics of structures and strategies. The key in transferring lessons from manufacturing to engineering is to recognize that the "unvalidated decision" is the unit of inventory in engineering (or cooperative games of invention and communication in general). Here are the components of the restructuring. CraftIn The Reflective Practitioner, Schön follows the working habits of architects and engineers. In that book, we see people making predictions as to what their situation will support; then they do some of their work and watch what the situation actually produces, and from that, they alter their understanding. They update their understanding of the problem and the proposed solution according to the changed situation and their new learning. This "reflective conversation with the situation" is just what the Wright Brothers did in designing their airfoil. Craft implies skill in working in a medium, mental or physical. There are many materials in an engineering project and therefore many skills or crafts to become adept at. Some people need people management skills, others need mathematical skills, others need visual design skills, and so on. Each skill and material brings its own specialized vocabulary. Ceramicists "wedge" clay and study the shrink rate of different glazes compared to clays. Civil engineers work with the tensile strength, fatigue rates, and thermal expansion of their materials. Writers look for flow and development in their texts. Programmers look at cohesion and coupling, testability, clarity of expression, and computational complexity in their algorithms. Testers work with test coverage and probabilities of occurrences. User interface (UI) designers work with cognitive-motor task switching times, recognition times, color scales, and user work patterns. Project managers work with people and are concerned with what builds or tears down trust, community, and initiative. In each case, craft practice requires practitioners to have a reflective conversation with the material, using the specialized vocabulary. They work with the constraints offered by the materials, the vocabulary, and the project. On a software project, the UI designer is constrained by the two-dimensional screen, the operating system's rules, and the UI component set that has been selected for use on the project. The UI designer will learn what is possible and not possible in the framework (and maybe also what is not supposed to be possible but can be done anyway). As work progresses, using the evolved understanding of what can and cannot be done, the UI designer may propose a different workflow to the users from what they originally requested. The materials for a system architect are architectural standards, application program interfaces (APIs), and signal propagation technologies. The architect balances performance degradation with ease of change as he or she adds APIs and separates the system across different boxes or locations. This work is partly a mathematical activity and partly heuristic. The materials for a programmer are the programming language, the operating system, and the components or APIs the programmer is obliged to use. Some programming languages are very malleable, such as LISP, APL, Smalltalk, Python, and Ruby. Other languages are less malleable, such as Ada, C++, and the other strongly typed languages. Programmers sometimes compare working in the former languages to working with clay and working in the latter languages to working with marble. Wonderful sculptures can be made from either clay or marble, but the necessary skills and the approach differ significantly. So, too, for the different programming languages. In software engineering, the crafts include at least
To develop professionals in our field means we should recognize the various crafts needed to carry out a project. It means training newcomers in the basics of those crafts. It requires professionals in the field to continue developing skills as a natural part of being in a craft profession. It means honoring the different crafts required to complete a project. The crafts define the specific moves that the people make in the cooperative game. Cooperative GamesEngineering is seldom done alone. Engineers exchange their thoughts and proposals as they proceed along their intertwined paths. They communicate with sponsors and the users: The sponsors must find ways to fund the work, and the users must respond to the unexpected ways in which the system will change their lives. The following is a description of engineering work at Lockheed's Skunk Works facility. In this extract, it is easy to see the principles of the cooperative game in action and the cross-coupling of the crafts. This is an outstanding example of a group holding a reflective conversation with the situation as a team.
Lean ManufacturingLean manufacturing may seem a peculiar foundation for software engineering. Surely, if there is one difference between manufacturing and engineering, it is that manufacturing is about making the same item many times, and engineering is about approaching situations that are unique each time.[3]
Replace manufacturing's flow of materials with engineering's flow of decisions, however, and the rules governing the two are remarkably similar. One remaining difference is that the flow of decisions in an engineering project has loops (requests for validation and correction), which designers of manufacturing lines try hard to avoid. These loops complicate the optimal strategies for the team but do not change the rules of the situation. Figure 1.1-2 shows the flow of decisions in a software development project. The top image highlights the decisions being made; the bottom image highlights the feedback loops. Let us look at the decisions:
The testers can't tell whether the program is correct until they get running code; the programmers can't know what to code until the UI designers and BAs make their detailed choices; and the UI designers and BAs can't decide what to request until the sponsors and users make up their minds. As with manufacturing, there is "inventory," there are "work-in-progress" queues between workstations, and there is the problem of selecting batch sizes for those handoffs. The engineering team's inventory is made up of unvalidated decisions. The more decisions saved up and passed from one person to another at one time, the larger the batch size involved in that handoff. Texts on lean manufacturing (for example, Reinertsen 1997) stress that increasing the batch size generates almost uniformly negative consequences on the system's overall behavior. Small, natural variations in work speed produce unpredictable delays at the handoffs. In the end, it is hard to predict the flow through the system, even for a well-designed system. The cure is to reduce batch size at the handoff points and then choose from a collection of techniques discussed in the lean manufacturing literature to deal with the inevitable bubbles of inventory that pop up from place to place within the system.[4]
In software development, reducing batch sizes corresponds to designing, coding, testing, and integrating smaller amounts of functionality at one time. It is hard to imagine what just "one" piece of functionality is, but it is easy to see that on most software projects, many unvali-dated decisions are batched up in the requirements document, many unvali-dated decisions are batched up in the UI design, and many unvalidated decisions are batched up in the assembled code base before the testers are given anything to test. Reducing the functionality requested in one delivery increment is the first step in reducing batch sizes. As with manufacturing, a cost is associated with reducing batch sizes. In manufacturing it is the cost of switching from one job to another. Lean manufacturing companies spend a lot of money reducing job switching times so that they can gain the benefits of smaller batch sizes. (Important note: They don't make excuses that they can't have small batch sizes because they have high job switching costs; they redesign their job switching procedures to lower that cost so that they can use smaller batch sizes. This difference is significant.) Engineering groups have not only the task-switching costs but also the cost of injecting new work into the system through the feedback loops and the cost of revising the designs as the requests change. Unresolved arguments still rage in the software development community about how small the batch sizes can be made in UI and database design. Figure 1.1-2 shows one other important characteristic of a development team: There is a different number of specialists at each point in the flow, so they have different capacities for clearing their decisions. Alert managers do two things when studying these decision-flow capacities:
Now to deal with the feedback (Figure 1.1-2, bottom). When the testers find a mistake, they send a report back to the programmer or the UI team. These defect reports constitute additional inventory for the programmer or UI team to handle. A loop exists from the UI designers to the sponsors and users. The UI designers make a mock-up of the user interface, show it to the users, and come away with a stack of rework decisions. A third loop may exist from the programmers to the users and sponsors, creating more decisions being fed to the UI designers, BAs, and programmers. The same results apply to batch sizes at the handoff points and also to the use of creative strategies at non-bottleneck stations. All these dependencies exist even when the people are sitting next to each other in the same room. I suggest that those three foundations provide a model that is both sound and practical. It applies in general to cooperative games and in particular to both engineering and software development (or software engineering, as it is now safe to write). The model helps us gain insight into both education and project management. On the education side, people should be trained
On the management side, managers should
Collaboration in Other EngineeringsDr. Stephen C-Y. Lu, David Packard Chair in Manufacturing Engineering, University of Southern California, writes that "human behavior dynamics impact technical decisions that cause societal changes, which, in turn, shape human and social dynamics to influence future technical decisions. Such adaptive, cyclic socio-technical interactions represent the true fabric of modern engineering." In 2003, the International Academy for Production Engineering (CIRP) started a working group to study engineering as collaborative negotiation.[5] They felt the "need of broadening the engineering foundation from 'Engineering is Applied Science' at the present to 'Engineering as Collaborative Negotiation' (ECN) in the future. This ECN paradigm encourages engineers to use various negotiation approaches and techniques when making joint engineering decisions."
"Engineering as Collaborative Negotiation (ECN) is a decision-making paradigm that we propose as the foundation for collaborative engineering research. As such, this new paradigm offers a different perspective towards the basic questions of what is collaborative engineering, how engineers should engage in this activity, and how it can be better supported in engineering practice." The following sidebar comes from Dr. Lu, Chairman of CIRP's Working Group on Engineering as Collaborative Negotiation.
|