On starting over. Don't do it. | Hacker News Reader

On starting over. Don't do it.

ewakened.com

5 pointskentf8 comments

Where's the reasoning for this? Frequently starting over is a problem, but code refactoring can have immense benefits. Discovering a different framework or language may suit your work better, for instance.

Monkeypiling on top of old work is really advice out of the 90's.

These articles with a bunch of three word sentences and zero justification are becoming annoying.

Sometimes, it's just not a good idea. If you have a piece of software that has been battle tested and many of the bugs have been worked out over the course of several years, you will have an entire new set of bugs with a complete re-write (which could take lots of time to figure out).

I've also seen this as a solution to many problems because it was much easier for the developer to start over than to figure out the existing code and try to work with it.

But, there are some instances when a rewrite is the answer.

I have to disagree, sometimes it is a lot better to start over. For example, with legacy code with bad test or even worse, with no test at all.

If your legacy code has no tests, how do you know its replacement works correctly?

If your legacy code has no tests, how do you know it works correctly?

Because it's in production and people are using it. When you rewrite a new implementation from scratch and deploy it, you make their lives miserable, because so many things will break. This is nearly inevitable.

When talking about websites and web applications, client-side integration makes it nowadays very easy to add new modules to legacy codebases using a completely different technology. With a little bit of JavaScript, you can have some parts of webpages coming from an entirely different new server, using a new fresh framework and backend database. I think this is the best way to start migrating to new technologies, one step at a time.

Because it's in production and people are using it.

I've run into more examples of broken code for which the above statement is true than I care to remember.

My original response was meant to be a rhetorical question, with the purpose of hinting that techniques for verifying the correctness of code might have existed existed prior to the 1990s. But "we haven't heard any complaints from users yet," while certainly a popular technique, is only slightly more reliable than prayer as a QA policy and I personally wouldn't recommend relying on it.

That's kind of the angle I was coming from as well. In order to effectively rewrite something you first need to know what the existing code actually does. If you don't know that yet, then figuring it out is usually a lot harder than fixing whatever problems it has.

It's not that you should never rewrite, but it's always a lot more work than you think it's going to be.

Reply on news.ycombinator.com