Things You Should Never Do (2000)
joelonsoftware.comI'm a big fan of Joel Spolsky's earlier blog posts, but to be honest, I don't think this piece has aged well. If anything, I'm more of the opinion now that you should almost always plan to do a rewrite, eventually. Lots of big companies successfully rewrite stuff all the time. Google is fairly well known for having rewritten large, critical pieces of their codebase over the years.
If anything, what should be warned against is big bangs. Netscape's problem isn't that they did a rewrite (which eventually became Firefox, mind you) it's that they essentially abandoned their old code too early, and similarly, they also announced the rewrite too soon.
If you're going to do a rewrite, do it quietly, and don't announce it until it's close to ready, and even then you can roll out slowly. For example, the infamous Digg v4 debacle is another example, but the problem isn't that they did a rewrite, it's that they did a rewrite to produce a product nobody wanted, and they burned any possibility of going back after they released it.
The more experience I get, the more I think Joel was right. Developers want to believe rewrite-from-scratch can succeed because green-field development is easier and more fun than slowly refactoring inscrutable legacy code. But long before the rewrite project achieve feature parity with the original, it is already marred by the same issues that motivated the rewrite. Because the dysfunction which led to the original code turning into a mess have not been addressed.
"But we are smarter than those other guys who wrote this mess" - if that is the case, you should be smart enough to fix the mess.
I think I mostly agree with your take, but if I could defend the counterargument for a moment, there exist stronger cases for a rewrite than "we're smarter than those other guys." Namely, what happens if your requirements have fundamentally changed?
Classic Mac OS was written at a time when computers had kilobytes of memory and black and white graphics. It was not designed for multi-tasking, because at the time it was written, the world had insufficient hardware to make multi-tasking practical. It was not designed for networking, because the internet mostly did not exist at the time. It was not designed for security, because computers were a less important target for criminals, and no internet meant far fewer exploit vectors.
All of these features were post-facto bolted onto Mac OS, and the result was an unstable mess. It was ultimately a full OS rewrite that fixed the platform.
---
I'll make a separate case too, for a rewrite I wish would happen: it's all well and good for Slack to build their client in Electron as a small startup that needs to experiment and iterate quickly. However, Slack is now a reasonably-sized public company, and they (should) have a stable product that will not undergo rapid changes.
Now would be an excellent time for Slack to rewrite their client to be a native app on each of the major platforms. They have the resources to create a snappy, performant app that more customers will enjoy using.
But didn't Apple actually attempt a full rewrite of the Mac OS which eventually failed? So instead they bought an already working OS and adapted it for their purpose.
Well, as I'm thinking of it NextStep was still effectively a "rewritten from scratch" OS—it just happened to get written outside of Apple.
That is not what Joel means by rewriting from scratch. NextStep was not written to replace Mac OS, it was just later adapted into that purpose. It is a completely different scenario.
Oh yeah. I remember that clearly. It was Copland- er, MacOS 8.
What a cluster----. Back then, crashes would result in a special kind of debug screen called MacsBug[0].
When you walked into their "release-ready, hands-on lab," almost every screen was displaying MacsBug.
The change didn't actually happen until NextStep became Cocoa.
I was also at a Microsoft "Longhorn" prerelease event. They were showing "live code demos," but you could clearly see the presenter quitting Director, when they were done with their demo.
That became Vista, another famous success story (but at least, it did ship).
From wikipedias Copland article (https://en.wikipedia.org/wiki/Copland_(operating_system)):
"The Copland development effort is associated with empire-building, feature creep, and project death march. In 2008, PC World named Copland on a list of the biggest project failures in IT history."
"what happens if your requirements have fundamentally changed?" That's not a rewrite, that's a new program with the same name
What happens is that you write the first version, and then the requirements fundamentally change (or you learn that your requirements were fundamentally wrong) but it happens gradually and you change and change the old version. It's now mostly meeting the new set of requirements, but has a bunch of cruft from what it used to do.
Throwing that away and writing something to support the new set of requirements is a rewrite.
I take no position, here, on whether it should be done.
I would recommend just removing the cruft rather than throwing everything away. But cruft should really be removed continuously.
I was merely being descriptive, clarifying that there are not uncommon situations where requirements have changed and yet nonetheless one of your options is aptly termed a rewrite.
If I am to move into making recommendations, then I think the whole thing is ultimately situation dependant, but that your advice is correct for the most common cases.
Rewriting because it is messy will almost never work. Rewriting because there is a fundamental problem with the code base may be worth it.
Problems can include:
- lack of parallelism, designed with single core CPUs in mind
- lack of security, software was designed for single user, offline operation turned multi-user and online
- "wrong" optimizations, for example relying on a lot of precomputation when people now want to change everything on the fly and modern computers allow it if the software is properly designed
- relying on outdated tech, like Flash
None of the previous points involve bad design, but things change, including user expectations. For now, security is a big one. It wasn't a big deal back then, for example, in a game console, a buffer overflow in a game would just cause a crash and piss off the player in some extremely rare case. Now because your console is online and so is your bank, the same relatively harmless bug on the same game can be used to siphon your bank account.
If the code is reasonable well designed (low coupling, separation of concerns and so on) then architectural changes can be introduced by refactoring. I can't imagine an architectural change which will require every single line of code to be rewritten in a realistic application. Most likely there will be large chunks of complex business logic which is largely unaffected by the architectural change.
But migrating away from an obsolete platform probably do requires a massive rewrite. Even then it might be possible to port (rather than rewrite) large chunks.
Actually, the more experience I get, the more I think Joel was wrong. Like anything in software, I've had the experience that there are good ways and bad ways to do rewrites. Start with the reasoning for doing it:
Bad reasons: "The code is messy", "It's written in language foo while all the cool kids are using language bar these days", "It's slow".
Good reasons: "The architecture is too tightly coupled now and it won't scale without untangling major pieces anyway", "The lack of our forward velocity is directly related to problem XYZ in the code, and here is how a new architecture would fix that."
In other words, I feel like I can sniff out bad rewrites now, which are generally lack a sense of focus and a true, enumerated list of problems with the current code base. Good rewrites have clearly delineated benefits that the rewrite will bring, stuff that brings measurable value, and show that the rewrite will bring things better and more cheaply than what's possible with the current codebase.
> Actually, the more experience I get, the more I think Joel was wrong.
There is no black and white in software. Joel writes from a viewpoint that's not always applicable to all of us.
> There is no black and white in software.
That is my whole point. The title of the blog post is "Things You Should Never Do", and it highlights "They did it by making the single worst strategic mistake that any software company can make." (emphasis Joel's).
Doing a rewrite may be a horrible mistake, but Joel was just wrong advising no company should ever do it. Lots of companies have done that, quite successfully.
> But long before the rewrite project achieve feature parity with the original, it is already marred by the same issues that motivated the rewrite.
I think there are definitely counter-examples. Can you imagine using an OS in 2020 based on incremental improvements in Mac OS System 9, or Windows ME. Or browsing using a browser based on incremental improvements in Netscape 4.7?
These are hypotheticals, but isn't the Blink engine incremental improvements all the way back to KHTML? It has been more successful than Mozilla.
But again in the Windows ME vs WinNT/Windows2000 case it wasn't a re-write. It was improving an existing product and using it in a consumer space.
But Windows NT itself was a rewrite not an evolution of Windows 3.1.
Windows NT wasn't a rewrite of Windows 3.1, but an attempt of Microsoft to create a modern workstation OS that is in a completely different product category than DOS/Windows 3.1.
> if that is the case, you should be smart enough to fix the mess.
The GEOM subsystem is FreeBSD is an example though that sometimes the world changes in a way that you can't accommodate and you have to go do a big bang reset.
Because of that, FreeBSD has a much nicer set of methods for dealing with disks and hotplugging and resizing ... while Linux is still all very ad hoc.
There are other arguments for rewrites usually though.
Some of the problems came only to light, because the original software was written and showed weaknesses. Of course afterwards one always knows more.
Then there is the reason of software often not perfectly matching your use-case and you could have better, specialized for your use-case software. You might also have other ideas about how extensible and modifiable your software should be. There really is a lot of software out there, that barely works for its use-case. If you are asked to extend that, good luck with that, without introducing new bugs, due to inflexible design.
So there are very valid reason for rewriting and often you do know better, how to write the software for your own use-case.
It's about even more than that: it's about the complexity.
There's an inherent complexity in the problem being solved.
And there is an "accidental complexity" in the implementation of the solution.
Throwing away everything, people typically believe that they can avoid handling a lot of the "inherent complexity." But typically there is a good reason why the inherent complexity was addressed in the previous version of the program, and there's a big chance that the new "from the scratch" designers will have to relearn and rediscover all that, instead of transforming the already existing knowledge that is encoded in the previous version.
For anybody interested in the topic, I recommend the number of case studies presented in:
https://www.amazon.com/Search-Stupidity-Twenty-Marketing-Dis...
"In Search of Stupidity: Over Twenty Years of High Tech Marketing Disasters"
See about new rewrite of Wordstar simply not having the printer drivers that the previous had, and also other features people already expected, leading to Wordstar's demise.
Or what Zawinski's names "Cascade of Attention-Deficit Teenagers" (search the internet for that, the link here wouldn't work!)
"I'm so totally impressed at this Way New Development Paradigm. Let's call it the "Cascade of Attention-Deficit Teenagers" model, or "CADT" for short."
"It hardly seems worth even having a bug system if the frequency of from-scratch rewrites always outstrips the pace of bug fixing. Why not be honest and resign yourself to the fact that version 0.8 is followed by version 0.8, which is then followed by version 0.8?"
Or an interview with Jamie Zawinski from Siebel's "Coders at Work."
https://www.amazon.com/Coders-Work-Reflections-Craft-Program...
... "even phrasing it that way makes it sounds like there’s someone who’s actually in charge making that decision, which isn’t true at all. All of this stuff just sort of happens. And one of the things that happens is everything get rewritten all the time and nothing’s ever finished. If you’re one of those developers, that’s fine because there’s always something to play around with if your hobby is messing around with your computer rather than it being a means to an end — being a tool you use to get whatever you’re actually interested in done."
If one is able to cover all the complexity, and it is not destructive to the goal, the rewrite is OK. Otherwise, one should be critical to the ideas of rewrites as they could be potentially secretly motivated by simple (jwz again): "rewriting everything from scratch is fun (because "this time it will be done right", ha ha)"
Your last sentence made me think humorously of Fermat's Last Theorem, and 350 years of grad students trying to prove it...so ironic and in that way funny.
Netscape’s big bang rewrite is in great contrast to the current work on Firefox Quantum. Mozilla is slowly rewriting pieces of the browser in Rust to gain better performance and security.
The reason is less important than the methods.
I can't imagine this to be true.
If you can rewrite in the style of Ship of Theseus, and get a higher quality result, sure.
But if the architecture is wrong, a piecewise rewrite to a new architecture is very tough.
My impression: it's still easier than a rewrite. People always underestimate a rewrite, because they only consider the complexity they can think of, which is generally only the tip of the iceberg. I've been on projects where even though people nervously joked about the dangers of rewrites they still underestimated the costs. Bonus points if afterwards people scratch their head thinking "where the heck did all that time go"?
I think rewriting to a new architecture piecemeal is probably easier than in a big bang - assuming the thing is at all complex and you can't actually understand all of it at once. The difference is more one of perception. It's easier to see the costs of the Frankenstein architecture than the rewrite, so we overestimate the costs of the former and underestimate the latter.
The real case for a rewrite is if you honestly think all that old stuff really has mostly just sentimental value; i.e. that it's OK to break all kinds of workflows because there are enough alternatives. If you can sell actual users on relearning all their habits, you can get away with a lot.
Google tends to rewrite without all of the features. I guess you can get a way with that if you’re Google.
There's a running joke at Google that each internal tool has two versions: an old one that's deprecated and not maintained, and a new one that's being written and not ready. So I don't think these rewrites necessarily persist because they're being done well.
I keep seeing the same optimistic failure mode over and over again at each employer. It's just too tempting to rewrite, say, the SDK package deployment system rather than trying to understand and fix up the messy old Python that some past engineers left behind. And it'll only take three or four months! A year later the messy old Python with unfixed buts is still the only option because the rewrite isn't ready, and the rewrite consumed all the resources that would've been used to fix bugs.
I think a big reason people opt to re-write is a lack of desire to understand the problem as a whole and belief that anything overlooked will get fixed in production. I agree we need to be suspicious of these intentions.
Not to brag, but I recently spent a week re-writing some software I developed over 5 years (thanks covid), and it runs 100x faster. No joke. Better code, better SQL, better indexing, less list manipulation. 100x faster.
That's great work but anything you can do in a week and then throw away if it turns out bad is hardly a risky rewrite.
It's a lot easier to do now, because we are in a dependency-based system. We can often replace tens of thousands of lines of legacy with a single call to a SaaS API.
Of course, T.A.N.S.T.A.A.F.L, so caveat emptor. Needless to say, picking the right dependency is a big deal.
I once rewrote a monstrous app that was in development for 5 years (!), in just one month. In terms of LOC it was 20 times smaller than the old codebase. Had the same functionality and then some more. It had zero bugs in the first release, compared to myriad of bugs in the previous one (mostly multithreading related - yes it's hard).
All I did was, I dumped Microsoft's COM/DCOM and replaced it with REST; also replaced C++ and VB with C#. Totally made sense to rewrite from scratch and it was a big win with absolutely no downsides. Like, no downsides whatsoever because otheriwse the same month I would have spent fixing maybe 4 or 5 multithreading bugs in the old codebase.
Anyway, never say "never do X" because you are most likely wrong.
I think this advice is not relevant if you are on a project where it's feasible for a single developer to re-write it in a month. Burning a month on a failed re-write is certainly worth the risk if you take a run at it.
For projects where there are several devs going to be working on the re-write for a long time, it almost certainly is a sign that the 'legacy' code has way more knowledge embedded in it than it might seem. Having been on the death march of a re-write before I think the signs are usually obvious when you're in one scenario or the other.
> the 'legacy' code has way more knowledge embedded in it than it might seem.
Cannot agree more, but when knowledge embedded only in the code and not in comments/commits and documentation it is a problem even if you don't plan for re-write.
It is very disappointing to hear from otherwise good programmers statements like: "good code doesn't need comments (and my code is good)". As a result we have code where some line can captures hours of research and/or discussions, but there are no comments and commit logs are too brief. After a year even an author usually cannot say why it was done this way.
>I think this advice is not relevant if you are on a project where it's feasible for a single developer to re-write it in a month
The implication is that is can be non-obvious if something is potentially that sort of project, as it originally was a large undertaking. I mean, you can assume it's a fake story, but they said it wasn't originally a one person, one month thing.
I don't know that it implies the person who rewrites something is a super-genius, it's just that sometimes a new perspective or tools allow a really amazing improvement.
Yeah I was referring to the posterior - eg if your project could be rewritten by one person in a month (unbeknownst to you beforehand) then the advice is irrelevant. Hence it’s worth attempting a re-write in some cases to determine that, and failing fast.
This is my experience too. I rewrite often and liberally, and even switch langs (on the side) to check if it can bring huge gains.
I agree. With the right tools, expertise, and design, rewriting is absolutely an option. I've learned over the years that it's often better to just rewrite some crufty, old code entirely than to try to understand the old code to patch it up. This requires a very good understanding of the requirements, which have often changed from the original code, to come up with a better design for the present needs.
Of course, this doesn't apply in all cases, but "never rewrite" is a limiting strategy.
I think saying "you should never rewrite code from scratch" is a bit too dogmatic. There's a cost and risk tradeoff. I think people underestimate the cost of a rewrite (Due to ego or NIH or yak shaving), but I don't think it's never the answer.
Sometimes the language is so old it's cripplingly expensive to hire programmers in. Sometimes the code is deeply tied to a hardware architecture that is extinct. Sometimes the legacy code actually is that bad.
For reference, I've done total rewrites on two different small-ish software projects - in both cases because the original author had made design choices that made the whole thing unsustainable in the long run (no blame implied, it's more about shifting goals).
For reference, Twitter has done a total rewrite of their large codebase, and lived to tell the tale.
Yeah, it's probably closer to things like fiddling with assembly, manual thread syncing and rolling your own crypto - it's not that you should never do it, but unless you're very, very sure what you're doing and why, it's probably a bad idea.
Indeed. The most successful project I've work in my career was a re-write of a very large internal tool. The choice to "re-write" & re-envision was almost universally regarded as a good choice after the fact. One of the biggest reasons cited was moving to a different tech stack.
I hear you.
But I think that dogmatically saying "You should never rewrite code from scratch" is just useful enough to catch the vast majority of instances when you should not rewrite code from scratch.
I'm willing to be called out for being totally wrong for my dogma in the rare instance that the application should be rewritten from scratch.
Every project I have ever joined on, there has been someone who wants to start fresh. There have been a lot of projects. There was one such instance where it was a good idea.
« It’s important to remember that 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 »
With the benefit of twenty years of hindsight, I think the programmers who performed the rewrite in question did a better job than the original Netscape implementation.
Come to think of it, I'm typing this message on the direct descendent of that rewrite, while the competitor to whom they gave « a gift of two or three years » has been forced to abandon their codebase in favour of a third-party one.
Firefox has less market share today than Netscape did at the time this was written.
But the market share was lost to a "rewrite" by a competitor.
An anecdote I know, but I recently converted from Chrome to Firefox and am actively distancing all of our technology within away from Google.
There is a few more competitors today, though.
Joel classic, and it always reminds me of times I've seen this happen again and again years after it was written. I don't think I've ever seen a full rewrite bring all of its heralded benefits. I'm sure there are some people who have. There always end up being things the old system did better, and sometimes you wind up with the old and new systems running in parallel because end users need to switch back and forth until v2 is finally mature (it seemingly never finally matures).
That said, I'm in favor of a rewrite when the use cases for the platform have diverged so significantly that you essentially have to bend it in half to make it do the thing that users want it to today. That is, as some point the core use cases have changed, perhaps via a pivot, and you need to build a product that is essentially new as compared to the old.
Regardless, the cases where I've seen a rewrite take place are when the engineers are young, talented, and enthusiastic about new tech and the engineering manager doesn't want to piss them off so they let the devs play (most of them will be off to other jobs in 2-3 years leaving behind a system that is debatable as ugly and busted as the old).
Always important to mention the alternative, a "Strangler Fig Application", also known as the strangler pattern.
There's a Domain-Driven Design pattern that encapsulates this entire problem. First, never even think about rewriting an entire system. You will likely fail. Not because you're not smart and capable, but because the business won't be patient enough to allow you to do it properly. And they'd be right not to be patient. They have things to sell and customers to support...today.
That's why Eric Evans came up with the Autonomous Bubble pattern. You rebuild features one at a time and connect them to the old code through anti-corruption layers and translation layers. Over time, the older code will be set aside. In a year or two, the plug will have naturally been pulled on all of the older code.
So there's some truth to Spolsky's 2000 blog post. But it's not smart to maintain older code forever either. You have to be careful, thorough, and use the right tools.
> They have things to sell and customers to support...today.
Deau ex Agile.. knock out one "thing" at a time and let's keep loading the backlog for the next features/etc to be upgraded/rewritten. Tbh in banking I see very few rewrites, most banks (that make their own applications) don't fix it unless it breaks down. They only bother in massive upgrades where modules are rewritten, or an application is replaced one module at a time.
Max's answer to the interview question "What is the most terrible code that you ever encountered, and what was your approach to refactoring it?" is relevant here.
In his book "Code Simplicity", Max has a checklist (summarized in point 4 of https://techbeacon.com/app-dev-testing/rewrites-vs-refactori...) -- and that's the checklist referred to in the InfoQ interview.
Here is the link to the InfoQ interview: https://www.infoq.com/news/2018/01/q-a-max-kanat-alexander/
I completely agree! Throwing away your code and starting over is failing to atone for the sins of the past, and I feel like it prevents you from learning or growing as a programmer. That's why I don't think I'll ever rewrite something from scratch again.
To me, this was nowhere more obvious than from my old co-worker who was constantly trying to rewrite the internal site we worked on. First it was angular and coffeescript, but that was apparently unmaintainable after 3 months (!!!). So they rewrote it and then I joined, and it apparently made it to 6 months. Then we tried to rewrite it in TypeScript and React which blew 10 man weeks away before we abandoned it. And then he tried to do TypeScript and Angular again but it never launched.
Meanwhile, after the React debacle, I learned my lesson and focused on rewriting and rearchitecting the old code to follow more modern Angular practices (1.5 components and such), and suddenly the code didn't seem so unworkable anymore! Quality improved and features were added that made it a very popular internal site, still in use 3 years after I left that team.
So I agree, I think you should always try to improve what you have instead of starting over. (If only our UX designers would go for incremental improvements too...)
Rewriting anything complex and actively used from scratch is not a good idea and the problems have been hashed out may times.
Having said that, angularjs and coffescript is a terrible software stack in a dead ecosystem, the best course of action is probably incremental rewrite - React is really good at that because it starts out as a small rendering library and you can incrementally replace stuff like routing etc.
For that example, I would just use Decaffeinate to migrate to ES6, upgrade to TypeScript + AngularJS 1.5+ best practices as OP did, and then follow the official AngularJS -> Angular migration path.
Considering they're two entirely different frameworks, Google did a good job creating a usable compatibility layer. This allows a relatively painless "ship of Theseus"-style transition where you have a combination of Angular and AngularJS components interacting with each other, until eventually it's just Angular components and you can drop AngularJS from the build.
I completely agree. On my next app, I was forced to use AngularJS (in 2017, somehow), but did get to use TypeScript (which is somewhat hobbled by having to use Angular templates), and this is exactly what we're doing now: rewriting components one-by-one in React. I love refactoring and React is much nicer, so I'm having fun with it :)
Never say never, but still a lot of truth to this. I generally think refactoring is the better way to go unless you are backed into an architectural corner. Say, for instance the app was built in power builder and needs to support 64 bit OS. That’s a rewrite in a new language. Say the app was a MacOS 9 and OSX is coming. Rewrite. Otherwise it’s probably better to refactor old code than to chase green fields.
I've heard such thoughts expressed as "Evolution, not Revolution". You evolve (refactor) your old app into the new one, rewriting parts of it at a time.
Several comments have already expressed that they've rewritten projects successfully. I've also evolved several projects successfully too. One of the benefits of the evolution approach is that when old bugs resurface, they're less likely to show up all at once since you only changed part of the application. Also it should be easy to compare the code with the bug to the previous code without the bug because it mostly similar.
There are times when an application is beyond repair and a rewrite is necessary, but I see those times as the exception rather than the norm.
Currently on a project where I find myself thinking a lot about this post. I think a lot of the comments here are missing some of the finer points of this argument. "Rewriting" is not per se the problem, "rewriting from scratch" where a project is effectively put on hold until the rewrite gets done, is the real quagmire. There are legitimate ways of doing a rewrite that don't require boiling the ocean and prevent you from shipping. And I'm sure there are exceptions as well, but as a general piece of advice about software engineering I've found this to have a better shelf life than many other nuggets of advice.
From the three dozen or so previous submissions, the actual discussions seem to be:
2013 https://news.ycombinator.com/item?id=6327021
2012 https://news.ycombinator.com/item?id=3624830
2012 (a bit) https://news.ycombinator.com/item?id=3449953
A better way to put it IMO is that you should never go dark on your customers during a rewrite.
Refactoring code is a continuum, from "let's do nothing" (0%) to let's rewrite the whole damn thing" (100%). There's a whole spectrum in between.
While I'm a "never say never" kind of guy, I do think many well-intentioned engineers make a leap to the 100% solution too easily. There are lots of other tools in the toolbox that can de-risk the process, like becoming more service oriented, implementing facade patterns, etc., which all in some way or another work towards a "rewrite" usually without ever rewriting everything.
Sometimes you get the benefits of the 100% solution with 25% of the work, and without most of the risk. "Yeah, that part of the codebase is old and crufty, but we never have to touch it because it Just Works and there's no point in rewriting it."
Refactoring is different from rewriting.
I think the above implies that it is different, because it is a subset?
I have successfully rewritten a major codebase. It took about two years to implement. It helped that it involved moving from a mostly proprietary stack to a mostly FOSS stack, which allowed us to leverage the community and spent more time on business features rather than plumbing.
It is hard to defend position "never rewrite" (because sometimes rewrite is an optimal strategy), but I see where it comes from: 1. Most programmers when they encounter legacy code have a strong desire to rewrite it from scratch. Especially when it uses language/framework they don't know well. 2. They significantly underestimate the cost of a rewrite and either it takes much more time than estimated or a new system implements a small fraction of old features and/or re-introduces problems fixed in an old system long time ago.
It a cognitive bias and we can try to compensate it. Though like with any biases - usually you can see it in others, but cannot correct own behavior.
There are methods for rewriting legacy systems. Articles like this make the job of improving systems more difficult by creating an impassable set of presuppositions among non-technical stakeholders.
Agree that you should never rewrite from scratch. However, I believe that almost 100% of rewrites are not actually from scratch: even if not a single line is reused, there will be plenty of experience serving as a foundation.
I'm not implying that's always the case. Besides, in some cases, past experience is deliberately not taken into account -- I'm aware of a handful of systems written in procedural languages which performed not that great and were replaced by naive object-oriented implementations. Went really bad.
Having the developers of an existing code rewrite it using a much newer language & environment they master, with the existing code working rather adequately (but hard to extend and with mediocre performances)... is pleasant and useful.
Having a smaller and under pressure team of newcomers w/o any knowledge of the underlying concepts tackling a rewrite while trying to understand and fix a clunky existing code is an ordeal.
we have a data processing system in production that, for various reasons, will not scale horizontally without major work to the open source framework we're using.
Nobody has any appetite to fix the semi-abandoned framework, so if we want to process additional data from bigger workloads, we really have no choice but to rewrite our system.
Joel's right - there's a lot of pitfalls. We tried this once and it was a failure. Our 2nd attempt is going much better, though.
I suspect that instead of never rewrite from scratch, it is more never rebuild a product from scratch.
The problems with all these rewrites went well beyond just changing the codebases.
Before rewriting, create as many tests as possible, so you know what subtle things you broke/changed. Or foist the burden on QA/users to test.
Relevant links:
https://medium.com/@herbcaudill/lessons-from-6-software-rewr...
And this DHH talk (transcript) https://businessofsoftware.org/2015/10/david-heinemeier-hans...
I'm digging through some legacy code, feeling better about it after reading this.
Is Joelspolsky overrated ? There is no public code available to verify his competency like JohnCarmack. His writings are more about marketing and general technical knowledge. In my opinion he is overrated.
I think rewriting a project is an endless curse.
TLDR
Don’t re-write from scratch, refactor instead.