I'm not convinced. They only show a couple of examples, but there must also be counter-examples.
The main things I've learned over 40 years:
* Rewrites will fail. Whether they're called that, or called "lift and shift" or called "refactoring"
* The reason they fail is because the focus is entirely on the technology, not the users and how they use the systems
* Understanding business systems and users and how they interact is vital. Business processes haven't changed, accounting hasn't changed, company hierarchies and competitive markets haven't changed.
* What has changed is that where people used to be the "API" for a process touchpoint, now that is likely to be another system, and will have its own API which expresses how it sees the process. Trying to "force" those systems to interact with yours in the way you want is a fools errand.
* Abstraction is really important when defining business domains. "Sales" vs "Fulfilment", "Payment" vs "Charging", "Data" vs "Information", etc.
* Software can't solve all of the possible implementations of the business domain abstractions. You have to set constraints to limit the number of "configuration" elements. Things like "Sales are always retail to end user consumers so that we don't have to deal with VAT exclusive invoicing".
* Those constraints need to be agreed to by the product owners/managers of the domain. Otherwise, every potential requirement will add yet another "knob" to the control of the domain, yet another testing path etc.
Either way, though, we're lead to similar conclusions as the article, regarding refactoring. If a codebase/system is too large to rewrite in a single project, you have to break the work into incremental steps. Theoretically the only difference between "refactor" and "rewrite" is the scope of the affected code.
I'm part of one of those rewrites right now, and while it's true that it's taken much longer and had other ancillary issues, it's clear that the problem really has moved on, and there are needs that can't be addressed without a fundamentally different solution. It's kind of trading a hard problem for a harder one: we're forced to really understand the domain we're serving, rather than simply reimplement a set of existing capabilities. (But then, I don't think maintainable, evolvable software can reliably be created without understanding the domain to begin with.)
A couple of counter-examples that come to mind are Windows (with effectively a 15 year long rewrite that required selling both lineages in parallel while keeping the compatible enough) and Mac OS (when transitioning from classic to OS X).
The point isn’t that every rewrite fails, it’s that it makes things really painful and is rarely worth it. The Mozilla rewrite, Windows NT transition, and MacOS X transition all succeeded too, just painfully.
Thus, a counterexample wouldn’t be a complex rewrite that succeeded or failed; it would be one that was surprisingly easy, painless, and shipped on time, with the expected feature set.
> As for solutions, there isn't much to say about the second system effect except you should do your utmost to prevent it; it's entirely self-imposed. Refactor your code instead. Even if it seems like incrementalism will be more work... it's worth it.
That seems to be a misleading conclusion? Maybe the moral is rather that you will probably vastly underestimate the Big Rewrite. If it is still worth it at 10x the estimated effort, you should still do it though (WinNT, OSX, etc). That raises the question if we could improve about estimating such Big Rewrite tasks.
Following that thought, the chicken-and-egg problems collapses into the second-system problem. You need to rewrite incrementally in small steps but it only pays off once you completed all the steps (or at least most of them). Until then you just introduced inconsistency into your codebase. You left a local optimum to go for another one and naturally it gets worse before it gets better. You better plan ahead how to keep moral and management support big enough to cross that gap.
The counterexample is thus not rewrites that were painless. It's rewrites that were strategic successes, which clearly Windows and Mac OS were. They are, after all, the foundation of two of the world's most successful companies.
Microsoft was a software company. Other than accessories like keyboards and mice, they sold an OS to OEMs and applications that ran on the OS. They suffered through Windows NT as a transition and the Vista debacle. Without their monopoly market, those could have ended the company.
Apple was a hardware company. Other than MacOS and a few applications, they sold hardware that ran that OS. Their focus was on selling more hardware.
Windows had to maintain compatibility because the OS is the base, there isn't anything lower down. If they lost compatibility, then the argument for running Windows was reduced.
MacOS had to enable the new features of Apple's hardware. If it didn't, then there would be no demand for the new hardware. So the transition of MacOS from M68K to PPC to x86 to M1 is necessary to enable the hardware to advance. To Apple, it's a cost of introducing more advanced hardware features.
The Mythical Man Month.
1. Nobody is doing rewrites from scratch anymore. That's just not the case.
2. Nobody is talking about all the failing rewrites causing entire companies to collapse. I don't think anyone is convinced by this argument, it's basically several big conspiracies in one.
3. People have learned how to avoid the same traps, by reading about the Netscape/Mozilla fuck-up.
Basically, the problem isn't rewrites. It's badly managed rewrites.
5. Nobody is admitting to doing rewrites from scratch anymore.
6. Netscape/Mozilla became (due to path-dependence and happenstance) the canonical example, and no other examples have been interesting/memetic enough to displace it.
7. People have learned to keep failing rewrites dragging along until something else causes them to be abandoned, sparing them the label of "failed".
8. Other.
Most software is services oriented, and it evolves, piece by piece over time.
Is Facebook running any of the same code from 18 years ago?
Probably not?
When did they re-write? They didn't, they just evolved, piece by piece.
This claim would be more compelling if it provided a few notable examples.
Google is replacing its internal systems all the time. For example, MapReduce was replaced with Cloud Dataflow [0].
[0] https://www.datacenterknowledge.com/archives/2014/06/25/goog...
This included migrating about 1/2 petabyte of old data and rebuilding several Kimball-style Data Marts to Data Vault approach, which pairs really well with the Lakehouse-style tech stack.
This all took about 9 months, which is a long time, but it was in highly regulated industry where compliance, security and data integrity get a lot of scrutiny.
In the end, nothing of the previous solution survived - no code and no infrastructure.
If you've ever used one, you can see how quickly (and iteratively, which is key) you can spin up new functionality.