Things You Should Never Do (2000)
joelonsoftware.com
Things You Should Never Do (2000)
1–10 of 85 posts
Re: Things You Should Never Do (2000)
#2I have successfully rewritten a major codebase. It took about two years to implement. It helped that it involved moving from a mostly proprietary stack to a mostly FOSS stack, which allowed us to leverage the community and spent more time on business features rather than plumbing.
Re: Things You Should Never Do (2000)
#3I think saying "you should never rewrite code from scratch" is a bit too dogmatic. There's a cost and risk tradeoff. I think people underestimate the cost of a rewrite (Due to ego or NIH or yak shaving), but I don't think it's never the answer.
Sometimes the language is so old it's cripplingly expensive to hire programmers in. Sometimes the code is deeply tied to a hardware architecture that is extinct. Sometimes the legacy code actually is that bad.
For reference, I've done total rewrites on two different small-ish software projects - in both cases because the original author had made design choices that made the whole thing unsustainable in the long run (no blame implied, it's more about shifting goals).
For reference, Twitter has done a total rewrite of their large codebase, and lived to tell the tale.
Re: Things You Should Never Do (2000)
#4There are methods for rewriting legacy systems. Articles like this make the job of improving systems more difficult by creating an impassable set of presuppositions among non-technical stakeholders.
Re: Things You Should Never Do (2000)
#5« It’s important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time »
With the benefit of twenty years of hindsight, I think the programmers who performed the rewrite in question did a better job than the original Netscape implementation.
Come to think of it, I'm typing this message on the direct descendent of that rewrite, while the competitor to whom they gave « a gift of two or three years » has been forced to abandon their codebase in favour of a third-party one.
Re: Things You Should Never Do (2000)
#6Never say never, but still a lot of truth to this. I generally think refactoring is the better way to go unless you are backed into an architectural corner. Say, for instance the app was built in power builder and needs to support 64 bit OS. That’s a rewrite in a new language. Say the app was a MacOS 9 and OSX is coming. Rewrite. Otherwise it’s probably better to refactor old code than to chase green fields.
Re: Things You Should Never Do (2000)
#7I think saying "you should never rewrite code from scratch" is a bit too dogmatic. There's a cost and risk tradeoff. I think people underestimate the cost of a rewrite (Due to ego or NIH or yak shaving), but I don't think it's never the answer. Sometimes the language is so old it's cripplingly expensive to hire programmers in. Sometimes the code is deeply tied to a hardware architecture that is extinct. Sometimes the…
Yeah, it's probably closer to things like fiddling with assembly, manual thread syncing and rolling your own crypto - it's not that you should never do it, but unless you're very, very sure what you're doing and why, it's probably a bad idea.
Re: Things You Should Never Do (2000)
#8Relevant links:
https://medium.com/@herbcaudill/lessons-from-6-software-rewr...
And this DHH talk (transcript) https://businessofsoftware.org/2015/10/david-heinemeier-hans...
Re: Things You Should Never Do (2000)
#9I'm a big fan of Joel Spolsky's earlier blog posts, but to be honest, I don't think this piece has aged well. If anything, I'm more of the opinion now that you should almost always plan to do a rewrite, eventually. Lots of big companies successfully rewrite stuff all the time. Google is fairly well known for having rewritten large, critical pieces of their codebase over the years.
If anything, what should be warned against is big bangs. Netscape's problem isn't that they did a rewrite (which eventually became Firefox, mind you) it's that they essentially abandoned their old code too early, and similarly, they also announced the rewrite too soon.
If you're going to do a rewrite, do it quietly, and don't announce it until it's close to ready, and even then you can roll out slowly. For example, the infamous Digg v4 debacle is another example, but the problem isn't that they did a rewrite, it's that they did a rewrite to produce a product nobody wanted, and they burned any possibility of going back after they released it.
Re: Things You Should Never Do (2000)
#10I think saying "you should never rewrite code from scratch" is a bit too dogmatic. There's a cost and risk tradeoff. I think people underestimate the cost of a rewrite (Due to ego or NIH or yak shaving), but I don't think it's never the answer. Sometimes the language is so old it's cripplingly expensive to hire programmers in. Sometimes the code is deeply tied to a hardware architecture that is extinct. Sometimes the…
Indeed. The most successful project I've work in my career was a re-write of a very large internal tool. The choice to "re-write" & re-envision was almost universally regarded as a good choice after the fact. One of the biggest reasons cited was moving to a different tech stack.