> Let’s call this Joel’s Law. A lot of things follow from this premise. Why do most developers think the code they inherited is a mess and want to throw it out

> Let’s call this Joel’s Law. A lot of things follow from this premise. Why do most developers think the code they inherited is a mess and want to throw it out and start again? It’s because writing something new is cognitively less demanding than the hard work of understanding an existing codebase, at least initially. Why are many rewrites doomed to fail? Because much of what makes the code seem messy are vital little improvements that accreted over time. Without some plan for simplifying them, you will end up back where you started. This is a somewhat flawed argument. The old code probably is very bad and brittle and difficult to use and really does need a rewrite in order to grow. It was probably never designed for all the requirements it has accreted and the patches that were done were likely done with expediency and minimal-change in mind and are now hopelessly entangled. It is also true that the person doing the rewrite _often_ doesn't have any appreciation for the complexity of the old code and the rewrite attempts to just simplify the problem while throwing out all kinds of requirements that it turns out were there for a reason. However, it is also possible to do the actually hard work of understanding an old codebase that you didn't write and refactoring it into a better shape, while maintaining all the requirements and producing something that is more maintainable and extensible.