@Matthew Broberg: I don't actually believe either part of that line :)
The point is that the software development as a whole is very different undertaking with very different goals from industrial production. The economics of software work very differently from manufacturing. In the latter, throughput (the things you produce) directly translate to revenue (and if there is demand, profits).
So in industrial production, you can very well look at flow metrics as performance metrics.
The challenge is that we often adopt this mental model when porting these concepts over to software. These metrics are often treated as performance metrics, and this is mostly wrong in the software context.
But in reality what we should be interested is in the "flow" part of the flow metrics instead of the "metrics" part.
Especially in the face of uncertainty in knowing what to build, and operating in an OODA loop etc.. having smooth flow of work is crucial to getting faster feedback on what you produce.
Properly used, the underlying machinery behind these metrics helps you measure, diagnose and fix flow problems in software product development just as they do in industrial production contexts.
The underlying math behind this is general enough, that it works even in the highly variable, non-repetitive work that we do in software. The principles and mathematics of flow are a very powerful and general mental model that has huge value in software.
What I am arguing here is that it is mistake to simply equate these with the manufacturing because that was where these were applied initially.
It's like thinking that Newtons laws apply only to apples :)
Yeah, I'm still working through some of these ideas myself, so happy to engage and clarify and improve my own understanding in the process :)
Re: economics - the economic model I think is closer for software is real estate. We invest money into a fixed asset (the codebase) over time and collect returns on rental income on the property, and potentially capital appreciation.
And I only mean this as a loose analogy/mental model - not literally :)
The main point is that any specific improvement we make to the property is not going to appreciably move the needle on how much rent you collect etc.. but cumulatively over time, if the costs of your capital investments don't turn into sustained returns then your code base is not economically valuable.
And ideally in the long term, we want to get more rent for fewer changes to the codebase, which is the PE investors dream scenario - pure rent seeking :)
So this decouples incremental output from the economic equation.
But this does not change the need for understanding how we can deliver this work efficiently and with less waste.
@Matthew Broberg: I don't actually believe either part of that line :)
The point is that the software development as a whole is very different undertaking with very different goals from industrial production. The economics of software work very differently from manufacturing. In the latter, throughput (the things you produce) directly translate to revenue (and if there is demand, profits).
So in industrial production, you can very well look at flow metrics as performance metrics.
The challenge is that we often adopt this mental model when porting these concepts over to software. These metrics are often treated as performance metrics, and this is mostly wrong in the software context.
But in reality what we should be interested is in the "flow" part of the flow metrics instead of the "metrics" part.
Especially in the face of uncertainty in knowing what to build, and operating in an OODA loop etc.. having smooth flow of work is crucial to getting faster feedback on what you produce.
Properly used, the underlying machinery behind these metrics helps you measure, diagnose and fix flow problems in software product development just as they do in industrial production contexts.
The underlying math behind this is general enough, that it works even in the highly variable, non-repetitive work that we do in software. The principles and mathematics of flow are a very powerful and general mental model that has huge value in software.
What I am arguing here is that it is mistake to simply equate these with the manufacturing because that was where these were applied initially.
It's like thinking that Newtons laws apply only to apples :)
Thank you @Matthew !
Yeah, I'm still working through some of these ideas myself, so happy to engage and clarify and improve my own understanding in the process :)
Re: economics - the economic model I think is closer for software is real estate. We invest money into a fixed asset (the codebase) over time and collect returns on rental income on the property, and potentially capital appreciation.
And I only mean this as a loose analogy/mental model - not literally :)
The main point is that any specific improvement we make to the property is not going to appreciably move the needle on how much rent you collect etc.. but cumulatively over time, if the costs of your capital investments don't turn into sustained returns then your code base is not economically valuable.
And ideally in the long term, we want to get more rent for fewer changes to the codebase, which is the PE investors dream scenario - pure rent seeking :)
So this decouples incremental output from the economic equation.
But this does not change the need for understanding how we can deliver this work efficiently and with less waste.