Stop "maintaining" your software

[Zooce]

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 I hear, "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 more about the ability to handle many scenarios, whereas changeability is more about the ability to change direction entirely.

How many times have you had to fix a bug or add a new feature to code that was just too rigid and fragile in its ways, you had no choice but to duct tape your solution to it? I bet the answer isn't 0.

So, how do we design for changeability?

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 valuable than the others - take the big pieces and sweep the crumbs 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 specifically on solving 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.

When you have more than one responsibility then you must also manage the coordination between them, which means you have yet another responsibility on top of your other responsibilities. Same goes for your software.

[Zooce]

HEY World