3 ms·

They violated the "Things You Should Never Do, Part I" rule: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsof

by duxup 2y ago

They violated the "Things You Should Never Do, Part I" rule: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-... It's such a TEMPTING rule to violate... The amazing part was how BAD it went, supposedly engineers were raising every red flag possible that it wasn't ready and still they did it. Considering how bad it was I can't imagine having any faith in anyone up the chain of command having the power, or intelligence to do the right thing at this point it was such a bizarre failure.

sergioisidoro 2y ago
Basecamp violates that rule often and they are doing ok. If I remember right they even make it a strategy to re-write their whole application every few years. There's no hard rules in software engineering, and all best practices should be put into context. You don't know what monsters lurked in the old code base. So yes in some cases (but not often) re-write is a good / only choice.
- duxup 2y ago
  I don't know much about them. It would be interesting to see how the manage all the usual pitfalls.
- 93po 2y ago
  basically every billion or trillion dollar company the started as a startup has rewritten their entire platform
amelius 2y ago
The rewrite couldn't have caused this, because there was a single German developer who wrote a usable app, see this comment elsewhere [1]. [1] https://news.ycombinator.com/item?id=42683999 https://news.ycombinator.com/item?id=42683999
- duxup 2y ago
  I think the article actually goes into detail why a rewrite does cause these things. The reasons matter.
  - amelius 2y ago
    To me this reads more like a mismanagement issue than an issue caused by a rewrite.
    - duxup 2y ago
      In a perfect world maybe, but we don't code there.
  - Arnt 2y ago
    Well, I've seen a rewrite that worked. The CEO used the software, including the signup processes. I've also seen a sequence of gradual changes that broke badly. Nobody in management used any part of the product. I don't think being a rewrite is the important difference there, if you see what I mean.
raydev 2y ago
I've been a part of a few successful rewrites, one definitely larger than what Sonos did. We should let go of some of the JoS dogma. Failed rewrites are the result of mismanagement, not because rewrites are inherently bad.
- AlexandrB 2y ago
  This kind of implies that a rewrite requires better management than just sticking with the existing codebase. It's still a pretty strong reason not to do a rewrite unless you're 1000% sure the organization can handle it.
- johnsbrayton 2y ago
  I am sure there are rewrites that were necessary or beneficial. But I think it’s fair to say that usually they are a mistake. And a lot of “bad code” comes from starting to write clean code and then coming across a variety of assumptions that prove incorrect, and real-world considerations that add complexity.

by duxup 2y ago

sergioisidoro 2y ago

Basecamp violates that rule often and they are doing ok. If I remember right they even make it a strategy to re-write their whole application every few years. There's no hard rules in software engineering, and all best practices should be put into context. You don't know what monsters lurked in the old code base. So yes in some cases (but not often) re-write is a good / only choice.

duxup 2y ago
I don't know much about them. It would be interesting to see how the manage all the usual pitfalls.
93po 2y ago
basically every billion or trillion dollar company the started as a startup has rewritten their entire platform

amelius 2y ago

The rewrite couldn't have caused this, because there was a single German developer who wrote a usable app, see this comment elsewhere [1]. [1] https://news.ycombinator.com/item?id=42683999 https://news.ycombinator.com/item?id=42683999

duxup 2y ago
I think the article actually goes into detail why a rewrite does cause these things. The reasons matter.
- amelius 2y ago
  To me this reads more like a mismanagement issue than an issue caused by a rewrite.
  - duxup 2y ago
    In a perfect world maybe, but we don't code there.
- Arnt 2y ago
  Well, I've seen a rewrite that worked. The CEO used the software, including the signup processes. I've also seen a sequence of gradual changes that broke badly. Nobody in management used any part of the product. I don't think being a rewrite is the important difference there, if you see what I mean.

raydev 2y ago

I've been a part of a few successful rewrites, one definitely larger than what Sonos did. We should let go of some of the JoS dogma. Failed rewrites are the result of mismanagement, not because rewrites are inherently bad.

AlexandrB 2y ago
This kind of implies that a rewrite requires better management than just sticking with the existing codebase. It's still a pretty strong reason not to do a rewrite unless you're 1000% sure the organization can handle it.
johnsbrayton 2y ago
I am sure there are rewrites that were necessary or beneficial. But I think it’s fair to say that usually they are a mistake. And a lot of “bad code” comes from starting to write clean code and then coming across a variety of assumptions that prove incorrect, and real-world considerations that add complexity.