5 ms·

I have seen more than one product need to be entirely rewritten because it was just so slow working on the legacy codebase. Simple minor features (i.e the abil

I have seen more than one product need to be entirely rewritten because it was just so slow working on the legacy codebase. Simple minor features (i.e the ability to do a certain kind of promotional discount) would take forever to implement without regressions - much less the performance issues, or aged feel of the application. Tech debt can be low interest (skipping some test coverage) or absolutely crippling to velocity (i.e no tests, duplicative 1000+ line mega classes).

halpert 5y ago
But would you have needed the minor features had more time been spent on the initial product? Said another way, had the initial product not been developed quickly using the available developer resources, would the product have lived long enough to need more features?
- siliconc0w 5y ago
  Products generally always need more features. Except maybe in some captured markets or for very specific apps you need to need to either grow the product or competitors will eat your lunch. Everything changes over time - business practices, technologies, ecosystems - so most legacy applications, even if they were implemented well, need constant changes to adapt to today's users and ecosystems.
  - halpert 5y ago
    Failed products don’t need more features, which was my point.
mnd999 5y ago
I’m always cynical of things needing to be entirely rewritten, especially if it’s in a different language and / or framework. It’s a very expensive thing to do and there’s no guarantee you won’t still have issues. So my question is, were any of these products completely rewritten, and if so were they still successful?
- jack_h 5y ago
  I'd say it depends on context and just how bad it is. I'm in the embedded world and I often advocate for rewrites. As an example the current code bases I maintain has code that persist certain (per product) information to flash which dates all the way back to EEPROM. That is it doesn't take into account wear leveling, it's not power loss resilient, it's copy-pasted between numerous code bases except one implementation which is shared between several products, it relies on a ton of undefined behavior, it's a bad design, has no tests, and not all of our products can even be updated. Realistically there is no fixing this. It's also just one part of a larger whole that will eventually collapse into technical bankruptcy while a competitor leap frogs us. Embedded is certainly a different world though. The complexity really comes from the fact that 95% of the code is custom, generally poorly designed without tests, and then duplicated and modified over and over again. So rewrites can be very successful in my realm if upper management can be convinced.
deleted 5y ago
[deleted]
quantified 5y ago
I’ve spent the last 9 months doing little but rewriting indebted code that is a tar pit to all new and existing devs. Next year we can hire people who will be productive, and I can actually start to add features and resilience. Glad my employer can afford this luxury.
commandlinefan 5y ago
> would take forever But you’re salaried, so it doesn’t matter.

halpert 5y ago

But would you have needed the minor features had more time been spent on the initial product? Said another way, had the initial product not been developed quickly using the available developer resources, would the product have lived long enough to need more features?

siliconc0w 5y ago
Products generally always need more features. Except maybe in some captured markets or for very specific apps you need to need to either grow the product or competitors will eat your lunch. Everything changes over time - business practices, technologies, ecosystems - so most legacy applications, even if they were implemented well, need constant changes to adapt to today's users and ecosystems.
- halpert 5y ago
  Failed products don’t need more features, which was my point.

mnd999 5y ago

I’m always cynical of things needing to be entirely rewritten, especially if it’s in a different language and / or framework. It’s a very expensive thing to do and there’s no guarantee you won’t still have issues. So my question is, were any of these products completely rewritten, and if so were they still successful?

jack_h 5y ago
I'd say it depends on context and just how bad it is. I'm in the embedded world and I often advocate for rewrites. As an example the current code bases I maintain has code that persist certain (per product) information to flash which dates all the way back to EEPROM. That is it doesn't take into account wear leveling, it's not power loss resilient, it's copy-pasted between numerous code bases except one implementation which is shared between several products, it relies on a ton of undefined behavior, it's a bad design, has no tests, and not all of our products can even be updated. Realistically there is no fixing this. It's also just one part of a larger whole that will eventually collapse into technical bankruptcy while a competitor leap frogs us. Embedded is certainly a different world though. The complexity really comes from the fact that 95% of the code is custom, generally poorly designed without tests, and then duplicated and modified over and over again. So rewrites can be very successful in my realm if upper management can be convinced.

deleted 5y ago

[deleted]

quantified 5y ago

I’ve spent the last 9 months doing little but rewriting indebted code that is a tar pit to all new and existing devs. Next year we can hire people who will be productive, and I can actually start to add features and resilience. Glad my employer can afford this luxury.

commandlinefan 5y ago

> would take forever But you’re salaried, so it doesn’t matter.