I think the similarity lies in the chaos seen in the early days of industrial management and that we see now in software development.
Perhaps we’d see a GoldRatt (author of book: Goal) coming out from the software field too.
What I mean to say is practices like the JIT manufacturing and Goldratt’s theory of constraints really helped the people in manufacturing industry.
Now when one sees similar problems in the software industry one is tempted to draw experiences from the other industries, particularly the techniques which have really been succesfull.
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.”
Yes and no.
In designing a prototype it will never happen to design a Toyota Tercel, then have the customer come and ask for a Hammer.
This can happen quite often in software.
It is a limit in how “lean” you can be.
The post and some of the comments highlight why most software projects are over budget – everything has to be ‘new’, and we do not require customers to fasten their minds down and state what it is they want. Software tries to follow their ramblings.
People don’t take the time to think things through or require enough of a specification. So we invent new ‘methodolgies’, yet things are still over budget and behind schedule.
Rugby might be an “extraordinarily violent sport”, but the strange thing about it, is that traditionally it’s played by ‘upper class’ people.
There is an old saying that compares Soccer (aka ‘association football’, ‘the football with the round-ball’, ‘the world game’) and Rugby (aka ‘Rugby Union’).
“One is a thug’s game, played by gentlemen, and the other a gentleman’s game, played by thugs.”
“Variability is the enemy in manufacturing; in software, it’s the reason we get up in the morning. Every worthwhile software development project is a custom one-off job for a unique problem.”
Anything inherently not variable in software becomes a “more or less standard” library whose marginal production cost will be zero and purchase cost will be a fraction of the development cost, thus “worthwhile software development” means something not done before.
The word is “iMproper”, by the way, not “iNproper”. You’ve made the same error twice in that quote (or you and some other blogger also misquoting Wikipedia, I forget now). Wikipedia got the spelling right.
Software development is a mix of manufacturing and thinking. We moved from breadboards to assembly all the way to today’s excellent IDEs for one reason: to ignore the manufacturing and focus our brains on thinking.
There are still plenty of manufacturing processes in the chain (source control, bug tracking, builds, etc.). They can either be done haphazardly, with variable results or documented, optimized, and shoved out of the way.
Software development may not be like manufacturing, but I couldn’t help but try (and in some cases succeed) to draw parallels to manufacturing - specifically the lean manufacturing with which the Japenese taught the U.S. something about how to make cars.
Quite some time ago I read “Japanese Manufacturing Techniques: Nine Hidden Lessons in Simplicity”. It was a rather interesting looking into how the Toyota Production System was born and works, albeit in the auto industry.
While it’s not fair to really compare software and cars, after reading there are many points in which I wish software development WAS like manufacturing.
Although I agree that Mary’s book talks more about manufacturing that I usually tolerate, I also appreciate that Mary is one of those few people that has real-life experience on both industries and has enough knowledge to compare the two.
Some good points here – there are limits to the comparison. However, I think there’s another angle that’s been missed: Lean is not really about processes and tools as much as it’s about a way of thinking. This is why there’s so much emphasis on culture. Lean can be (and has been) described in many ways, but it boils down to (1) reducing waste in all its forms in the pursuit of customer value, and (2) trying to do #1 better by hypothesizing, expermimenting, observing in a continuously repeating loop.
Jim Womack, founder of the Lean Enterprise Institute, and author of some of the seminal books on Lean has shifted gears a little bit and now talks about Lean Management vs. Lean Manufacturing, and he makes the point that the thought process can be used virtually anywhere.
By the way, the Stephen Spear article mentioned above is awesome.
I also am not convinced that manufacturing industries and software development have much, if anything, in common–but, Jeff, I don’t believe that Mary is arguing this which is perhaps more clear in her more recent book, Implementing Lean Software Development.
The paper that helped inspire Scrum (The New New Product Development Game) is not about manufacturing at all, but about product development. Software Development is product development and a particularly pure form of it since the medium we work in is so malleable–a mere computer-intelligible expression of an idea. While most of what we hear about Lean has to do with the manufacturing approach Toyota and others have adopted, Toyota’s process for inventing new products (Lean Product Development) is really the basis of the thinking behind Agile methodologies like Scrum, XP, etc. While Lean Manufacturing and Lean Product Development share a few underlying principles, they are very different processes focused on very different kinds of problems. The process used to design a new car is nothing like the process for manufacturing it.
Another metaphor thrust on software is from construction. Architects design, builders build. Fowler argued persuasively (http://www.martinfowler.com/articles/newMethodology.html) that in software it is all design. The construction phase is what the compiler does. Applying Lean Product Development (not Lean Manufacturing) to Software Development makes precisely this point.
