The reason why a lot of people criticize moves to rewrite large codebases is because the industry has collected a lot of knowledge and experience with these types of moves and it rarely works out. This is why it's considered a bad practice. We are not babes in the woods, walking around with our eyes newly opened, exploring this strange, wonderous land. The lay of the land is already known in some areas, and this is one such area.
Here I would recommend the following twenty year old article by Joel Spolsky, and Joel was merely reciting knowledge that was already well understood, but in an entertaining way.
There exist codebases that are too large and too old to ever adequately rewrite. Joel Spolsky wrote an entertaining article some time ago on why rewriting software isn't always the panacea it's made out to be[0].
I'm not so sure about software engineers. We often value working solutions even if the code base is not perfect. I certainly do and I very much agree with Joel Spolsky in his classic:
"Things You Should Never Do, Part I
"They did it by making the single worst strategic mistake that any software company can make:
They decided to rewrite the code from scratch."
[1] (Emphasis his.)
Where I'm 100% sure is that consultants hate code. I've never ever seen one recommending the reuse of existing code - not once.
And it's understandable: They have nothing to gain from recommending reuse of existing code.
In the best case the code is good and everything else goes well and the client saves some money. If the consultant can not pull this of repeatedly their benefit will still be limited. The praise will be with the programers.
On the other hand, if the old code is bad or anything else goes wrong everyone will blame the consultant for the recommendation.
For the consultant it's a risk-return tradeoff that just always favors a rewrite from scratch.
> ... implementation re-written from the ground up
Rewriting a big project from scratch is often used as something to brag about: "Look at all the hard work we accomplished!". Except in software what matters is correctness and efficiency, not the age or the code or the size fo the rewrite. Rewriting "from the ground up" is throwing away years of bugfixes[1].
Maybe this new version is fine; I'm only suggesting that big re-implementations should be seen as an unknown risks, and that "carefully refactored problematic areas of the code" is something worth bragging about on a slide.
That article is an incredibly useful warning against the temptation for casually taking code rewrites, but it's incomplete.
Sometimes full rewrites are necessary and good. The trick is doing it correctly. Rewrites are riskier, more difficult, and require more development resources than greenfield development. More so when you consider that you can't just abandon the old code until the new code is mature and has proven itself.
Most people do rewrites the wrong way, and they get into trouble, but that doesn't mean there isn't a right way. There are many examples of unsuccessful rewrites in history, but also many examples of highly successful ones.
Joel Spolky wrote a popular essay on why you should never do The Big Rewrite. I mostly agree with it but it's not always clear cut (Mozilla - his example in the essay - eventually got re-written as the most popular browser in use today)
It's a difficult decision to make, the choice between improving an existing code base that has grown warts against the temptation of starting fresh and fixing what went wrong the first time, under the guise of learning from past mistakes.
I guess the lesson is: Don't try to rewrite your codebase from scratch unless you understand that you will spend an order of magnitude more time on the rewrite, even factoring in the experiences you have gained from doing it once.
I am on the camp that big rewrites are more often than not a mistake. The real reason behind most rewrites is that writing code is easier than reading code. A system has grown to be too complex to understand, and instead of taking the time to study and understand it, you start writing it from scratch instead. At some point you end up with a new system of perhaps comparable complexity as the original. You now understand that system better, but give it enough time you will get rusty, or new devs will join that do not understand it. Rinse and repeat.
Also many devs underestimate the reasons why code has ended up being smelly. Unaccounted edge cases, legacy system support, time constraints. Who says you won't hit time constraints during the rewrite too?
Of course there are many good reasons for a rewrite too. Being more experienced and a better dev today than you were yesterday when you wrote it, is a great way to clean up whatever amateur mistakes you might have created. Or perhaps the system is inefficient and now you know how to improve it. But incremental updates, and defining the critical code path and making sure that is as robust as possible (eg I am sure you can increase system performance by magnitudes by changing only 10% of the most-often run code), are great ways to start.
Good luck, and I am looking forward lessons learnt too!
I think the idea he's trying to convey is that rewrites are a bad idea IF you already have a nice clean, simple product that works, with a large code base. I've been on projects where the entire code base was essentially trashed, except for some specific reference materials, but the code was terrible, and that was actually a pleasant experience.
First, there's no such thing as something you should "never" do, especially when it comes to code. Our problems are so abstract that few if any tools should be off-limits.
Second, the author leaves out any examples of where rewrites succeeded. Windows NT was effectively a rewrite and is the grandfather of every version of Windows that came after Windows ME. Game engines and websites are rewritten all the time to varying degrees of success. OBS was a full rewrite and they're killing it. Slack did a rewrite and, whether you like them or not, they've been very successful.
Some of what he says makes no sense IMO, like:
> [...] when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time.
Perhaps there's no reason to believe that you will certainly do a better job, but surely much of the time there are lessons to be learned even if the old team is entirely gone. When I'm brought on to new projects, I can pretty quickly tell what's dysfunctional, why that is, and what parts can at least benefit from serious cleanup.
He goes on:
> [...] you probably don’t even have the same programming team that worked on version one, so you don’t actually have “more experience”. You’re just going to make most of the old mistakes again, and introduce some new problems that weren’t in the original version.
What the author is doing here is making the same logical fallacy that he attempted to point out in the opposite position, except he's actually making it here. He's assuming that the team rewriting a hypothetical codebase are going to make most of the same old mistakes again. While that's definitely possible, is it really so certain? Can no one learn lessons from code regardless of whether they themselves wrote it?
A full rewrite was a bad idea for Netscape at a time where the market around the web was brand new and moving ridiculously fast. It's the circumstances that lead to the Netscape rewrite being a disaster. Not all software is subject to those issues, commercial or not, and not all software teams are the same.
Conventional wisdom says that complete code rewrites are almost always a bad idea. Joel has some great essays on this from several years back.
Developers that have not tackled a big rewrite tend to believe they are the exception to this rule (I believed I was).
After tackling a major rewrite most discover why it is called 'conventional' wisdom. I won't volunteer for it again (on a several hundred thousand line code base).
However bad your code appears, and if it is generating significant revenue then it probably isn't _that_ bad, you almost certainly can refactor it step by step. Yes, it may take a while, but it is manageable!
> Rewrites are the devil though, at least that's what Joel Spolsky taught me.
From scratch rewrites of anything large are, absolutely. But it's entirely possible to rewrite code component-by-component in many cases, and that's what most of the successful moves have done.
There is no reason to think a ground-up rewrite of existing working code will lead to better and more maintainable code.
As with almost every argument in this area that depends very much on context.
A substantial rewrite might be an opportunity to use better tools and improved techniques that have been developed since the original was written. In some cases that could represent a huge improvement in things we actually care about like developer productivity and the quality and performance of the product. Importantly this doesn't imply anything was done wrong or any bad decisions were made by the developers of the original product or the people who have maintained it so far. It's just that we work in a fast-moving industry and sometimes even a few years can see some big improvements in what the available technologies can do.
A development team starting with a relatively clean slate can take into account all the knowledge and feedback received over the lifetime of the existing system. Maybe it was too expensive to make use of those insights while evolving the original system but a new version can take advantage of them. Again that can represent big gains in areas that we care about.
It's often observed that a big rewrite risks losing a lot of small improvements and fixes that have accumulated over the lifetime of the existing system and of course that's true. However it's also true that a big rewrite can avoid a lot of existing design problems or get rid of long-standing bugs that no-one was ever going to get around to fixing.
I've seen big rewrites that didn't end well. But I've also seen big rewrites that were done for sensible reasons and had very positive outcomes. And I've also seen things that should have been rewritten but weren't and instead became a drag on everything. There is no universal rule here.
tl;dr Things you should never do: rewrite the code from scratch.
Sentiment like this is not valuable. The experience that it comes from is often informative, but as a conclusion, this explicitly ignores circumstances that sometimes do make rewriting a good, compelling course of action.
Truly bad, unmaintainable code exists. It exists on projects that have long intended futures. It exists in all sorts of environments on all sorts of projects for all sorts of reasons. To discount the idea of a rewrite out of hand is a failure to objectively review the specific circumstances around whatever it is you're working on.
Often there are better ways, and yes, often a rewrite is a bad idea. But absolutes are so rarely valid, and this one is most certainly not universally true.
When it comes to rewriting others' code, it's prudent to keep in mind that it's naturally harder to understand code written by someone else. Just because you're confused in the first five minutes of looking at something doesn't mean it's an unsalvagable spaghetti. It's too easy to underestimate the time and cost of a rewrite and confuse your lack of knowledge for a fault in the codebase. Of course sometimes a rewrite is still appropriate after that consideration.
If it's your own code then you probably have a better judgement than anyone whether it's in need of a rewrite.
Doesn't everybody tend to rewrite major components of something in its early states? Though I find as I gain experience over the years I have to rewrite/"draft" code less and less.
As a general rule you shouldn't rewrite everything from scratch. This does not mean that you shouldn't, on occasion, rewrite some parts of your system. Rewrites are expensive. On the other hand some code you think is bad really is bad, and it will be a net win to rewrite it.
To make a call like this, you really do need a pretty good understanding of your codebase, your business, your testing exposure, the capabilities of your team, and probably some other stuff as well. In reality, your understanding is never going to be as good as you really need it. This doesn't mean you should never rewrite any portion of your codebase, it just means that you really need to reduce the scope a lot to reduce the risk to a manageable amount.
This reminds me of the Joel Spolsky's post on why you should never re-write your code from scratch [1].
The reasoning goes most 'ugliness' comes from bug-fixes that people encountered along the way, and by re-writing that 'two page function' you lose all that accumulated knowledge. In short, the hacks that make us want to rewrite code are there for a reason
The thing is, there are a lot of small systems maintained by a lot of small teams. Unfortunately, when Joel wrote
“They did it by making the single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch.”
some people took the “any software company” to heart and now apply the same principle even in those smaller contexts when sometimes the code really is that bad and rewriting the whole thing really is by far the best plan. I’ve seen very senior people citing the Netscape case study to support a no-rewrite position while discussing a 10kLOC system that could be rewritten from scratch in a couple of weeks by a single developer.
This is the most overrated and overquoted piece of (bad) software engineering advice ever. Sure, it's harder to read unfamiliar code than write new code, because your understand the reasoning behind the new code. That's exactly why rewrites often make much more sense than labor-intensive incremental changes.
I've had many real-life situations where I successfully chain-deleted thousands of lines of legacy code and replaced it with some sub-100-line method that simply worked. All that without understanding how legacy code works. You're wondering what's the secret here? Instead of trying to deduce the undocumented logic behind legacy code I gathered current requirements and implemented them in the simplest way possible.
In most cases the results were dramatically more readable, because I used build-in language capabilities and standard libraries whereas old code spectacularly failed to do so. Also, I didn't have to worry about requirements that were no longer relevant.
Here I would recommend the following twenty year old article by Joel Spolsky, and Joel was merely reciting knowledge that was already well understood, but in an entertaining way.
https://www.joelonsoftware.com/2000/04/06/things-you-should-...
reply