Hacker News Reader

What tends to happen as you refactor bad code is that you gain some intuition about the way the code needs to flow. The longer you spend grinding away at the existing code, the more likely it is that rewriting it will work, because you'll have pent-up "architectural energy" waiting to be used, and good, already-debugged code from the previous version that can be copied in.

The most likely causation for crossing a threshold from refactor to rewrite, while steering clear of the "big bang rewrite", is that you have to ship a feature that triggers an end-run around some of the existing architecture. So you ship both new architecture and the new feature, and then it works so well that you can deprecate the old one almost immediately, eliminating entire modules that proved redundant.

Edit: And if you don't really know where to start when refactoring, start by inlining more of the code so that it runs straightline and has copy-pasted elements(you can use a comment to note this: "inlined from foo()"). This will surface the biggest redundancies at a minimum of effort.

Joel Spolsky has a pretty good rundown. The biggest takeaway for me was that legacy apps usually don't have clear reproducible requirements. All the corner cases are written down in one place: the old code. Throwing that out means you'll recreate most of the bugs that were already fixed in the old system.

It is painful to look at and work with the old code, so we want to avoid it. But some things worth doing are painful, like exercise, or getting a cavity filled.

[edit] https://www.joelonsoftware.com/2000/04/06/things-you-should-...

10k loc is very very minor league. You can do anything you want on a base that size, it won't matter.

100's of thousands to millions of loc is a lot more problematic, many moving parts and weird interplay is to be expected.

I understand that it likely "won't matter". My point was to ask if it was worth talking about outliers to the Never Rewrite law.

eg it's assumed when talking about refactoring over rewriting that a large portion of features is working. There should be some percentage where it's worth rewriting over refactoring. Or perhaps a size where it's small enough to easily rewrite.

Yes, that's definitely a discussion worth having.

To me you can rewrite anything that:

(1) you fully understand (and you'd better be right about that)

(2) you have total control over already

(3) is small enough for (1) and (2) to be possible

(this is where I think a lot of people over-estimate their capabilities)

(4) where you have the ability to absorb a catastrophic mistake

(which usually isn't the pay-grade of the programmers)

and finally

(5) where you have a 'plan-B' in case the rewrite against all odds fails anyway

None of these are absolutes, if there is no business riding on the result then you can of course do anything you want. The history of IT is littered with spectacular failures of teams that figured they could do much better by tossing out the old and setting a date for the deploy of the shiny new system. Whatever you do make sure that your work won't add to that pile.

The older, the larger, poorer documented, worse tested the system is the bigger the chance that it is not fully understood.

Your example is much smaller than what people are usually talking about in terms of big-bang rewrites. So maybe you will be successful.

Even so, you're better off doing a step-by-step rewrite, where the new stuff and the old stuff coexists in a single application. That way your users can continue getting incremental benefits over time even if the rewrite takes dramatically longer than you're optimistic estimate.

If you can't figure out how to manage the complexity of a piecemeal rewrite, consider that you may not actually understand the system well enough to avoid making version 2 just as bad as version 1.

Most people overestimate their ability to act differently than they've acted in the past. It's like the unjustified optimism of a New Year's resolution that this time you're actually going to exercise every day. To get a better result than last time, you need to impose some very clear rules on yourself that cause you to work differently.

Not attempting a full rewrite of a significant codebase is excellent advice because it's usually the right advice.

That's not to say that it can never be successful, just that the circumstances in which it will are sufficiently rare that it's usually worth discounting relatively early on.

In >20 years of dev experience, I can only think of one occasion where I successfully did a big bang rewrite i.e. tore down an application and restarted it with an equivalent system that had approx zero common code.

In that case, it was a C++ program that wouldn't actually build from clean. A lot of the code was redundant as the use cases had morphed over time (and/or weren't ever required but were coded anyway) and most changes were stuffed into base classes as it was effectively impossible work out how objects interacted. Releases took about 3 months for about 2 weeks worth of dev.

Initially, I didn't plan to rewrite it. When I realised I couldn't understand what it was doing, I took a step back and worked out what it should have been doing, assuming that I could map one to the other. What I found was that, at heart, it should have been doing something fairly simple but that the original "designers" had thrown the kitchen sink at it and its core function was lost in the morass.

I also came up with a way of making it easy to show that the new system was correct more deeply than just tests. This gave me, and folks I needed to convince, a lot more confidence that a rewrite made sense than would normally be the case.

In summary, it was quite a rare set of events that led me to the conclusion that a rewrite was the right direction: the existing system being a complete basket case, my happening to have a lot of domain expertise, the problem space turning out to be relatively simple and finding a way to "prove" correctness, all contributed. I doubt I would have made the same decision if any of them were different.

There are cases where you can do a rewrite, but still avoid the big-bang cutover, by exposing the new app only to some subset of customers or transactions. That isn't possible with every app, of course.

I think the gospel view is when you have to do both...rewrite and big bang cutover. Especially when there is no obvious fallback.

Not a dissenting opinion but I'd love to see some case studies on rewrites. As a consultant this is a frequent request and will probably be big business in the future as people migrate off of expensive legacy mainframe or other applications from the 80's, 90's, and possibly 2000's.

It's not "rewrite" that's bad, it's thinking you can cut over to a new system in a "big bang".

Rewrites are definitely common and beneficial, but the successful ones always run the new code and the old code side-by-side for an extended period of time. Which means you're still tending and caring about the old code, even as you strive to direct most of your effort into the new code.

There's the Sivers CD baby to rails (fail) and back to PHP (success) case https://sivers.org/rails2php

The application may be a steaming pile of crap, but you probably don't have as much knowledge of the problem domain as the creators did. You will get there, over time. Starting a complete rewrite throws away the bad parts, but it also throws away accumulated knowledge.

I'd say as long as you've read and understand nearly every line of code in the old system, you're good to rewrite it from scratch.

And if you write the test suite first, you're in a much better position to do this successfully.

I also disagreed with that part in the article. Big-bang rewrites can be just fine - but usually there are reasons it's not possible.