Things You Should Never Do, Part I (2000)

The main reason why developers do rewrites is because it is easier to read your own code than it is to read somebody else's code. Doing a rewrite means you only have to work with code that was written by your current coworkers or by yourself. This is also the core motivation behind all of the schemes to force a single coding style on all developers at the cost of performance and usually with an extremely complicated design for seemingly…

I'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…

What you should do is write code in a way where rewriting parts of it is actually possible. If you don't do it that way you will eventually have to rewrite the whole thing anyways at some point. And this is done by drawing in the right amount of borders in the right spot. I am not saying microservices, but you need clear interfaces between your different layers. Rewriting is absolutely a chance to get things right but: 1. Never…

>When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work. >You are throwing away your market leadership. You are giving a gift of two or three years to your competitors, and believe me, that is a long time in software years. I think this is powerful, it's so magnetizing to follow the latest trends and consider everything preceding to be worthless or lesser, but ugly…