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.
The opening line of Tidy First? is, "Software design is an exercise in human relationships." However, we operate in an economic world. The economics sustain our work. Lose money & you'll have to stop regardless of how many other needs are met.
It's tough to maintain both "economics matter" and "humans matter" at the same time, but if it was easy regular people could do it. So I'm glad you're uncomfortable because that means you get it.
What about software that doesn't change that much after the first two or three releases? For example, I have Zoom H4n recorder that is more than 10 years old and its software had never been updated, and thats fine. It works. Is embedded software less likely to be updated, so the initial cost is higher than change cost? And not only embedded software, also some web software are running for many years without any change at all (my personal blog is an example). There is also games that are developed once and never updated, and they run pretty well.
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.
The opening line of Tidy First? is, "Software design is an exercise in human relationships." However, we operate in an economic world. The economics sustain our work. Lose money & you'll have to stop regardless of how many other needs are met.
It's tough to maintain both "economics matter" and "humans matter" at the same time, but if it was easy regular people could do it. So I'm glad you're uncomfortable because that means you get it.
What about software that doesn't change that much after the first two or three releases? For example, I have Zoom H4n recorder that is more than 10 years old and its software had never been updated, and thats fine. It works. Is embedded software less likely to be updated, so the initial cost is higher than change cost? And not only embedded software, also some web software are running for many years without any change at all (my personal blog is an example). There is also games that are developed once and never updated, and they run pretty well.
At the point it stops changing design ceases to create leverage.
I'd suggest "+ cost(regression)", what do you think?
Well since that never happens 😬.