I wasn’t able to be concise enough. Since Susana’s question made me think of three other questions which I do not know the answers, I’m sharing them with you all.
Hi Susana.
Thanks for your inspiring comment. Actually, I do agree with you. The more we put focus on people (as we should, at least according to the Agile Manifesto), the harder will be defining metrics to measure value. As you say, it will also be harder to compare different approaches, i.e. Waterfall to Agile.
I don’t have a precise reply to your question, but it is so interesting that it raises at least 3 other questions.
Scrum/Waterfall/WhatEver’s Goal
In these days I’m reading The Goal: A Process Of Ongoing Improvement by Goldratt. Have you ever read it? If no, I strongly recommend it. It’s really amazing.
Oversimplifying one of his arguments, Goldratt claims that a whole arbitrary complex system could be modeled using 3 very generic (yet strict) measures:
“They’re measurements which express the goal of making money perfectly well, but which also permit you to develop operational rules for running your plant,” he says. “There are three of them. Their names are throughput, inventory and operational expense.”
“Throughput is the rate at which the system generates money through sales”
[..]
“The next measurement is inventory,” he says. “Inventory is all the money that the system has invested in purchasing things which it intends to sell.”
[..]
“Operational expense,” he says. “Operational expense is all the money the system spends in order to turn inventory into throughput.”
In the software industry:
- Throughput may be software delivered and sold.
- Inventory is hard to define: one could say that to some extent Kanban’s attempt to limit WIP might corresponds to the process of reducing inventories, that is, money stacked in investment not producing sales. Inventory is, to me, software not delivered, each piece of code that is not in production.
- Operational expense is the cost of producing software: wages, rent, time and so on. Mainly, wages, I suppose.
All of those 3 quantities must be managed in order to reach the only goal a company has: to make money.
My doubt (hence, the first question) is:
Since the goal is actually very simple no matter how much complex the system is, couldn’t we measure the efficiency of an approach rather than another through Throughput, Operational expense and Inventory?
Manufacturing industry is not just an Assembly line
The second topic that your question made me think of is about the comparison between software industry and manufacturing.
When talking about manufacturing industry, we always think about assembly lines.
Actually, this is wrong, exactly like it would be wrong to reduce software developing to “the act of typing code with a keyboard“.
A software is designed, coded, tested, deployed, reworked, refactored. Typing code is just the mere material act of putting the result of a lot of intangible activities into source code.
Well, may be we should do the same with manufacturing industry. Before the assemply line phase, the product has been designed, described in specifications, prototyped, documented, in a lot of intangible activities. The assembly line itself has been designed and planned according to the whole project.
Software development is a bit different, since we developers can design and code at the same time, while in an assembly line none of the workers are designing the product. In software development, several different phases can be overlapped and even mixed together.
Comparing software industry with just the assembly line part of manufacturing industry may be not the fairest choice. Unfortunately, some writers go on using exactly this analogy For example, some confuse the act of producing code with the mere act of coding it, and they write
After you make a program, the cost of making another one just like it is very close to zero.
I’m very sorry, but making a second program is not byte-copying the first one (which is, as a matter of fact, a free-cost task). Hence, the analogy with the assembly line (where products are replicated) is not that good.
Poppendiecks proposes
Think of development as creating a recipe and production as following the recipe.
Typing on keyboard and assembly lines are just the production phase.
The question is:
Are we sure that manufacturing industry is not about intangible things as well?
Nothing is free (as in free beer)
My last doubt is: I have often heard that software industry is so much different because while developing we programmers are exploring a problem in search of one of the possible solutions, hence, software developing is inherently exploratory, rather than predictable.
I’m pretty sure that manufacturing industry is about exploring as well: we should simply broaden the scope, don’t stop to the assembly line topic and consider it’s design phase as well.
Of course, in manufacturing, once the solution has been found and the assemply line has been set up, the work deterministic.
I have often heard that software developing is exploratory because prototyping with software is a no-cost activity, while prototyping with concrete stuff is much more expensive.
As a matter of fact, the manufacturing industry does use prototyping. Then, it uses a certain amount of exploration.
I don’t believe that software is more exploratory because prototyping is cheaper, since in almost every industry, the biggest cost is the human cost (wages).
A 2 days software spike in pair programming is not free at all, even if it does not waste concrete material. It may cost more than a (re-usable) concrete prototype.
And we developers are prototyping much more than our colleagues in manufacturing industry.
For example, until we reach the 3rd refactoring phase in TDD, all we have produced is a prototype, isn’t it?
If we could measure how much time we spend in writing prototypes (that we later refactor or rework) and we could calculate how much it would cost to the company, I’m sure we would stop saying that “prototyping in software industry is for free“.
The question is:
Is it possible that we have something to learn on exploratory activities from manufacturing industry?
Have a nice day
Any one who thinks that prototyping (or refactoring for that matter) is free obviously hasn’t thought very hard about the question. Both activities have value and costs. Not letting the costs overwhelm the value is critical.
I could not agree more.
Actually, the fact that software is not made of atoms and it is immaterial leads some one to think that producing it can be costless, or at least much cheaper than ordinary products.
Indeed. And the irony is that even for physical products, the labor costs involved are highly significant (otherwise Apple wouldn’t manufacture iPhones in China and pay to ship them to the US, etc.)
I agree with both of you
But I also think that exploratory testing in the so called industry is way too different. I wonder if something like that could be made with software at all.
What usually happens is that random samples are taken and tested and according to the measurements on how many in each lot have defects, so is the production pipe adjusted in order to get better quality.
In the software business, those who are striving and fighting for quality try to have a good coverage on the tests, specify as many scenarios as possible so that nothing is missed out. Which by definition is an impossible task in my opinion.
How would it go if we just picked random stuff to test in order to find defects in our products?
How would the cost of prototyping and testing samples improve the overall cost of production? At this moment it looks like some prototyping and testing costs much more than developing something.
Again, I think you are referring to the production phase: tests on random samples try to measure variance in the process of assembly.
Software needs fewer controls in its assembly line, since all the tasks are much more deterministic (I think a build script for deployment could be a good equivalent of the manufacturing assembly line).
When I think to exploration in manufacturing industry I refer to prototypes made in order to evaluate an idea. That is, tests and spikes made before the assembly line.
None of us think that a modern car’s project is made by applying several adjustments to the assembly line, do we?
Instead, much before a car is assembled, a project for that car is designed and produced; and, in order to design the project, a lot of prototypes and exploratory activities are made. Those are the prototypes I’m referring to. And those are equivalent to exploratory activities in software industry, aren’t they?
This was the sense of the title “Manufacturing industry is not just an Assembly line“: there’s a bunch of intangible activities before the assembly line, including some exploratory tasks, and they may be similar to the one we know in software industry.