I expected some wisdom, but that comment basically says that a rewrite either isn't needed because programmers are already excellent in the first run, or the rewrite will end with a similar shit code in paraphrase, because programmers have learnt nothing. Also it takes time, which costs money...

This is probably going to sound weird, possibly cheesy, but cottonseed got something out of that post, possibly more than I intended to convey, so I hesitate to follow up for fear of taking that away.

What I think I was getting at then, and certainly believe now, is that some people grow with the code, learn from many of their mistakes, and do the long quiet job of expunging their worst errors as they go. Their code is the best proof that they could accomplish a rewrite, because it already is a rewrite. They just didn't need to stop the world to do it, or at least not all at once. Perhaps a month here and a couple weeks there.

For the rest of the time it has been like the Ship of Theseus. All of the parts are new, and yet it is the same ship.

Meanwhile the rewrite guys are continuing with their mess and hoping they get a do-over, putting off things hoping for Some Day. And on that magical day, all of the bad habits of the entire team (management included) will correct themselves overnight.

Bad habits are too hard to break. The best of us know that you don't abstain from bad habits, you crowd them out with new, better ones. But that takes time, practice and determination.

If you want to condense it down to nothing new under the sun, that's fair, and I would offer that I wanted to believe the rewrite folks were onto something, but at the end of the day, breaking down the problems and using relentless refactoring seems to be the only thing that works, without changing the definition of success to achieve victory.

Additionally, as time passes you get new people working on the system that does not understand it as well as the original designers/developers, simply because they already have the system and their knowledge becomes pigeon holed inside of it. They don't have the original scope.

And then to top it off; if you did rewrite the system you not only need to reverse engineer N years of code, but also N years of bug fixes and random miscellaneous snippets that made it into the system and that no one who still works at the company understands the purpose of any longer.

And like the Ship of Theseus, it help the shipwright a lot when the guy who owns it is rich enough to check everything thoroughly before going out to sea. :p

edit: Yes, no problem, i understood now what you meant, crdoconnor put me to it.

No it isn't. It says that good programmers are doing mini rewrites all the time negating the need for a big bang rewrite whereas bad programmers are probably just piling the debt up while asking for permission to rewrite and will do once again when they rewrite.

There's some truth to this I think. Big bang rewrites are best avoided where possible and there's plenty of ways you can incrementalize refactoring that don't occur to most people.

I think you're right and i misread it. So if the mini-rewrites in silence equal relentless refactoring, that might equal a rewrite nobody ever observed, excellent.