We engineers like to summarize design principles with initialisms such as DRY (Don't Repeat Yourself) , its newly popular cousin WET (Write Everything Twice), or YAGNI (You Aren't Gonna Need It), to name just a few.

I'm sure you can think of many conversations where one of these was invoked as an argument.

These rules typically originate from very valid ideas, and then are abused and tortured and eventually are shelved as False Good Ideas by jaded engineers. They spread because they're easy to remember and will generally make designs better if you design with them in mind.

I have this other rule for software design, which actually applies both for software (as in adding files/code paths etc.) and architecture (adding features, services, jobs, data stores, etc.):

Make it easy to delete

It's kind of an odd take at first sight, because if you are adding a feature or a piece of code, ya probably need it right? So why think about removing it before you've even added it?

Humor me for a second, and think about a piece of code you know about that would be easy to delete.

What makes it easy to delete? Probably something along the lines of:

1. there aren't that many places where you would need to delete code calling it, imports, etc.
2. the actual code is located in the same area, and you won't have to delete bits of dead code in a lot of random places

For code specifically, #2 can simply be a result of a sound way to structure files in the projects (maybe by feature), while #1 is where I think this design tip is useful.

If a piece of code does not need to be deleted from a lot of places (or at least deleting it is easy), it means it is not tightly coupled. Code that is loosely coupled will usually be easier and safer to delete.

This applies in a lot of areas. For example, if a service's method is triggered by RPC call as opposed to a pub sub queue, if you want to delete this service you now need to delete the RPC call everywhere. If the method is triggered by an event, then you may not even have to do anything.

"Make it easy to delete" is interesting because it's easy to reason about how much pain you'd have to go through if you needed to undo something.

Disclaimer: just like with every design principle, do not apply blindly