Skip to main content
2 of 6
added 345 characters in body
user avatar
user avatar

To me it's a proportion of stability (as in cemented in concrete, clay baked in the oven, set in stone). The more unstable your code is, as in the higher the probability that you'll need to change it in the future, the more easily pliable it needs to be to stay productive.

Naturally even the most difficult to maintain code imaginable doesn't pose a problem if there's never a reason to change it, only use it. And it is possible to achieve such a quality, especially for low-level system code where performance often tends to count the most. I have code I still use which hasn't changed since the late 80s.

Thoroughly writing tests is one way to improve stability. Another is decoupling. If your code doesn't depend on anything else, then the only reason for it to change is if it, itself, needs to change. Sometimes a minor amount of code duplication can serve as a decoupling mechanism to dramatically improve stability in a way that makes it a worthy trade-off if, in exchange, you get code which is now completely independent of anything else. Now that code is invulnerable to changes to the outside world.

Another helpful thing in practice is to separate your library from the unstable parts of your codebase, possibly even building it separately, as you might do for third party libraries (which likewise are meant to just be used, not changed, at least not by your team). Just that type of organization can prevent people from tampering with it.

Another is minimalism. The less your code tries to do, the more likely that it can do what it does well. Monolithic designs are almost permanently unstable, since the more and more functionality gets added to them, the more incomplete they seem.

Stability should be your primary goal whenever you aim to write code that's difficult to change. You counteract the difficulty of maintaining the code by maximizing the likelihood that you won't have to change the code, and therefore won't have to maintain it in the future. That brings maintenance costs down to zero no matter how difficult the code is to maintain.

user204677