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
“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
Write code that is easy to delete