Decouple to delete by Mark Seemann
Don't try to predict the future.
Do you know why it's called spaghetti code? It's a palatable metaphor. You may start with a single spaghetto, but usually, as you wind your fork around it, the whole dish follows along. Unless you're careful, eating spaghetti can be a mess.
Spaghetti code is tangled and everything is directly or transitively connected to everything else. As you try to edit the code, every change you make affects other code. Fix one thing and another thing breaks, cascading through the code base.
I was recently reading Clean Architecture, and as Robert C. Martin was explaining the Dependency Inversion Principle for the umpteenth time, my brain made a new connection. To be clear: Connecting (coupling) code is bad, but connecting ideas is good.
What a tangled web we weave #
It's impractical to write code that depends on nothing else. Most code will call other code, which again calls other code. It behoves us, though, to be careful that the web of dependencies don't get too tangled.
Imagine a code base where the dependency graph looks like this:
Think of each node as a unit of code; a class or a module. While a dependency graph is a directed graph, I didn't indicate the directions. Imagine that most edges point both ways, so that the nodes are interdependent. In other ways, the graph has cycles. This is not uncommon in C# code.
Pick any node in such a graph, and chances are that other nodes depend on it. This makes it hard to make changes to the code in that node, because a change may affect the code that depends on it. As you try to fix the depending code, that change, too, ripples through the network.
This already explains why tight coupling is problematic.
It is difficult to make predictions, especially about the future #
When you write source code, you might be tempted to try to take into account future needs and requirements. There may be a historical explanation for that tendency.
"That is, once it was a sign of failure to change product code. You should have gotten it right the first time."
In the days of punchcards, you had to schedule time to use a computer. If you made a mistake in your program, you typically didn't have time to fix it during your timeslot. A mistake could easily cost you days as you scrambled to schedule a new time. Not surprisingly, emphasis was on correctness.
With this mindset, it's natural to attempt to future-proof code.
YAGNI #
With interactive development environments you can get rapid feedback. If you make a mistake, change the code and observe the outcome. Don't add code because you think that you might need it later. You probably will not.
While you should avoid speculative generality, that alone is no guarantee of clean code. Unless you're careful, you can easily make a mess by tightly coupling different parts of your code base.
How do produce a code base that is as easy to change as possible?
Write code that is easy to delete #
Write code that is easy to change. The ultimate change you can make is to delete code. After that, you can write something else that better does what you need.
"A system where you can delete parts without rewriting others is often called loosely coupled"
I don't mean that you should always delete code in order to make changes, but often, looking at extremes can provide insights into less extreme cases.
When you have a tangled web as shown above, most of the code is coupled to other parts. If you delete a node, then you break something else. You'd think that deleting code is the easiest thing in the world, but it's not.
What if, on the other hand, you have smaller clusters of nodes that are independent?
If your dependency graph looks like this, you can at least delete each of the 'islands' without impacting the other sub-graphs.
Writing code that is easy to delete may be a good idea, but even that is easier said that done. Loose coupling is, once more, key to good architecture.
Add something better #
Once you've deleted a cluster of code, you have the opportunity to add something that is even less coupled than the island you deleted.
If you add new code that is less coupled than the code you deleted, it's even easier to delete again.
Conclusion #
Coupling is a key factor in code organisation. Tightly coupled code is difficult to change. Loosely coupled code is easier to change. As a thought experiment, consider how difficult it would be to delete a particular piece of code. The easier it is to delete the code, the less coupled it is.
Deleting a small piece of code to add new code in its stead is the ultimate change. You can often get by with a less radical edit, but if all else fails, delete part of your code base and start over. The less coupled the code is, the easier it is to change.
