Hacker News Reader

Comment by majormajor | Hacker News Reader

The way I've phrased something similar before is "don't do a full rewrite if you couldn't write up a plan for refactoring in place to fix the problems with the old system."

If you can build that plan, and make the case that it will be easier to do the full rewrite, go for it. But if you couldn't put together the fix-in-place plan, you might not understand everything the old system does well enough to actually estimate the size of a rewrite...

(This isn't solely for full-parity rewrites: if you're dropping features, what does that look like dropping from the old system?)

View on HN

I was involved in a rewrite where it would have been much easier to refactor the old system.

A year into the process one of the c-level leaders pulled me into a room and asked why I couldn't fix the legacy code, and I basically told him that he should have pushed back on it. I couldn't fix the legacy code because that would be months of refactoring that should have been done instead of the rewrite.

Context: the legacy code had some design flaws that required major refactoring, but the legacy code "worked" except for very large deployments. The only problem was that the legacy system wasn't modular, so it didn't have unit tests and wasn't cross platform. All of those problems are easier to tackle via refactoring instead of a full rewrite.

> The way I've phrased something similar before is "don't do a full rewrite if you couldn't write up a plan for refactoring in place to fix the problems with the old system."

Hmm... there have been a number of times when I've banged my head against the wall trying to figure out how to make my own code do something, until I finally bit the bullet and decided to rewrite the entire chunk from scratch and suddenly it took a fraction of the time I had spent trying to fix it to get it written and working. Not sure how to reconcile this with the advice you gave.

Rewriting a chunk is much easier than rewriting the whole application.

In fact rewriting a chunk sounds rather like refactoring.

I agree, rewriting with a clear head works wonders - but, to be fair to the op, when you rewrite your own code you'll be very appreciative of all the challenges and possibilities.

It's a very different kettle of fish to rewrite from scratch strange code you've not properly explored and given a chance to - which is the usual situation.

Great point, I didn't realize that aspect!

Rewriting "a chunk" of code kind of is refactoring, though.

Knowing what the system should do, in sufficient detail that there is nothing of significance to be discovered with regard to its requirements, while simultaneously not actually knowing enough about how it works to the point where you could plan how to refactor it, is quite a corner case in the field of legacy systems (the latter is quite commonplace, but the former is almost unheard of.)

But rewriting one chunk at a time could be considered refactoring.

Yes, two other people have said the same thing already. I don't personally agree with it but I don't have a response beyond that.

Reply on news.ycombinator.com