This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2006/10/is-software-development-like-manufacturing.html
Wikipedia got the spelling right.
Or perhaps, just perhaps, Wikipedia had the typo and we both pasted it in. Subsequently someone fixed it on Wikipedia…
And SCRUM is only one letter away from the typo in this position…
“knowledge of agile development approaches a definite plus. (XP, Scum, FDD, etc)”
On John Price’s point, I wonder if the problem is that we’ve become far too good at the final production process. That is, we have tools which are so automatic in producing the final output that there is no human effort involved in actually producing the work product from the blueprints. In the worst case, the developer must open the IDE for each component and run the Build command. In the absolute best case, the automation is set up so that a component (e.g. CruiseControl.NET) monitors the source repository and, when a checkin occurs, automatically gets the latest source and builds the output.
I wonder if this makes the casual observer, and even some developers, blind to the actual manufacturing phase and see (wrongly) that what the developer is doing as being ‘assembling the box of parts’. The corollary is that end-users will never be able to get a ‘toolbox’ programming system that works well enough to completely replace professional programmers.
Making the assembly of cars fully automated is probably achievable with technology - as in, plug blueprints and components into an industrial automation system at one end, get a fully assembled car at the other - but it would require extensive work to ensure that all the parts were aligned correctly before trying to bolt them in, and there would either have to be some dramatic redesign or some very clever tools to work in some pretty cramped spaces on most cars. Our tools have the advantage that they (now) only have to manipulate bits on disk, which is of course what any program does. It was inevitable that we would eventually get to a point where we could make building a program entirely automatic.
Software development is like software development… When will people stop trying to compare it to anything else? Metaphors are useful in small doses.
Software development is NOT like manufacturing… manufacturing is about the design of a product, and it’s subsequent replication. It’s about the process of copying. Software development is about creating an entirely new thing every time-- copying is free and is usually as simple as dragging a folder around on the desktop.
I agree with Ken(Ken on October 5, 2006 06:32 AM)in that we are constantly trying to get some new catch phrases and buzzwords to define…what? It all seems to boil down to the same old committees attending meetings. I would guess if you wanted to compare the software process to anything, it would be the process used to create advertising campaigns. Creative people trying to get a different product out each time while dealing with whiney customers.
It’s also two letters away from a pirates favorite drink. Arrrrr!
If you visit the process guidance for Scrum for Team System you’ll find a series of videos of Ken Schwaber talking about the Scrum Framework - if you’re interested in why Scrum is called Scrum (and why it’s intentionally an unfortunate name), take a look at the video called “Selling Scrum to your Manager”:
Great post – as usual. I’ve seen this parallel made before…and agree with the first post: software development is like software development. I’ve worked in the manufacturing sector (Ford and American Honda) doing custom software. We weren’t crazy enough to ask our manufacturing brethren to “help” out on our schedules/methodology.
Love the comment about requirements Jeff. My current gig is all about requirements. Management randomly thinks we have great requirements (we don’t…) or that we don’t need them at all(we do…). I’m so glad things don’t ever change!
Really, you know, whatever. In this day and age there is a constant desire to define, to model. We must have definitions and catchy terms and phrases. We must follow guidelines and adhere to the latest, greatest thing that’s catching on.
For me, though, it all gets to be a bit too much. I know this seems overly simplified but just try to do the job at hand using the right tools and taking the most logical approach.
There’s always more than one way to skin a cat, especially in software development.
Additionally, committing your people to the same approach for any and all project projects doesn’t seem to be the right answer to me. One size does not always fit all. If it did we wouldn’t have multiple languages, multiple platforms, multiple ideologies.
And scrum is just a god-awful name. Don’t get me started on all the goofy naming and labeling that’s going on these days!!!
Just my nickel of thought.
"Is Software Development Like Manufacturing?"
Why would we care?
Here’s the interesting question - what can we learn from an organisation that outperforms its peers year-in year-out.
“Recognizing that TPS is about applying principles rather than tools enables companies that in no way resemble Toyota to tap into its sources of success. Alcoa, a company whose large-scale processes - refining, smelting, and so on - bear little resemblance to Toyota’s discrete-parts fabrication and assembly operations, has based its Alcoa Business System (ABS) on the TPS rules. … pilot projects applying the rules at … health care organizations have led to huge improvements in medication administration, nursing, and other critical processes, delivering better quality care to patients, …”
Stephen Spear “Learning to Lead at Toyota” Harvard Business Review May 2004 78-86
Steven Spear and Kent H Bowen “Decoding the DNA of the Toyota Production System” Sept 1999 97-106
Ascribed to the Poppendiecks - “This is equivalent to manufacturing, where the objective is to faithfully and repeatedly reproduce a “recipe” with a minimum of variation.”
That’s strange, read the Stephen Spear articles and you’ll see that the objective is to repeatedly vary and improve the recipe - by following a standard approach to process improvement.
Jeff Atwood wrote “Variability is the enemy in manufacturing; in software, it’s the reason we get up in the morning.”
Variability in the quality of customer experience is the enemy - in manufacturing, in services, in software.
Chapter 2 of Peopleware (DeMarco/Lister). “Make a Cheeseburger, Sell a Cheeseburger.”
Same principle. In production, you optimize the steady state. Sqeeze out excess. Sternly deal with goofing off. Get as close to 100% “go” mode as you can.
Development is development is development. (dance, monkey boy!*)
Whether you’re developing armour piercing rounds, a new type of vaccine, or software. (I haven’t a clue why those examples came to mind…)
I forget whose idea it was, but I once heard a much better explanation of software development in terms of manufacturing than what is usually presented (if you simply must use a manufacturing metaphor):
In manufacturing, you spend a whole bunch of time up-front doing design work and end up with a blueprint for what you want to build. You (loosely speaking) feed that blueprint into a bunch of machines who churn out your end product The traditional software-as-manufacturing metaphor maps “creating blueprints” to “writing a spec”, “bunch of machines” to “developers”, and “end product” to the code that those developers produce.
The revised metaphor instead maps “creating blueprints” to “writing code”, “bunch of machines” to “compiler”, and your end product is the binaries that you produce.
Using this metaphor better emphazises the challenges and efficiencies of software development as compared to manufacturing.
First, it casts the coding process as the creative design step that it is, rather than suggesting that developers are a bunch of automatons that take specs in at one end and churn out software at the other.
Second, it acknowledges the need for a detailed spec, but casts the code itself in that role. After all, what more detailed spec of how software works is there than the code itself? And unlike real manufacturing where screwing up the blueprints and starting to manufacture something incorrectly is extremely costly, actually “manufacturing” something from code is essentially free. Appreciating this frees you up to try different things with your blueprints to see which one produces the best end product.
I’m embarrased to admit I walked through a lot of names for male genitalia and never got to the one you meant. Who knew you meant a mature, adult word? Be more clear next time. Either way, it’s hardly a more unfortunate name than “Scumniotales”.
I suppose one can make the manufacturing analogy if one accepts that software development is mostly about the repetitive process called typing. If one doesn’t, then analysis deriving from the analogy is wrong. Design/build of bridges or skyscrapers or doghouses is more accurate (yes, design/build is a term of art).
As to variability, we do it differently each time because we want to; rarely do our employers, they think it’s about that repetitive process called typing.
Never forget, it requires a good deal more time, effort, and brains to be a real architect than the software type. You need a license to be a real one. Hell, you need a license to be a dog groomer. Hairball anyone?
“The beatings will continue until morale improves.”
Is Software Development Like Manufacturing?
Nor is it like constructing a building, or crafting an exquisite violin, or even playing rugby. It’s also not remotely like hunting a tiger either.
Anything else I can do to help, as I’m running a bit late?
PS I can sell you a hardback limited edition ‘ScragilefallXP 2.0 - Lose 20 Pounds Instantly’(GBP 20) book if you sign up for the free training course - today!
PPS I am weirded out by your scrum/scrotum word association. I racked my brains before hovering over the link and still couldn’t guess it. Is there something you’d like to share with the group? (cough)
You would perhaps enjoy ‘Managing the Design Factory’ by Donald G. Reinertson. Building software is not like manufacturing, it is like designing the first prototype. Which doesn’t mean there’s nothing to be learned from the manufacturing-sourced idea of “just in time” or “lean.”
This is my favorite book of any kind, and definitely my favorite sofware-related book. And it’s not about software at all. I’m still working on applying the ideas to the software development team I run.
Another interesting definition of scrum (in he rugby sense)
One guy trying to push 2 guys up three guys buttholes.
It made me chuckle…and now it is my gift to all of you lovely anonymous readers. Don’t spend it all in one place.
When playing Rugby at school I always used to deliberately collapse the scrum.
Perhaps “Huddle” would be a better term - describing a daily (meeting) huddle - but that leaves me with images of poor, cold starving developers huddling together for warmth and comfort in the pouring rain (or backlog)