Iterational design is a thing.
If the same team that did the crappy code gets a chance to learn from the mistakes and rewrite it part by part now when they have the whole picture, it's easier and the end result might be mantainable and nice.
I've heard that the worst code is the 2nd version. You try to fix everything from the 1st version (real or perceived) and over correct as a result.
Re:Lessons learned from rewriting code
by hpolatyuruk on Sunday June 16, 2019 @05:57AM
(#20194751)
Yes, I've heard that too. But in our rewriting case, it didn't happen. We didn't make that mistake. Usually, developers made a lot of mistake in the first version and they learned many lessons. Now they are experienced about software and they will try to implement everything in the 2nd version. And they will come up with the complex system again. In our case, we cut off many features and we kept our code base small.
However the third iteration is something that you can be proud of. (but in my experience, 1/2 through the second iteration the funding gets cut off)
Also architectural needs sometimes are not really needs. E.g. you have a program for dos and think that you need a complete rewrite for windows. Then someone heroically ports over the dos program to windows, because the programs are not compatible. You end up with two programs to maintain.
When you hear about "good" rewrites it's almost never framed in a way that is "the old code is bad and complicated." It's usually driven by an architectural need - for example it started in Python, but now we have scaled up and in order to avoid $1MM/month a rewrite in Go/Rust/C would be beneficial.
Or, in the case of changing marketing needs, it can be "we now better understand our customers and a rewrite can help us provide a more stable interface and help us iterate faster". However in this case a full 100% rewrite is never the case and it's usually done piecemeal or by the new system simply proxying requests to the old system.
When the excuse is simply the "code is a mess", then not only are you admitting that the original team failed to design a maintainable system, you are also trusting them to not make the same mistake again. And if their whole motivation is "the code is a mess", they will probably fuck up the redesign, as messy code is a symptom of bad design but not the root cause. If the root cause is burnout, and that isn't addressed, the rewrite may be just as bad.