5 ms·

23 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-...

by adt 4y ago

DonsDiscountGas 4y ago
Beat me to it
- Zigurd 4y ago
  "Second system syndrome" is what came to my mind. But I'm wicked old.
  - lamontcg 4y ago
    Actually its not going to be that. That's when you've got something small that works and the rewrite is a bloated mess of every feature you could dream of. This is the case where you've got an accumulation of over a decade of technical debt and Chesterton's Fences and someone who has no idea why the code is the way that it is inherits it and decides to rewrite it, and not knowing which constraints are necessary and which aren't they throw away most of them and find out the hard way that the problem isn't actually that simple. It is almost the inverse of the second system syndrome. But it is abundantly clear that Elon doesn't even know how to have this conversation.
    - Zigurd 4y ago
      In a sane acquisition a list of issues would have some out in technical dd. Not that Elon would have listened to anyone doing technical dd.
bmitc 4y ago
It can be a legitimate strategy. Hard rules in software rarely work.
- drks91 4y ago
  Any successful example?
  - bmitc 4y ago
    I've done it myself several times, but of course on projects small enough for a single developer. I also think the approach of rewriting bits and pieces over time works. You can identify pieces of the old code base that has well-defined behavior and can be split off with a well-defined interface between the new and old code. This has the added benefit of both needing to understand the old codebase and what you'd ideally want from a new codebase.
    - ojkelly 4y ago
      This is one of the foundational concepts behind microservices. A service small enough that a team or engineer can rewrite it in a cycle/sprint. When it’s bigger than that, you have the compounding effects of other systems that interact with each other.
      - object-a 4y ago
        For microservices, the "rewrite" fallacy usually takes the form of: "Why are there so many small services running? Surely we can shut down / delete/ merge together a bunch of them to clean things up" I'm pretty sure Elon has also hit this fallacy during his tenure at Twitter.
        Jcowell 4y ago
        > "Why are there so many small services running? Surely we can shut down / delete/ merge together a bunch of them to clean things up" It’s such a Weird fallacy since I feel like the entire point of Microservces is that there’s an inherit reason they’re microservices in the first place. If you don’t know why, you investigate why. It feels far easier to make a monolith than a microservice.
  - 4y ago
loandbehold 4y ago
Browser is lot more complex than Twitter.
- object-a 4y ago
  I am extremely skeptical that Netscape 4 is a lot more complex than modern day Twitter.

23 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-...

by adt 4y ago

23 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-...

DonsDiscountGas 4y ago

Beat me to it

Zigurd 4y ago
"Second system syndrome" is what came to my mind. But I'm wicked old.
- lamontcg 4y ago
  Actually its not going to be that. That's when you've got something small that works and the rewrite is a bloated mess of every feature you could dream of. This is the case where you've got an accumulation of over a decade of technical debt and Chesterton's Fences and someone who has no idea why the code is the way that it is inherits it and decides to rewrite it, and not knowing which constraints are necessary and which aren't they throw away most of them and find out the hard way that the problem isn't actually that simple. It is almost the inverse of the second system syndrome. But it is abundantly clear that Elon doesn't even know how to have this conversation.
  - Zigurd 4y ago
    In a sane acquisition a list of issues would have some out in technical dd. Not that Elon would have listened to anyone doing technical dd.

bmitc 4y ago

It can be a legitimate strategy. Hard rules in software rarely work.

drks91 4y ago
Any successful example?
- bmitc 4y ago
  I've done it myself several times, but of course on projects small enough for a single developer. I also think the approach of rewriting bits and pieces over time works. You can identify pieces of the old code base that has well-defined behavior and can be split off with a well-defined interface between the new and old code. This has the added benefit of both needing to understand the old codebase and what you'd ideally want from a new codebase.
  - ojkelly 4y ago
    This is one of the foundational concepts behind microservices. A service small enough that a team or engineer can rewrite it in a cycle/sprint. When it’s bigger than that, you have the compounding effects of other systems that interact with each other.
    - object-a 4y ago
      For microservices, the "rewrite" fallacy usually takes the form of: "Why are there so many small services running? Surely we can shut down / delete/ merge together a bunch of them to clean things up" I'm pretty sure Elon has also hit this fallacy during his tenure at Twitter.
      - Jcowell 4y ago
        > "Why are there so many small services running? Surely we can shut down / delete/ merge together a bunch of them to clean things up" It’s such a Weird fallacy since I feel like the entire point of Microservces is that there’s an inherit reason they’re microservices in the first place. If you don’t know why, you investigate why. It feels far easier to make a monolith than a microservice.
- 4y ago

loandbehold 4y ago

Browser is lot more complex than Twitter.

object-a 4y ago
I am extremely skeptical that Netscape 4 is a lot more complex than modern day Twitter.