What is code easy to delete?
When you envision logic of an application as a combination of different elements (smaller logics), there is always a measure for a given element that expresses how interconnected it is within the application. That measure could be the number of places you need to adjust when deciding to remove an application’s component. Code easy to delete is the code (an element) connected in very few places, optimally only in one place. That means that if you decide to remove that code from your codebase, you delete it and adjust the application only in one place. The code is decoupled and separated from the rest of the application. We may also refer to that kind of logic as plug and play, which is usually the case with many libraries responsible for well-specified parts of the system.
Why is it useful?
If you are still envisioning the applications as a working system of different elements, you should think about it changing as time passes. What are the changes along the way required by the business? The issue with most applications implementing a business logic is that this logic, and the system along with it, always diverge and rarely or never converge. So, if you look at two elements in your system that have a similar sense and exist in two places, there is an excellent chance that business requirements will drive you to make them more different rather than more similar to each other. There is usually a far greater possibility that you will need to introduce some distinction and separate the logic than combines two different logics into one. Within that ever changing and ever diverging environment, you need to add, modify, and remove elements. Aside from that, you need to keep it clean and do it efficiently.
Let’s imagine that you have to add a logic, and then months later, you need to remove it. Usually, this is not easy when we consider the situation where this logic abundantly links to the rest of the application. With time, all those places may change independently, and simply reverting your adding commit will end up with lots of conflicts, and some of them may not be easy to resolve when the code was under constant development. That could be easier if the element you need to remove is less coupled with the system. In that case, the number of conflicts and the difficulty would decrease because less associated code usually has a more understandable API.
Another thing worth considering is the ability to ensure the quality of the code. One thing is to be able to easily remove a logic and a whole different story is modifying it. The best way to make sure your element works as desired is to create automated tests on different levels of your logic. When your code connects to the system in many places, you have to introduce more possible contexts to implement integration tests properly. If you don’t do this and skip any connection, you risk that an unrelated change in a different logic may affect yours and cause an unexpected behavior. As you see, it is usually easier to provide good quality when you have fewer possibilities to verify and cover with tests.
Are there any downsides?
Of course there are! And the same is true for many design patterns in the programming world. I think it is quite clear that each practice may be misused. You should consider applying a pattern to your solution and not your solution to the pattern because you can quickly lose the overview and implement something in a very suboptimal way.
When we consider a separated logic, one thing that comes to mind is the difficulty of making it aware of the general implementation’s behavior. For example, when you have your application and a separated element with a single integration point, and you need to synchronize it with the rest of the system, you may consider two solutions. The first one is to keep the logic separated, keep the code easy to delete and introduce a broader API for synchronization. The second one is to drop the separation idea and decide that coupling the logic within the system brings you more advantages than disadvantages. There is no silver bullet, but there is a lesson to be learned.
Tips for the future
The idea of code easy to delete may be very beneficial in a broad range of solutions. Hence, the most important thing to remember is to think about it when the time is right. When you consider adding something to your application and come up with a solution, you may think about the following ideas.
Think about the way that your logic connects to the general system. Examine whether you are diving too deep to make the elements cooperate. Consider the ability to remove that logic from the system. That could happen now or later after many changes from other programmers. Would that be easy then? Study your solution’s testability, especially at the integration level, where you usually find a straightforward API very convenient.
When you understand all of that, you can ask yourself whether your solution could be better separated or more coupled within the system and what benefits that could bring. Understanding the pros and cons of regarded solutions is the key here. Good luck!