One model for a software development project is the assembly line on the factory floor, where we’re making a buhzillion copies of the same thing. And it’s a lousy model.
Software is developed in an architectural studio with people in it. There are drafting tables, drawing instruments, good lighting, pens and pencils and paper. And erasers, and garbage cans that get full of coffee cups and crumpled drawings. Good ideas become better ideas as they are sketched, analysed, criticised, and revised. A lot of bad ideas are discovered and rejected before the final plans are drawn.
Software is developed in a rehearsal hall with people in it. The room is also filled with risers and chairs and other temporary staging elements, and with substitute props that stand in for the finished products. There’s a piano to accompany the singers while the orchestra is being rehearsed in another hall. Lighting, sound, costumes and makeup are designed and folded into the rehearsal process as we experiment with different ways of bringing the show to life. Everyone tries stuff that doesn’t work, or doesn’t fit, or doesn’t sound right, or doesn’t look good at first. Frustration arises, feelings get bruised, and then breakthroughs happen and problems get solved. Lots of experiments lead to that joyful and successful opening night.
Software is developed in a workshop with people in it; skilled craftspeople who build tools and workspaces for themselves and each other, as part of the process of crafting products for people to buy. Even though they try to keep the shop clean, there’s occasional sawdust and smoke and spilled glue and broken machinery. Work in progress gets tested, and weaknesses are exposed—sometimes late in the game—and get fixed.
In all of these places, variation is encouraged. Designs are tinkered with. Discoveries are celebrated. Learning happens. Most importantly, skill and tacit knowledge are both applied and developed.
The Lean model for software development might seem a more humane step forward from the older days, but it’s still based on the factory. Ideas aren’t widgets whose delivery you can schedule just in time. Failed experiments aren’t waste when you learn from them, and if you know it won’t be waste from the outset, it’s not really an experiment. Everything that makes it into the product should represent something that the customer values, but when we’re creating something novel (which we’re always doing to some degree as we’re building software), we’re exploring and trying things out to help refine our understanding of what the customer actually values.
If there is any parallel between software and manufacturing, it is this: the “software development” part of manufacturing happens before the assembly line—in the design studio, where the prototypes are being developed, refined, and selected for mass production. The manufacturing part? That’s the copy command that deploys a copy of the installation package to all the machines in the enterprise, or the disk duplicator that stamps out a million DVDs with copies of the golden master on it, or the Web server that delivers a copy of the product to anyone who requests it. Getting to that first copy, though? That’s a studio thing, not an assembly-line thing.
The primary inspiration for this post is a conversation I had with Cem Kaner in 2008. Another is the book Artful Making by Robert Austin and Lee Devin, which I first read around the same time. Yet another is Christopher Alexander’s A Pattern Language. One more: my long-ago career in theatre, which prepared me better than you can imagine for a life in software development.
[…] It’s Not A Factory Written by: Michael Bolton […]
I really loved this post. I’ve worked for a manufacturing company who had a software development function, so you can imagine them as the kind of villain of this piece.
Michael replies: Although I’ve met a few in my time, we’re probably not talking villains here; more likely innocents.
There are elements of the manufacturing line in development (coding) and testing (checking) where in fact the problems usually lie, right? Because humans are bad at robotic, repetitive functions. The creative part of writing a novel is plot, character development. The production line part is the actual writing, which usually contains typos, grammatical errors, even with the most experienced writers. So it is with developers putting the design down in code, and testers performing the repetitive checking element of quality control. Is software development outside of manufacturing, or are there elements of manufacturing within software development?
I think it’s a mistake to think of any part of this as assembly-line work. If you were watching me write right now, you would quickly see that writing is not a production-line work. There are tons of little typos and grammatical errors, and tons of little revisions and backspacing. There are loops of evaluation, wherein I wonder if I’ve phrased something sufficiently politely (or impolitely, on occasion) and rephrase what I’ve written. There are periods in which I pause to reflect, moments when I look up a blog post or a quote—perhaps my own, perhaps someone else’s (I’ve just done this now, and I had to backspace and edit to add this little interpolation). I touch-type. That’s a mimeomorphic action, where the task that I’m undertaking in this reply is polimorphic. This is not assembly-line work. It is craft work. Every time I produce something (a blog post, a test) it is something different and new. It is not a copy. It is not an artifact. It is a performance.
If you believe that testing is “performing the repetitive checking element of quality control”, I fear for the quality of the testing work that you’re doing (or that you’re being asked to do). Testing, as we see it in Rapid Software Testing, is not about quality assurance or quality control. A test is an investigation; fresh in some way each time; each test accomplishing some work not done in previous tests.
Thanks for the response. I get what you’re saying about writing. What I meat about checking – it is a part of testing. Certainly not all of it. And checking is repetitive and repeatable, 2 things humans aren’t excellent at. It’s why it so well suited to automation. Having a ream of test cases, to be executed manually, checking outputs. Testers don’t excel in this rigid, repetitive environment and mistakes may be made in execution. It’s this part that can appear like production line work, no? I felt this part WAS like a factory, and thats why factory thinking should apply, remove the human and introduce the machine. Leaving the tester free to focus more on the human side of testing.
To back to the writing analogy, there was a machine element to free the human. Your spell checker was likely automated, right? If you had to go through and look for errors you might have missed them. Because its a rigid, dull task. So the factory element of writing in your case was already automated. But it’s still a part of developing the response. In fact the physical act of writing, moving text about, adding, deleting, has all been automated by your Word processor. As this part is dull and you’re likely to make more errors if left to it yourself.