5 ms·

> 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 starting from scratch, 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 also resonates a lot with Chesterton's fence[0]. Often the current solution to a problem might seem unnecessary or complicating. But the complexity lies in the problem itself. Only if you truly understand the problem you can say if the current solution is too complex itself. [0] https://en.wiktionary.org/wiki/Chesterton%27s_fence https://en.wiktionary.org/wiki/Chesterton%27s_fence

skrtskrt 6y ago
This is true, but bad codebases are inherently hard and dangerous to change. That's one of the properties of them being bad.
- aequitas 6y ago
  That's why creating a new codebase is not the solution per se. Understanding the old codebase and putting its behaviour under test should be the first step. Only then you can start working on a new codebase, compare its behaviour to the old one and call it an improvement (if you manage to not mess it up as well, which is sadly often the case). Of course this can (and should often) be done is stages and not as a whole.
  - skrtskrt 6y ago
    Agreed, whether you rewrite or change in-place you're not going to be confident in the outcome unless you have tons of end to end tests first. Then you need to find and skip/ignore the tests that don't actually test end-to-end behavior or business logic, just some implementation detail along the way. Only then will you be free to do what is probably the first step if you have a crappy codebase: start establishing domain boundaries and interfaces and splitting things across those lines.
citrin_ru 6y ago
> It’s because writing something new is cognitively less demanding than starting from scratch For me it's quite the opposite: starting from scratch is hard - you have to make too many decisions. On other hand when I see an average legacy code, with the rare exceptions I find an unpleasant mess - it is rare to find that whoever wrote cared about code readability and left useful comments (and I cannot blame them - in commercial projects code quality, maintainability e. t. c. often has the lowest priority and adding new features - the highest). So maintaining legacy code looks like an easier task for me, but usually more boring.
c7DJTLrn 6y ago
I don't like the suggestion that rewrites are based on lack of knowledge or insight. As requirements change over time, past assumptions and architectural decisions also accrete. Unless you're in a company with strong engineering culture, you get a Tragedy of The Commons kind of situation where nobody goes back and changes the architecture because they don't want to be the guy who breaks it all. In my view, good engineering culture is being unafraid to treat code as disposable and throw it away - as long as the current requirements are properly understood.
- aequitas 6y ago
  I agree that code all is disposable, old and new alike. But without knowledge and insight you won't know which code to throw away. So you either end up being the guy who introduces the new product that everybody complains about because it doesn't do what the old one did. Or you end up having to maintain both old and new because not everyone will switch to your new codebase.

skrtskrt 6y ago

This is true, but bad codebases are inherently hard and dangerous to change. That's one of the properties of them being bad.

aequitas 6y ago
That's why creating a new codebase is not the solution per se. Understanding the old codebase and putting its behaviour under test should be the first step. Only then you can start working on a new codebase, compare its behaviour to the old one and call it an improvement (if you manage to not mess it up as well, which is sadly often the case). Of course this can (and should often) be done is stages and not as a whole.
- skrtskrt 6y ago
  Agreed, whether you rewrite or change in-place you're not going to be confident in the outcome unless you have tons of end to end tests first. Then you need to find and skip/ignore the tests that don't actually test end-to-end behavior or business logic, just some implementation detail along the way. Only then will you be free to do what is probably the first step if you have a crappy codebase: start establishing domain boundaries and interfaces and splitting things across those lines.

citrin_ru 6y ago

> It’s because writing something new is cognitively less demanding than starting from scratch For me it's quite the opposite: starting from scratch is hard - you have to make too many decisions. On other hand when I see an average legacy code, with the rare exceptions I find an unpleasant mess - it is rare to find that whoever wrote cared about code readability and left useful comments (and I cannot blame them - in commercial projects code quality, maintainability e. t. c. often has the lowest priority and adding new features - the highest). So maintaining legacy code looks like an easier task for me, but usually more boring.

c7DJTLrn 6y ago

I don't like the suggestion that rewrites are based on lack of knowledge or insight. As requirements change over time, past assumptions and architectural decisions also accrete. Unless you're in a company with strong engineering culture, you get a Tragedy of The Commons kind of situation where nobody goes back and changes the architecture because they don't want to be the guy who breaks it all. In my view, good engineering culture is being unafraid to treat code as disposable and throw it away - as long as the current requirements are properly understood.

aequitas 6y ago
I agree that code all is disposable, old and new alike. But without knowledge and insight you won't know which code to throw away. So you either end up being the guy who introduces the new product that everybody complains about because it doesn't do what the old one did. Or you end up having to maintain both old and new because not everyone will switch to your new codebase.