2 ms·

Joel Spolsky makes a very good point about never throwing away code. To him, it is something you should never do.[0] https://www.joelonsoftware.com/2000/04/06/

Joel Spolsky makes a very good point about never throwing away code. To him, it is something you should never do.[0] https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...

hn_throwaway_99 3y ago
I love Joel's advice usually, but I don't think that piece of advice aged particularly well, for a couple reasons: 1. I think there is lot of good evidence in the past two decades where companies got killed by competitors because the competitors had the luxury of starting from scratch with better, fresh ideas. Think all of the innovations in Google Chrome when it first came on the scene, e.g. V8 and it's process model. 2. There have been examples of companies that have essentially "ripped out their guts and gone with something new" over the years - think Apple and all their chip architecture migrations over the years. 3. I've come to the conclusions that some old code bases are really just like quick sand, and they need to be scrapped. The hard question is how to do it. I think the biggest mistake is planning a major "big bang" release. While in some cases that is inevitable, the cases where a big bang is truly required are a lot rarer than one might think. From the description in the article I think there is probably a lot that could have been done beyond "we need to do a complete architectural change to get SSR". The primary problem is page load time. I've seen companies have success by putting up landing pages, which still have valuable info, but also start the download of the large bundle (the whole "it's not the wait time, it's the perceived wait time" that's the problem). Point being I think there are ways to do some gradual improvements while a larger rewrite takes place simultaneously behind the scenes. The worst thing to do is tell the business (or even worse, the public) that our current product is dead-ended but a great new thing is coming out a year later, fingers crossed, which in fairness was a big part of Joel's point.

hn_throwaway_99 3y ago

I love Joel's advice usually, but I don't think that piece of advice aged particularly well, for a couple reasons: 1. I think there is lot of good evidence in the past two decades where companies got killed by competitors because the competitors had the luxury of starting from scratch with better, fresh ideas. Think all of the innovations in Google Chrome when it first came on the scene, e.g. V8 and it's process model. 2. There have been examples of companies that have essentially "ripped out their guts and gone with something new" over the years - think Apple and all their chip architecture migrations over the years. 3. I've come to the conclusions that some old code bases are really just like quick sand, and they need to be scrapped. The hard question is how to do it. I think the biggest mistake is planning a major "big bang" release. While in some cases that is inevitable, the cases where a big bang is truly required are a lot rarer than one might think. From the description in the article I think there is probably a lot that could have been done beyond "we need to do a complete architectural change to get SSR". The primary problem is page load time. I've seen companies have success by putting up landing pages, which still have valuable info, but also start the download of the large bundle (the whole "it's not the wait time, it's the perceived wait time" that's the problem). Point being I think there are ways to do some gradual improvements while a larger rewrite takes place simultaneously behind the scenes. The worst thing to do is tell the business (or even worse, the public) that our current product is dead-ended but a great new thing is coming out a year later, fingers crossed, which in fairness was a big part of Joel's point.