Change
The purpose of design
The cost of software is dominated by the cost to change it. Successful software inspires change, for decades if you’re lucky. Was the cost before first production even 1% of the total cost?
cost(total) = cost(initial) + cost(change)
and cost(initial) << cost(change)
(All the equations here are subject to net present value, but we intend to inform intuition here not automate any decisions.)
The cost of change combines the costs to:
Understand the current behavior
Modify the behavior without accidentally breaking anything
Validate that the whole will work as expected in production
Deploy the new version
cost(change) = cost(understand) + cost(modify) + cost(validate) + cost(deploy)
We can drive down the cost of validation with automated testing. Similar with the cost of deployment.
We design software, then, to reduce the cost to understand the behavior of the current system and safely modify that behavior.
Hey Kent, I have been following you since I worked for Peter Coad 20 years ago, Jon Kern was my SA, and later for Ivar, where I was his only USA employee at Jaczone. Just saying hello and thanking you for this and so much more "First make the change easy (warning, this may be hard) then make the easy change." Kent Beck. Namaste. Doug Bock
I got a bit disturbed by this post. It's been spinning in my head, and got now mixed with political analogies with personal interests versus common interests and how would they meet.
I agree with what it shows, but am still puzzled on the implication and maybe the restriction of looking it from this money point of view only. I have the fear it may be restricted to this if not properly supported other ways.
Its talking about the benefits of the stakeholders, which could lead to, money holders giving room to the team to let it work this way if it asks to, as it is beneficial overall and does not even take longer, but also as being enforced from the top to the workers to "be more efficient" even if it could be painful for the team (working in shifts is found 10% more efficient, at the loss of your family life).
So could be seen from the team as "please work this way, it's good for the common interest" when in the end they may not even see the money benefits being given back to them, and may even get be double pain, as the team being more efficient in handling changes, be then subject to more work, or more complicated changes with tighter time constrains, "let's be more agile and adapt to every stupid change we did not even thought through".
They were "happier" when they were taking more time on their tasks, not worrying about the team and doing it the way they like, nobody bothering them. Working for the common interest, would ask them more effort and put them in a worst position (as long as the company still runs anyway).
However, I myself also like to use well thought software design, split changes, real incremental work for my own personal projects. Where I have no time, money, or profitability constraints. I just have fun working this way. Kind of "Zen and the art of software development" that is self beneficial. Even if I may be spending more time on a project I will never change again.
So I could see benefit even beyond the "At the point it stops changing design ceases to create leverage." as it could help the team work together, makes developing a more relaxed and pleasing task. And also help maintain it with newer software versions, help people using the software sources to interact with it even if it does not change it is still used by others or with other underlying software.
So I would be interested with your view from a more team focused, or even self beneficial on a personal level, so worth putting yourself the effort even if your team does not.
What if doing it this way would increase the cost by 10%.
How would you defend it, or would you even still be defending it?
I would even love if this is not a comment but a dedicated article as it is something I would like to have talked about in the book.
Thank you in advance.