What Engineering Has in Common With Manufacturing and Why It Matters

I t is generally considered frivolous to compare engineering – software engineering , in our case – with manufacturing. Manufacturing (so the reasoning goes) consists of making the same thing over and over, while software engineering is about making something different each time. In software engineering, coming up with the design and code is the hard part, while production is the easy part, sometimes as easy as publishing to the internet. Software engineering is remarkably similar to manufacturing once we notice decisions as the product that moves through a network of people. In software development , people make decisions, hand those decisions to other people to build on, and (most importantly for this article) wait for other people to make their decisions. The decision in software development corresponds to a part in a manufacturing line: Both flow through a network, wait in queues at bottlenecks, have throughput delays, and so on. With this equivalence in place, there is a very real parallel between design and manufacturing. This is useful to us because manufacturing has been studied heavily over the last 100 years, and we can learn from lessons in that industry. In what follows, I shall focus on software development, but it should be clear that the same argument applies to every team-design activity, including engineering, theatre, publishing, and much of business. We start by recognizing that in team-design activities, people wait on each other for decisions. Figure 1 shows a simplified view of the dependencies between people in software development (it is missing the feedback loops, in particular). Figure 2 shows a more complete mapping of the decision dependencies, with some typical feedback loops. The feedback loops complicate matters , but do not change the basic results. In Figure 1, the dependency of one person on another is shown with a large black arrow. The person at the tail of the arrow is making decisions and passing them to the person at the head of the arrow. A small pyramid represents the actual decision being passed from one person to another. In Figure 1, we see the following: • Business analysts and user interface (UI) designers waiting for users and sponsors to decide what functions and design styles they want. • Programmers waiting for business analysts to work out the business rules and UI designers to allocate behavior to different pieces of the user interface. • Testers waiting for …