Most people who are connected with the software industry will have at least heard of the problem of software bloat. I have seen many bloated code bases, enough to know that bloat is a major contributor to the phenomenon of software entropy.
Bloated code bases can occur for a number of reasons, for example
- Language choice – for example using a high ceremony language like Java that naturally requires a lot lines to accomplish a task.
- Technology choice – for example using verbose XML based tooling or supporting modules with badly designed interfaces.
- Overly verbose implementation technique – for example using a complex OO Pattern rather than just doing the simplest thing possible.
- Cut and paste reuse of code
Figure 1. Scissors and glue, used for cut and paste coding
There are lots of blog posts and videos that explain in great detail how to write code in a more elegant way to reduce the problem of bloat. This is not one of those posts. Instead I want to talk about a more fundamental approach to the problem which can be summarised as:
Don't write code!
“What? Don’t write code, but I’m a software developer, I get paid to write code”. I hear you cry.
Well actually No. As a developer you should see your role as one of analysing and solving problems. It just so happens that we often solve business problems with code.
If you stop and think for a moment, I’m sure you will be able to recall instances from your career where months of work have gone into a feature that was demanded by someone that was actually rarely used in practice, if at all. And then never deleted. Which then sat in the codebase. Rotting.
Figure 2. A few bad apples.
Now imagine this multiplied out over the software industry, over time.
If only someone had pushed back on that feature request. If only the assumptions underlying the request had been tested in a minimal way before rushing to implementation. Think of the money that could have been saved and the time that could have been better used actually improving the code, product and business.
Minimalism
Minimalism is a world view that is rooted in the teachings of the Stoic philosophers. Without going into the details, living as a minimalist means to remove all the extraneous crud from ones life, to live with less material possessions. A philosophy which I find personally appealing.
As developers we should practice minimalism.
By this I don’t mean that you need to go live in a cave and dress in sackcloth like a hermit! I mean that we should take a minimalist approach to the craft of writing software. The most minimal implementation of a feature is to not implement the feature at all.
Figure 3. Hermans Hermits, a popular 1960s beat combo
Minimalist Tools
So how do we go about this in practice? Here are some simple tools that you can start to apply in your journey toward minimalist enlightenment.
YAGNI
“You ain’t gonna need it”. Ask yourself and your team all the time do we really need to do this? Unless the answer is yes, don’t do it.
Ask why five times
When someone is pushing for a feature keep asking why. Challenge assumptions down the line, if it turns out that there is logical justification then fine, but many times this process will result in you being able to reject unneeded code changes early on.
Can we do this without code?
Is there an alternative, simpler approach that doesn’t require code that will yield a similar result. For example if a small change in user behaviour could save 6 months of time coding for an edge case, then it should be a simple call to make.
Do the simplest thing possible
If it turns out that code is required, always opt for simplicity. That additional plugin code that you want to add just in case you need to extend later – Don’t do it! Chances are YAGNI!
Code is a Valuable Commodity
Once you adopt the mindset of minimal coding, the code that you do create should be valued more. Treat it with respect, write the minimal amount needed and write it well. Code deliberately and directly, avoid fluff and crud, prefer a direct procedural implementation.
Optimise for Delete
As Greg Young said in his talk on The Art of Destroying Software(1) “Don’t write any self-contained part of your system that would take more than a week for someone unfamiliar with it to rewrite from scratch”. In other words you should expect the code that you write to have a finite lifespan. Make it easy to remove from the system.
Figure 4. The delete key, use this.
Ken Thompson is quoted as saying: “One of my most productive days was throwing away 1,000 lines of code” (2). I like to bear this in mind as I’m coding. I also try as hard as I can to avoid writing the 1000 lines of code in the first place.
As a final reminder, I’ll sign off with this inspiring feng shui minimalist video. Happy (not) Coding!
About The Author
Peter Elger is the CEO of fourTheorem and co-author of AI as a Service – available through Manning Publications: https://www.manning.com/books/ai-as-a-service
Get in touch to share your thoughts.
