As developers, it can be fun and interesting to try to solve all the problems and write “elegant” and “clever” solutions to simple problems. In many cases, these clever solutions are attempts to solve for every eventuality. They over reach and represent someone’s (usually inaccurate) prediction of the future. More often than not, the predicted future and actual future are vastly different from one another. Instead of trying to solve problems we may never have, what if instead, we focused on solving the exact problem at hand and created the cleanest, most “deletable” version of the solution we can come up with?
Why focus on “deletable” code, you ask? To minimize the blast radius when things change. If I can delete a feature in a code base with minimal impact on the surrounding code, that means the code has been written in a way that is contained and loosely coupled to the rest of the code. This also means the code was probably easy to test and tests will make refactoring faster and safer. This “deletable” code is also probably relatively easy for other developers to understand, meaning it’ll be easier to onboard new team members and share the work. Finally, if I can delete the code with minimal impact, I should also be able to replace it wholesale with minimal impact if things change drastically enough that it’s no longer a matter of refactoring what’s already in place.
We talk a lot about tech debt as developers, but I think a more appropriate term is “complexity risk”. When things are too complex, the risk of a small change breaking all the things grows. It slows down progress and leads to those parts of a code base that nobody wants to touch because nobody knows how dangerous it will be.