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.

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.