Software development and minimalism

About a year ago, I discovered The Minimalists. Their motto is “Live a meaningful life with less”. By that they mean less stuff, less clutter, with the idea that owning less stuff will make you less distracted thereby allowing you to focus on those things in your life that actually matter. This idea struck a chord with me, and I’ve been starting to apply it to my life and, without consciously realising it at first, I’ve been applying it to the way I think about software as well. In this post I will explain how.

Buying things

In their podcast episode on shopping the minimalists talk about buying things. What especially spoke to me in that episode is their advice that you should answer three questions when buying something:

1. Will this add value?
2. Can I afford this?
3. What is the true cost?

For software, you could ask these questions as well, but instead of answering them for buying things, you could answer them for adding features to a product (or creating a whole new product).

Translated to software development the first question, “Will this add value?”, can be interpreted as “Does this feature add value to the product as a whole?”. If not, you (probably) should not build it.

The second question, “Can I afford this?”, is about immediate costs of implementing the feature. If the feature adds value, but costs a lot to implement you might just be better off working on other features instead that produce more value. Additionally, even though you might be able to afford the costs of implementing a feature, also consider if there are cheaper options that would work just as fine, or maybe even better. For simple one-off jobs you really don’t need to create a full-fledged software project that takes several days or even weeks or months to build. Greg Young has a great talk on this subject: Stop over-engineering.

The third question, “What is the true cost?”, I think is one that a lot of people tend to forget to consider when adding a new feature. We might find that a certain feature will add value to our product and that we can afford the immediate costs, but what about the cost we need to pay once the feature is completed? For example, what if the feature requires some higher level architecture (think CQRS/ES) that only a few of the developers are able to work with effectively. Would you be willing to train other developers to get familiar with the architecture style in case they need to work on it as well?

Too often we only think about immediate costs when we think about adding features to our software, but the costs in the long run could be way more substantial and should always be taken into consideration when adding a new feature.

Owning things

The problem the minimalists point out with owning things is that a lot of the things you own don’t add any value to your life and in fact may even be harmful to your happiness. For one, you need to take the time to maintain them, which is time utterly wasted. Also they steal focus from other items that actually do add value to your life. Consider a drawer stuffed with miscellaneous items of which you use only a few. Every time you open that drawer to find one of those items you use you first need to wade through all the items you don’t, which probably causes frustration and causes you to think “I need to sort out the junk in this drawer”. If the drawer contained only the items that add value to your life and you got rid of all the other items, you would not have these problems.

The same thing goes for software. You need infrastructure to run it, you need to maintain the software and used third party libraries to avoid security issues, you need to pay for services the software integrates with, etc. So it would absolutely help to look through your software project every once in a while and see if everything that is in there is still serving a purpose. If it’s not, get rid of it, and save yourself the costs of maintaining something that does not add value to your product (anymore).

“Just in case”

The minimalists have a special category of items they call “Just in case” items. These are the items we keep around because we feel we might need them some day. For example some plastic plates and cutlery to use when camping even though you never go camping. These are the items we don’t think add value to our lives at this time, but they just might sometime in the future, and that’s why we hold on to them.

The minimalists have thought up a rule especially for these just in case items, called the ²⁰⁄₂₀ rule: If a given just in case item can be replaced in less than 20 minutes and for less than 20 dollars you should just get rid of it. If something is so easily replaceable you should not take on the maintenance of that item and clutter your life with it.

For software I think the just in case items manifest in two different ways:

Firstly, commented out or otherwise disabled code we keep around in our software because we might need it again in the future. You hardly ever do, but you do have to glance over it every time you read the code and wonder why that particular part of the code was disabled. Was it on purpose, or accidentally because somebody was debugging something and forgot to re-enable it at the end, etc? Instead of commenting out or disabling parts of the code, just get rid of it. If you ever need it again (hint: you won’t) there is always the history of your versioning system.

Secondly, there is the overcomplication of (new) features because some edge case might be needed later, and the overcomplication we’re adding to our feature would make that super easy. A lot of the times you don’t need to implement the edge case later on and you’re left with a piece of software that is overcomplicated for no reason at all. And for the cases that you do need to implement that edge case later, the time you need for that is most likely less than the time it would take to overcomplicate everything. Plus it leaves you with cleaner and nicer to read software if you don’t.

Beware that if there are strong indications from your client that a new feature will be required, or an existing feature will need to be altered in the foreseeable future in a particular way it is not a problem if you take this into account already as that is not a “just in case” scenario, but a “just for when” scenario; it is definitely going to happen in the future, but you just don’t know when yet.

Conclusion

Minimalism has had a meaningful impact on my life, and it has made a positive impact on how I think about software as well. My paraphrased motto of the minimalists applied to software development would be “Deliver meaningful software with less”. Less time, less effort, less code. But more impact.