Simplicity

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?

What Does Deletable even mean?

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 testable code, complete with tests should make for faster and safer refactoring.

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 significantly. When the code is easy deletable, it can sometimes be less work to start from the beginning instead 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. If you optimize for “deletability”, you can reduce your overall complexity risk.