The key to rework like this is you have to actually be able to finish it and get rid of the old, instead of spending months or years maintaining two half-baked versions of something instead of just one.
The finished projects tend to stick around forever and, if they need maintenance, it’s adding a feature or two or updating dependencies.
I do backend work so this kind of workflow probably doesn’t work for customer-facing projects that need to iterate on finding traction. But for something where the problem is generally well defined and not likely to change drastically in the short or medium term, it’s amazing. I have multiple projects I’ve written that run on virtually every machine (server and workstation) at my company (former unicorn, current Fortune 500) that are effectively “done” and only need to be redeployed a couple times a year for dependency updates and preventing bitrot in general.
Having worked like this, I can confidently say I will never again remain on a team where this isn’t the normal state of affairs.
Even coming from an attitude of being big on abstractions and generalized/scaled solutions, I cannot overstate the importance of writing a throw-away version at the outset. Hit the highlights, write it fast & dirty, use it, extend it a bit as you start to understand the system — then throw it away. Use that knowledge to design and build your real system, from scratch, but informed by your earned knowledge.
>>agile makes you iterate through pseudo productivity before you actually understood the problem, accumulating cruft that you need to maintain and extend as you go on.
And to this in the GP post, I think he identified a fundamental problem with Agile. Its entire bias is to write code fast, when the bias should be to avoid writing code — code is slow and habitat for bugs. Obviously everything requires code, but it should be minimized, not maximized. Of course, writing code quickly and seeing it run is satisfying, but developers' dopamine hits shouldn't be the primary driver of design & mgt - end performance should be, and that takes careful thought of what can be eliminated, and basing that thought on knowledge of a throw-away-version-1 is very useful, and pays benefits to both the dev team and to users for years.
Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering