In traditional pre-agile software development, the cost of change does indeed rise substantially, maybe even exponentially, over time. The cost of testing goes up. The risks of regressing functionality when making changes goes up.
But the big change in perspective, which you led, was to realize that things did not have to be this way: Instead of making decisions based on fixed cost-benefit curves and calculations, we could instead dramatically reduce those future costs with changes in the process of building the software.
Likewise, the "I have to ask for everything up-front or I won't get it." is an inevitable result of the way we fund and make decisions on improvement initiatives -- "projects." As an industry, we usually structure it that way. But we don't have to. With build and delivery approaches that enable iterative delivery with substantial change over time, without excessively increasing costs, one can sensibly do iterative requirements specification too.
It's not just a different view of fixed cost-benefit curves. It's a fundamental changing of the curves themselves.
In my ears (non-native English reader) “empirical“ sounds like a loaded term. We don’t have rigorous data, elaborate research designs and so on and that’s what empiricism would require in my ears. I don’t have an alternative to offer but in my mind the practice of “just enough design” is guided by probing and sensing the effects of the system (in the sociotechnical meaning) and adjusting course based on what we observe.
I think one should strive for design by experience or, in any other case, for design by knowns. As you mentioned, perception curves are just that—perception curves—and over time, one learns that different designables have varying costs of design or lack thereof.
If we were to follow the categorization of knowns, we would likely find different curves for the cost of development in relation to the cost of design.
I wonder to what extent the difference between sooner and later is a difference in the way design is expressed. Perhaps design always comes first, but the sooners prefer communicating design by way of talking it through using textual and visual artefacts, while the laters prefer communicating via code and working software.
Having read all of this, I get the point and think it’s a good one. I admit it took me much too long to realize what you meant by “design” though - I thought it referred to UX/UI design, which only made half sense. Might be worth clarifying early on.
In traditional pre-agile software development, the cost of change does indeed rise substantially, maybe even exponentially, over time. The cost of testing goes up. The risks of regressing functionality when making changes goes up.
But the big change in perspective, which you led, was to realize that things did not have to be this way: Instead of making decisions based on fixed cost-benefit curves and calculations, we could instead dramatically reduce those future costs with changes in the process of building the software.
Likewise, the "I have to ask for everything up-front or I won't get it." is an inevitable result of the way we fund and make decisions on improvement initiatives -- "projects." As an industry, we usually structure it that way. But we don't have to. With build and delivery approaches that enable iterative delivery with substantial change over time, without excessively increasing costs, one can sensibly do iterative requirements specification too.
It's not just a different view of fixed cost-benefit curves. It's a fundamental changing of the curves themselves.
Your draws triggered me (because of ocd) but it worthed! Thank you.
What about "Goldilocks"? https://en.m.wikipedia.org/wiki/Goldilocks_principle
In my ears (non-native English reader) “empirical“ sounds like a loaded term. We don’t have rigorous data, elaborate research designs and so on and that’s what empiricism would require in my ears. I don’t have an alternative to offer but in my mind the practice of “just enough design” is guided by probing and sensing the effects of the system (in the sociotechnical meaning) and adjusting course based on what we observe.
I think one should strive for design by experience or, in any other case, for design by knowns. As you mentioned, perception curves are just that—perception curves—and over time, one learns that different designables have varying costs of design or lack thereof.
If we were to follow the categorization of knowns, we would likely find different curves for the cost of development in relation to the cost of design.
By knowns, I refer to:
https://en.wikipedia.org/wiki/There_are_known_knowns
I wonder to what extent the difference between sooner and later is a difference in the way design is expressed. Perhaps design always comes first, but the sooners prefer communicating design by way of talking it through using textual and visual artefacts, while the laters prefer communicating via code and working software.
Having read all of this, I get the point and think it’s a good one. I admit it took me much too long to realize what you meant by “design” though - I thought it referred to UX/UI design, which only made half sense. Might be worth clarifying early on.