Design Code Like It Will Be Removed Tomorrow
In two of my most popular blog posts - "Collaborative Single Player Mode" and "Feature Planning", I mentioned one of my coding principles:
Write code as if you are going to remove it tomorrow.
I get a lot of questions about this. What do I mean by that?
When you write code for a new feature, you want it to be decoupled from other parts of your system. Put it in its own bucket - namespace, module, directory, etc. (depending on the technology). This makes the code easier to test and reduces the risk it will break existing functionality.
I have found that a good way to tell how decoupled some code is to find out how much work it would be to remove the feature it is powering. If removing a feature is just remove a folder + 2~3 integration points - that's good code.
Because of this, I prefer to organize code based on domain than on type.
But how often you remove features? 🤨
At Product Hunt, we do this quite often 😅 , and this is a good thing. When you do product development, you discover what works and what doesn't via experimentation.
But I spent so much work on this feature, and now my work goes to waste? 🙄
Not really. On the product level, you learned something, and hopefully, this will give you a better direction for future work.
Product logic gets simpler. Think about losing body fat.
But I had some really, really cool code there? 🥺
When I write code, I make a clear distinction between Plumbing vs. Domain. I have found that plumbing utilities are often where the "elegant" and "cool" code is.
This often happens to me. I build a feature and separate its plumbing utilities and domain. Then, for another feature, either me or a teammate use the utilities. Later, the original feature is removed, and the utilities stay.
If utilities are isolated, they are often re-used in different domains. So this cool code stays after the feature.
For any questions or comments, you can ping me on Twitter.