Ask “why”, not “why not”.
A year ago, I read a book on minimalism and the minimalist lifestyle. Maybe the most important takeaway was in correcting a misunderstanding that I (and a lot of people, probably) had about the philosophy of minimizing. For the longest time, a “minimalist” lifestyle to me meant giving up on all the material things in my life that actually brought me joy. No more computers, smartphones, or coffee machines: throw it all to the wind and cross your fingers that you’ll transcend untethered into a state of enlightenment.
That’s a big leap of faith to be making on a 3-hour audiobook. Luckily, it’s a bit more nuanced than that. The hypothesis isn’t that having stuff is making you miserable, it’s that having too much stuff is. If you’re like me, it turns out that belongings you have that actually bring you joy represent a small fraction of the teetering piles of junk accumulating in your house. The last step between this realization and downsizing is realizing that the stuff just hanging out in your attic or your basement or at the bottom of your closet is an active cognitive burden, not just a slight inconvenience when you change addresses.
So how does this relate to programming? The key word here is intentionality. Like extra clothes in the bottom of a closet or a box of broken electronics, old parts of your software have impacts that reach beyond the memory they take up on your system.
- Adding an external library creates a dependency that could prevent upgrades or cause security problems in the future
- Using bleeding-edge or fringe technology for a use case covered by your existing stack might increase developer overhead down the line.
- A feature with only a handful of customers on it still takes time and effort to maintain; otherwise, it can slip into disrepair and leave a bad impression with users that is far more impactful than the box you check just by having the feature.
- Dead code can cause dead ends and false leads for developers looking to fix bugs or new developers onboarding onto a large codebase.
And what’s the solution? If your codebase is already in this state, I think there’s plenty of literature on how to address it. Everything from bots that bug you to update your dependencies, to feature sunsetting discussions with your product team, to the do’s and don’ts of “the big refactor”. As they say, though, an ounce of prevention is worth a pound of cure: How do you stop your codebase from getting to this point in the first place? My snappy little idiom in this case is to ask why, NOT why not.
- Don’t ask “why not use this library”: even the sweetest dependencies are still dependencies. How much is a quality of life library worth tying you down to a certain version or browser, risking a compromised dependency, or adding performance overhead to your build?
- Don’t ask “why not build on this technology”: outside of some curmudgeons, software developers love playing with new toys. Unfortunately, the existing, boring technology will usually be better documented, have established best practices, and may even be more performant in a practical setting. Are you committed to keeping this tech running and do you really need it?
- Don’t ask “why not add / keep this feature”: software is never “done”, and all features have maintenance overhead. Keeping features broken is not an option in a good product. Will this feature provide value or are you just checking a box?
- Don’t ask “why not add / keep this code”: while it’s important to keep your design flexible to changing requirements, over-architecting with the sole impetus being anticipation of feature creep is a losing battle. There’s no better way to future-proof your software than to keep it simple enough to change without any catastrophic side effects. Is complex architecture actually going to make your life easier?
It’s worth mentioning that the answer might still point to keeping the feature, adding the library, or coding a more robust architecture. However, just by changing the phrasing of the sentence, from why not to why, we’ve made an important step towards making sure we act with intentionality. If we stay cautious and deliberate about the decisions we make early on in the life cycle of our product, we can prevent our code from turning into the software equivalent of an attic full of junk.
