Program for maintainability

Here’s a small epiphany I had the other day.

When building software applications we should program for maintainability. It’s common to talk about “programming for scale, change, stability” etc. However, I would argue that aiming for maintainable code should be the chief goal.

I choose to define maintainable code as being open to change. It’s not about trying to predict the future instead it’s about acknowledging that there will be a long unknown future for the application. Who knows what demands the world will put on your code? The application should be able to grow/shrink to meet whatever goal you set for it be it scalability, robustness, security and so on.

The trick however is ensuring that the application remains easy to change. While you are happily building out the application you might actually be building an obstacle. Each code change result in a hurdle that gets a little harder to jump over each time someone comes and suggests a change to the thing you’re building.

Following this thinking one might argue that a rigid test suite can make it harder to do necessary changes. While tests are usually a good enabler for safe and fast change I would argue that testing can be taken too far. The test code should also be open to change. Specifically, remember to refactor the tests so that they don’t become a dumping ground for outdated application specifications. Make the app maintainable.

In conclusion, if you can maintain the code you can fix it. Though be mindful that those changes don’t complicate future changes.

Stay nimble, dear code poet.