6 ms·

I've lost track of the number of "biggest engineering disaster" stories I've read that begin "so we decided to rewrite it..." The story arc is almost always t

I've lost track of the number of "biggest engineering disaster" stories I've read that begin "so we decided to rewrite it..." The story arc is almost always the same: starts out very promising and moves quickly, then at some point the wheels come off but everyone keeps going. Anyway, Joel Spolsky nailed it 20 years ago: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...

coldcode 6y ago
When you write code like shit, the language doesn't matter. What Uber did was write a monstrosity with too many engineers and too many features without considering that was beyond their ability to deliver reliably. The product decision making was also clearly deficient and didn't help. Rewriting is neither a panacea nor a problem if you completely understand what you started with and what you will wind up with and be brutally honest. Trying to combine a rewrite with major feature changes is extremely hard to pull off (I've done it a couple times with iOS apps, not fun, but ours came out well) and adding a new language at the same time is probably beyond any team's ability. A rewrite for good reason can be done, but not with 100's of engineers and major features changes, all done in a massive hurry; that's a recipe for disaster.
- scoutt 6y ago
  It can be quality code written by good engineers, but there are issues you won't see until you deal with big numbers. The problem here is that Swift seemed to be a cool language that it might work for a "Hello world" app. You won't notice any problem until the thing grows up to a certain point. For example, I work in embedded and I am proposed with a new "X brand" Chinese Modem to integrate in our devices. I don't recommend it but since it costs less I'm pushed to evaluate it. I am handed 3 samples and they all work fine, so management convinced themselves that Brand X from China is the way to go. Once in production the modems started to fail at a 10% rate (10 devices over 100 won't work). And that is a problem you only see only when manufacturing a certain quantity of devices. Now there are delays, an ongoing battle with the manufacturer of modems and a unhappy customer (that's why I didn't recommended it).
  - coldcode 6y ago
    We started with Swift 2.X as well but it became Swift 3 before we shipped anything; Swift 5.X now is much more mature and we have no issues. Trying to do too much with a new language plus all the other things was asking for trouble.
apozem 6y ago
Great article, thank you for sharing this. Makes a good case that the right thing to do, from a business sense, is usually not to do the full rewrite. Rather, you should do slow, un-sexy work of refactoring and cleaning up while adding new and maintaining current features.
raverbashing 6y ago
He's right on, but maybe people don't actually know what to do on those cases A full rewrite is not a Ship of Theseus thing. You're just going to reverse-engineer your own thing in another thing. Unless it is unusable (quality-wise or maybe the only current version was written in APL for Solaris, who knows) there's no need for that. Can Swift talk to ObjC? Great. Then do that. Attack the critical areas first Yes sometimes a whole new architecture is needed, but then maybe you needed to reevaluate your earlier procedures and/or hires.
trimbo 6y ago
Couple things always to mind whenever this article is referenced. Joel's example is Mozilla, but Mozilla ultimately became more successful than Netscape (in terms of userbase with Firefox). Was the problem really the rewrite, or that a browser company was doomed anyway and the rewrite exacerbated it? Also the article was published just a year before Microsoft pulled off what's maybe the most successful large rewrite and customer migration in software history: Windows/DOS to Windows NT (XP was where it became complete). I've always wished for Joel's take on NT, especially since he was at Microsoft previously and it happened just after this article was posted. What's his opinion on its success when so many weren't?
- andrewprock 6y ago
  I don't think you can consider Windows NT to be a rewrite of DOS. They were different products entirely, and existed in the marketplace concurrently for upwards of a decade.
  - trimbo 6y ago
    Microsoft took their entire userbase and successfully shifted them from DOS (and then Windows on DOS) to NT. They did it in a piecemeal fashion with e.g. Windows 95 and WIN32. What else you would call it?
    - andrewprock 6y ago
      I would call it "different products entirely".
- p_l 6y ago
  NT wasn't a rewrite, simply. It's a completely different system, that happens to support the same API/ABI, backed by long experience at Microsoft at making things backwards compatible (it's probably the biggest source of Microsoft's success). Microsoft also put ~7 years into preparing the transition piece by piece, with probably the biggest impact point being Windows 2000 that provided significant host of features that compelled big (and loud in complaints) clients over, pulling a lot of software vendors along.

coldcode 6y ago

When you write code like shit, the language doesn't matter. What Uber did was write a monstrosity with too many engineers and too many features without considering that was beyond their ability to deliver reliably. The product decision making was also clearly deficient and didn't help. Rewriting is neither a panacea nor a problem if you completely understand what you started with and what you will wind up with and be brutally honest. Trying to combine a rewrite with major feature changes is extremely hard to pull off (I've done it a couple times with iOS apps, not fun, but ours came out well) and adding a new language at the same time is probably beyond any team's ability. A rewrite for good reason can be done, but not with 100's of engineers and major features changes, all done in a massive hurry; that's a recipe for disaster.

scoutt 6y ago
It can be quality code written by good engineers, but there are issues you won't see until you deal with big numbers. The problem here is that Swift seemed to be a cool language that it might work for a "Hello world" app. You won't notice any problem until the thing grows up to a certain point. For example, I work in embedded and I am proposed with a new "X brand" Chinese Modem to integrate in our devices. I don't recommend it but since it costs less I'm pushed to evaluate it. I am handed 3 samples and they all work fine, so management convinced themselves that Brand X from China is the way to go. Once in production the modems started to fail at a 10% rate (10 devices over 100 won't work). And that is a problem you only see only when manufacturing a certain quantity of devices. Now there are delays, an ongoing battle with the manufacturer of modems and a unhappy customer (that's why I didn't recommended it).
- coldcode 6y ago
  We started with Swift 2.X as well but it became Swift 3 before we shipped anything; Swift 5.X now is much more mature and we have no issues. Trying to do too much with a new language plus all the other things was asking for trouble.

apozem 6y ago

Great article, thank you for sharing this. Makes a good case that the right thing to do, from a business sense, is usually not to do the full rewrite. Rather, you should do slow, un-sexy work of refactoring and cleaning up while adding new and maintaining current features.

raverbashing 6y ago

He's right on, but maybe people don't actually know what to do on those cases A full rewrite is not a Ship of Theseus thing. You're just going to reverse-engineer your own thing in another thing. Unless it is unusable (quality-wise or maybe the only current version was written in APL for Solaris, who knows) there's no need for that. Can Swift talk to ObjC? Great. Then do that. Attack the critical areas first Yes sometimes a whole new architecture is needed, but then maybe you needed to reevaluate your earlier procedures and/or hires.

trimbo 6y ago

Couple things always to mind whenever this article is referenced. Joel's example is Mozilla, but Mozilla ultimately became more successful than Netscape (in terms of userbase with Firefox). Was the problem really the rewrite, or that a browser company was doomed anyway and the rewrite exacerbated it? Also the article was published just a year before Microsoft pulled off what's maybe the most successful large rewrite and customer migration in software history: Windows/DOS to Windows NT (XP was where it became complete). I've always wished for Joel's take on NT, especially since he was at Microsoft previously and it happened just after this article was posted. What's his opinion on its success when so many weren't?

andrewprock 6y ago
I don't think you can consider Windows NT to be a rewrite of DOS. They were different products entirely, and existed in the marketplace concurrently for upwards of a decade.
- trimbo 6y ago
  Microsoft took their entire userbase and successfully shifted them from DOS (and then Windows on DOS) to NT. They did it in a piecemeal fashion with e.g. Windows 95 and WIN32. What else you would call it?
  - andrewprock 6y ago
    I would call it "different products entirely".
p_l 6y ago
NT wasn't a rewrite, simply. It's a completely different system, that happens to support the same API/ABI, backed by long experience at Microsoft at making things backwards compatible (it's probably the biggest source of Microsoft's success). Microsoft also put ~7 years into preparing the transition piece by piece, with probably the biggest impact point being Windows 2000 that provided significant host of features that compelled big (and loud in complaints) clients over, pulling a lot of software vendors along.