Hacker News Reader

Comment by 0xbadcafebee | Hacker News Reader

It's always a bad idea. Eight decades of software has shown it to be true, multiple books written on it. The inherent problem with it is the idea that writing a replacement is somehow going to be easy or fast. But if it were easy or fast, somebody would have done it already! Then come the additional problems of a rewrite like second system effect, inherent complexity, human error. It's impossible to predict how long it could take to finish making it, so fast-or-easy goes out the window.

Even though it's a bad idea, in very rare cases it can be the least-bad idea. But like you said, that takes an expert to figure out, and there's not a lot of experts floating around.

View on HN

Several times in the past few months, while working on my project, I spent a week writing something exploratory within it, and after all the lessons were fully learned and absorbed, erased that whole part and rewrote it in just a day. I could have kept the week long buggy and badly designed version of it and saved a day of work, but it would have drastically slowed down both development and maintenance of the overall project.

Isn't that one of the tenets of Extreme Programming, write a sketch, throw it away, write it properly?

I don't know, I'm not a real programmer, I still don't understand what SOLID is. I just write code and try to fix it when it doesn't work.

The Mikado Method

That is very different from having an existing complex system and attempting a complete rewrite from scratch.

If you have a car, and you disassemble the car and reassemble the car 10 times in a row, each time trying it out, then when you finally disassemble-and-reassemble an 11th time, without the defects you've seen the last 10 times, that will be pretty easy and fast.

If you disassemble and reassemble a car 10 times, but only once a month, it's not going to be as easy.

If you disassemble and reassemble it only once a year, it'll be even harder.

If you have never disassembled and reassembled it, and you want to not only disassemble it, but redesign all its parts, and then reassemble it, in one go, that will be incredibly time-consuming and error-prone.

That is the prototypical "entire software rewrite" which is just a bad idea, full-stop. It's not that it's impossible to work; you can eventually get the car to work again. It's just way more expensive, time-consuming, and error-prone, than people realize when they start it. The whole argument for it is that it'll somehow be quicker and cheaper, and that has never been the case. It is attractive because it feels less complex than a process of incremental improvement of an existing legacy system. But the reality is that it's often more complex, due to all the problems involved in a first-time tear-down, re-design, and re-build.

I am not the only person who has noticed this...

  - https://en.wikipedia.org/wiki/The_Mythical_Man-Month
  - https://www.onstartups.com/tabid/3339/bid/2596/Why-You-Should-Almost-Never-Rewrite-Your-Software.aspx
  - https://testdouble.com/insights/managing-legacy-code-rewrite-vs-renovate
  - https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
  - https://www.reddit.com/r/ExperiencedDevs/comments/sr8zyf/why_exactly_does_most_software_rewrite_fail/
  - https://daedtech.com/the-myth-of-the-software-rewrite/
  - https://levelup.gitconnected.com/why-rewriting-applications-from-scratch-is-almost-always-a-bad-idea-5402d1715006

It depends on the size of the (sub)system, the inherent complexity of any version vs incidental complexity of the initial version, and the time given for a rewrite.

> It's always a bad idea.

A significant chunk of my software career has been complete rewrites of existing systems. Every one was a huge success.

You should always beware of claims of universality ;-)

What would you say is most important for a rewrite to be successful?

A lot of disagreement apparently but I agree with you. Been doing this a long time and never seen it be a good idea.

I completed one successfully and it paralyzed a team of five for a year. Thankfully it was an internal product being rewritten for sale so the affect on users was minimal, but we also lost a year of potential sales.

Every other attempt I've seen has started with beautiful ideas, rainbows and pots of gold at the end, but went south after the first 20% code written and things got hard.

It's possible to do if you're willing to cripple development efforts or progress for an extended period and understand the result will have it's own issues and a rewrite isn't a silver bullet.

Reply on news.ycombinator.com