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.
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.
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.
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