I care about writing maintainable software1: code that is a pleasure to work with in the long-term; where new requirements can be accommodated smoothly and swiftly – above all, software that is easy to change.
Memorise that phrase.
I feel we lose sight of this overarching guiding principle and harm our codebases by dogmatically pursuing well-intentioned but proximate goals.
The main thing the future maintainer of your code (i.e. you) cares about is whether the code is easy to change2.
Software has two core values3:
Behaviour - What the software does. Working software must behave in a way that meets its requirements.
Design - The structure of software; how it is implemented. This will dictate how easy or expensive it is to adapt to changing requirements.
Maintainable software not only meets its requirements but is structured to ensure it is easy to change in the future.
This should be your aim. For each unit of code that you write, ask yourself:
Will this be easy to change in the future?
From this simple question, every principle, practice and pattern of “good” software design can be shaken out. Things like:
- Loose coupling.
- Simplicity (KISS, YAGNI).
- Don’t Repeat Yourself (DRY)
- Single Responsibility Principle (SRP), polymorphism and the rest of the SOLID principles.
- Accurate naming; readable code.
These are not goals in themselves - they exist to guide you towards your ultimate destination: writing easy-to-change software.
Beware of dogmatically pursuing these intermediate principles and patterns. Whilst they generally guide you in the right direction, they can be harmful if applied without thought.
For instance, relentlessly removing all duplication from a component can make it harder to change for future maintainers, through increased coupling and poor readability4.
In short, maintainable code is easy to change. This is the overarching principle that should inform your design decisions.
I work at Octopus Energy5, a UK energy supplier committed to driving more households to use renewable energy (all our tariffs are 100% renewable) and to have a more considered relationship with their energy consumption6.
Climate change is something I care deeply about and I have every intention of working for Octopus Energy for a long time. That means working with the same codebase for a long time and consequently, “maintainability”, ensuring the codebase is a pleasure to work with in the long term, is a primary focus of mine and the wider software engineering team.[return]
Don’t forget: deleting is a form of change. Code that is easy to delete is a gift to future maintainers.[return]
See, for example, The Clean Architecture by Robert C. Martin (page 14 especially).[return]
This is commonly seen in test suites, where some duplication of set-up code is often preferable to extracting everything.[return]
If you’re in the position to switch suppliers, check-out our Trust Pilot reviews and, if convinced, consider using this referral link to switch to us which will give you £50 free credit when your supply has switched.[return]
See, for example, our Agile tariff which uses half-hourly pricing to steer consumption away from the peak hours (of 4pm to 7pm) which put the most strain on the national grid.[return]