Write code that is easy to delete
It’s hard to write software that is easy to maintain and adapt to change. There’s a multitude of maxims to try and tease out general solutions to this, or at least approaches that can mitigate the problem.
This point did the rounds on Hacker News and elsewhere:
“Write code that is easy to delete, not easy to extend.”
This is one of the better maxims for producing maintainable and adaptable software. One of the most important aspects that distinguishes it is that it acknowledges that your code is probably bad. At some point, in some situation, in someone’s perception, the code you are writing now is going to be bad and difficult. The person that encounters that difficulty is also likely to be you.
Other maxims and approaches to this problem go down the route of trying to improve the code, and once they’ve taken that junction, they leave behind a whole avenue of thought around acknowledging the basic fact that any code will be bad in some situation, and that trying to optimise it often tends to actually exacerbate this problem. Trying to improve it makes it worse. This is quite funny, and increasingly enlightening the more you are forced to confront it.
(To stretch this even further, have a look at the concept of 無爲, or “inaction”. But that is probably an unsupportable digression.)
Once you acknowledge that your code will inevitably be an annoyance to someone at some point, you are liberated to find different ways to make the situation better, if not the code. Focusing on how to make it easy to delete is a good route into that thought pattern.
For example, there’s a tendancy to have code extend its tentacles further than they should go, rather than minding its own business. We try to generalise beyond the problem that is currently being solved. “We can abstract this out and then the same code will also solve x, y and z”. “We can prevent this problem that I have just imagined from ever happening”. “We can make it easier to achieve a, b and c in future.” Maxims like DRY actively encourage this line of thinking.
“Make it easy to delete”, on the other hand, takes you down a different path. “Let’s keep this simple and self-contained”. “Let’s encapsulate this cleanly”. “Let’s make fewer assumptions about the rest of the application, and let the rest of the application make fewer assumptions about this part”. These are healthier ideas to be thinking about as you write new code.
When thinking of “business logic”, we should also think of “mind your own business logic”. It’s a kind of politeness. Code that is easy to delete tends to fulfil that.