We've all heard it, "design for maintainability" and "once we're in maintenance mode..." What exactly do we mean by this? When I hear this it sounds like, "let's keep our software exactly how it is" and "don't change it." In fact, I think this is exactly what we mean, but for some reason we subconsciously tell ourselves something slightly different.
This contradicts a fundamental attribute of software; change.
What we should be saying is "design for changeability." We want to be able to easily change our software at any time.
Before I go any further, if the word "flexibility" is coming to mind right now then ignore it. Although the word flexibility is about change it is not the same as changeability in the context I'm talking about. Flexibility in software is often abused as a “future proofing” mechanism (which is also bullshit unless your crystal ball is working), whereas changeability is more about the ease of modifying it later.
So, how do you design for changeability? I can give you two core concepts (I’m sure there are more, but these two alone can be very powerful).
Solve your problem
It all starts with understanding your problem and limiting your solution to only the essential parts of that problem. Inevitably, every problem can be broken down into bite-sized pieces and when you do this you'll see which of those pieces are more important than the others - keep the important parts and sweep the rest into the dustpan.
When you solve more than you need to, you add unnecessary complexity to your system and if you keep doing this then your system will become adverse to change.
Be focused
When designing the architecture of your solution keep the parts focused on solving only their part of the problem. Never give any of the parts more than one responsibility. For example, if the thing manages a piece of data and glues some other things together, take the glue part out and give that responsibility to another part of the architecture.
Everything interesting has many complexities. Manage these complexities by isolating them.
Everything interesting has many complexities. Manage these complexities by isolating them.