Especially if you bring in other users than typical end users into the mix (like the people who will be looking after, maintaining, developing, and running the product). At this point you can see how refactoring produces valuable outcomes if it makes a more simple and cohesive architecture and codebase.
The interesting thing then is how and where to get quick feedback from to work out if the refactoring activities are valuable so you don't just have to rely on experience.
PS - I also am really impressed by the way you question activities that you hold strong to. Shows humility.
Especially if you bring in other users than typical end users into the mix (like the people who will be looking after, maintaining, developing, and running the product). At this point you can see how refactoring produces valuable outcomes if it makes a more simple and cohesive architecture and codebase.
The interesting thing then is how and where to get quick feedback from to work out if the refactoring activities are valuable so you don't just have to rely on experience.
PS - I also am really impressed by the way you question activities that you hold strong to. Shows humility.
Love the analogy.
If the product was expanded to behaviour, options, and simplicity you could argue that refactoring isn't a form of over production?
I think you’re right. When we start accounting for optionality, earlier refactoring is less likely to be waste.
Great insight! (As usual :-) )
Nit: the “seven wastes” link does not seem to work.
here it is:
https://en.wikipedia.org/wiki/Muda_(Japanese_term)