4 ms·

I am against rewrites of any significance because they generally just end up worse. Joel Spolsky wrote about that a long time ago as did others; most software t

I am against rewrites of any significance because they generally just end up worse. Joel Spolsky wrote about that a long time ago as did others; most software that’s older has millions of badly documented changes applied by 1000s of people over the decades and rewriting tends to take literally forever (never finishes) or at least much long than anyone estimated times PI. And then the endresult is usually just as crappy but with more bugs. The Dutch tax software rewrite attempts are an example I am personally familiar with. These attempt made me create a services company to help companies keep legacy software running forever. We support gnarly stuff over 25 years old and still wouldn’t recommend a rewrite for the above reasons. There are of course cases where rewrites (of significance; rewriting a 50k LoC codebase is not going to be hard) work, but usually the rewrite is done by the same people that did the original , the original wasn’t actually that bad but just too hard to extend in modern times etc.

mekoka 3y ago
Joel published that post the same year that Microsoft announced their .NET framework. I've said this in a different threads, but I think it's worth repeating here. I've seen many successful projects that started out as reverse engineered clones of older, well established ones, then go on to become better versions of their original model. Those are in effect rewrites, just not done by the same team. For a number of years now, it's been feasible to compete technically with an incumbent in matter of months. I see it as a trend indicating an increase in software production capability, be it because of better practices, better tools, or more developer availability. So although I tend to agree with Joel's old post, and still lean toward refactoring as the likely more economical approach, I hold that advice less religiously.
- anonzzzies 3y ago
  I think reverse engineering is often better than a rewrite from code, but again, as the dutch (and I have seen it in other countries too but I am intimately familiar with both failed rewrites attempts of this one) tax software system showed, it is sometimes just not feasible, no matter the money or the amount of experts. The amount of tax payer money wasted on the attempts is criminal.

mekoka 3y ago

Joel published that post the same year that Microsoft announced their .NET framework. I've said this in a different threads, but I think it's worth repeating here. I've seen many successful projects that started out as reverse engineered clones of older, well established ones, then go on to become better versions of their original model. Those are in effect rewrites, just not done by the same team. For a number of years now, it's been feasible to compete technically with an incumbent in matter of months. I see it as a trend indicating an increase in software production capability, be it because of better practices, better tools, or more developer availability. So although I tend to agree with Joel's old post, and still lean toward refactoring as the likely more economical approach, I hold that advice less religiously.

anonzzzies 3y ago
I think reverse engineering is often better than a rewrite from code, but again, as the dutch (and I have seen it in other countries too but I am intimately familiar with both failed rewrites attempts of this one) tax software system showed, it is sometimes just not feasible, no matter the money or the amount of experts. The amount of tax payer money wasted on the attempts is criminal.