Three evolutionary stages of thinking about how we make software

Sarah Mei gave a keynote called “Factory, Workshop, Stage” at Rubyfuza this year. I loved it. She spoke about the conceptual models we use to explain the hard problems in making software. These hard problems are not about hardware, design patterns or vim versus emacs. The hard problems are about people, of course.

Sarah argues that our models of thinking about the hard problems in software are flawed. We tend to think of the software creation process as a factory. It’s in our subconscious, in our everyday language as software makers. We’re building product. Then we ship it. Then we maintain it. It’s the language of a factory: making some thing.

Here are some of the hard problems in software according to Sarah:

  1. The effects of hiring a new person
  2. The effects of a person leaving
  3. Adding more people to increase output levels
  4. How to measure productivity

Stage 1: Factory model

According to Sarah, the factory model does a poor job of explaining these problems.

1. The effects of hiring a new person. The factory model says each person only does one small job, and so is replaceable. There is almost no effect when a factory hires a new person. The factory model is not helpful in explaining the effects of hiring new person in the software world. 🙁

2. The effects of a person leaving. Again, the factory model says we just replace the employee. Not helpful in explaining when a skilled software engineer leaves a team. 🙁

3. Adding more people to increase output levels. In a factory, getting more people and machines will increase output. In software, getting more people and machines might actually make you deliver less. Not helpful. 🙁

4. Measuring productivity. In the factory, if you want to know how productive you are, just count the number of widgets. In software, just count the number of…what? Not helpful. 🙁

The factory model is not useful in explaining the hard problems in software. Sarah suggests it’s time for a new model. Sarah brings this idea home by quoting George Box: “All models are wrong. Some models are useful.” The current models we use to think about software are not only wrong, but also no longer useful.

The idea of a new, more useful model superseding an old, less useful model isn’t a new idea. Sarah gives us a history lesson from the 1800s. Back then, the miasma model explained the spreading of infectious diseases. The miasma model claimed that poisonous particles in the air gives the air a bad smell. Breathing this bad smelling air is what makes people sick. Smelly swamps were dangerous places because of this. Even though this model was wrong, it was useful. It explained a bunch of things to some efficacy. People in close proximity to each other get sick because they’re breathing the same air. Sewers keep smells away (and also reduces drinking water contamination). Closing your window keeps out bad air (and also keeps mosquitoes out).

Cholera challenged the usefulness of the miasma model. If smelly air spreads disease, how could cholera spread along sea routes? There was a need for a new model. Enter Louis Latour’s germ theory (1860s). Cholarea can spread along sea routes, because germs spread disease through a variety of vectors (including water).

Stage 2: Workshop model

The factory model isn’t useful, we need a new model. Some attempts at this have already been made. Sarah digs into how many people adopted the idea of software as craftsmanship. Sarah calls this the workshop model. Let’s see how it explains the hard problems.

  1. The effects of hiring a new person. Imagine a sword smith and his (or her) apprentice. They form a close-knit team. Hiring a new apprentice is probably going to negatively affect the sword smith. The same is true for a software team. The workshop model works! 🙂
  2. The effects of a person leaving. Like the hiring scenario, if a sword smith’s apprentice leaves, it will have a negative effect. The workshop model works here too. 🙂
  3. Adding more people to increase output levels. Two sword smiths working on two separate anvils will make more swords. Two programmers working on two separate computers will not make more software per se. The workshop model falls down here. 🙁
  4. Measuring productivity. You can measure the productivity of a sword workshop by counting the number of swords made. With software you can’t count anything. The workshop model isn’t helpful here. 🙁

So the workshop model scores 2/4. The workshop model focuses a bit more on the people than the factory model. But, fundamentally, the workshop model is still about making some thing (just like the factory model).

Stage 3: Stage model

This is where Sarah makes a brilliant departure. What would happen if we have a model that does not focus on making some thing? What if we saw making software as something less like a factory or workshop and more like putting a theatrical play together? Enter the stage model.

Putting a play together requires a bunch of steps. There’s a script and a director. Actors interpret the script. Next, actors do read-throughs where they decide how their characters will relate to each other. Actors then go away and do some self study. Then the rehearsals begin. Finally, it’s opening night and the actors perform the play.

Putting a play together sounds a lot more like making software. Different programmers (actors) will design a different solution to problems (script). The more they have built together, the more difficult it is to go back on certain decisions (rehearsals).  And finally there is the deadline (opening night) and user feedback (reading the audience). Let’s see how the stage model does with our hard problems.

  1. The effects of hiring a new person. If you bring a new actor into the mix, the entire dynamic of the play changes. It becomes a different play. Same thing in software. The stage model is useful! 🙂
  2. The effects of a person leaving. Same goes for someone leaving – it becomes a different play. If a member leaves a software team, you get the same kind of dynamic. The stage model works here too. 🙂
  3. Adding more people to increase output levels. You’re not going to make the play better or faster by adding more actors to the troupe! This rings true for software teams too. The stage model works. 🙂
  4. Measuring productivity. What does productivity even mean in the context of a play? How good the production was? How much the audience enjoyed it? The same applies to software: productivity is difficult to measure. The stage model works. 🙂

The stage model scores 4/4. Like Sarah says, we realise now that software’s end result is no more a product than a play about Macbeth is a product — it’s an interactive experience. Software is about people, it is not about making some thing. We’ve known that it was about people all along — the stage model helps us understand why.