A couple of weeks ago I did a talk on Minimalism in software development at a meet-up hosted by the London Software Craftsmanship Community . This subject has been on my mind for a few months now and it was the first talk in which I wasn’t addressing a particular technology but software in general so naturally, I was a bit nervous. But since the talk went pretty well I decided to turn into a blog post. Here it goes.
What is minimalism?
It all started with when I moved countries almost 3 years ago and I suddenly had to fit all of my belongings in two suitcases and then into a tiny room in East London. This was followed by other 4 moves in different areas across London and every time I found myself giving up on clothing items, books, small furniture and other things that I just accumulated but didn’t actually need. I eventually gave up buying too much stuff altogether and decided to invest in travelling and building a nice savings account. Nowadays everything we own can fit in a car and if we decide that in a couple of hours we want to move to France, I’m pretty sure that’d be doable.
Nice story, but what’s your point?
The point is that minimalism is a mindset, a tool that you can adapt to different situations and areas to gain clarity, freedom and simplicity by removing any distractions or clutter. It brings instead efficiency and creativity, it help avoiding debt and the stress of keeping up with the Jonas by saying no to consumerism.
For me it was about bringing freedom to travel and move rather than worrying where to fit 20 pairs of shoes.
But most importantly it’s a about intentionality : choosing to free yourself of too many possessions to make room for things of higher value. Surely you might ask: “But how am I going to be the next Steve Jobs if I back out from competition and ambition? Money is important after all.” And I would say that is a very valid point, but it turn out Steve Jobs was a minimalist himself : he had several copies of his favourite turtleneck sweater (and mind you, we’re talking about expensive, cashmere Issey Miyake turtlenecks) and his home had almost no furniture although he lived in a very nice neighbourhood. His mindset was clearly reflected and Apple’s products: simple, yet very sophisticated with a passion for high quality design.
In the recent years minimalism has become almost trendy thanks to the increasing popularity of the Scandinavian interior design style and big names in fashion.
What isn’t minimalism?
It’s not a set of strict rules like “You mustn’t own a car, you should only have five t-shirts etc.” , it’s not just restrictions or a goal in itself. One does not just adopt minimalism for the sake of minimalism but to obtain something valuable such as time , experiences or just some headspace.
Minimalism in software development
Finally, back to our point. Seeing that minimalism can be applied in art, architecture, music, fashion, design and in the day to day to life I thought why not software as well?
I believe that there some principles we can borrow to obtain positive results such as less yak shaving, therefore more efficiency, maintainable code, less budget leaks and happier employees. It turns out the idea isn’t really new, a group of people came up with something called “The Minifest” a while ago and even in the agile methodologies there are ideas that can be considered minimalist.
These are all sensible and good ideas to follows but let’s extend them a bit and see how they can be implemented in a pragmatic fashion. And software isn’t only code itself but also resources, people and processes so let’s examine each of these.
Code level – micro
The practical things a developer can do are: refactor, refactor, refactor, using coding guidelines, applying principles such as KISS and YAGNI as they all come to the same conclusion – simple is better. Also, don’t hack it but don’t be a smarty pants either: eliminate overkill or CV-driven development. Develop in small iterations, get quick feedback, fail fast and get ready to throw your work in the bin and start all over again.
Code level – macro
And by this I mean code at team or organisation level, not just an individual. As a team let’s get rid of too many repo’s with code that has been retired, POC’s or training exercises for new employees or interns. Archive or delete them altogether and the next developer who will have to search for the uses of a certain dll in the entire codebase will thank you. Declutter as much as possible : unclosed pull requests, branches from years ago , millions of useless info logs that take up space and money need to go. Even using too many technologies , tools and programming languages just because they’re trendy but don’t actually fit the purpose can be bad for your organisation in the long term. CV driven development is not sustainable and our teams are only as strong as their weakest member is. If a technology is not widely understood among the team and only one lone ranger is using it there might be a problem somewhere.
Also, fighting too many battles at once can prove itself harmful. In war, as in business, resources are limited and it’s always about who obtains most results with minimum effort. If you’re going to split your army and make them fight on every front you’re in for a defeat. You probably won’t win every every client you pitch or launch versions of your app for every platform out there, so pick your battles.
Conflicting ideas from tech leads and architects (in larger organisations) might prove stressful for developers especially if they rotate in teams. Unity and collaboration between leaders, the business and IT is essential in order to produce quality software.
A few things that help in organisation with lots of teams and projects:
- APIs – a unified way of accessing and exposing resources means you can plug in any type of UI and have multiple teams work on things on parallel: mobile apps, responsive website and back-end development can all happen at once without too many surprises at integration time.
- Libraries, modules commonly used across the company – it can be a front-end library that leads to coherence across products and applications or a services dll that can be reused and would cut down development time.
I’ll keep it short and sweet with this one as it’s not really my field of expertise, so I’ll just point out to these things:
- Don’t use servers too powerful for what they’re meant to do
- Not all environments were created equal – if your team is not spread across lots of time zones maybe switch off those test machines during the night to cut some costs
- Do regular clean-up on file servers
- And take it to the cloud , but make sure you use plans that actually charge you for what you use and not more
Third parties, licenses, vendors etc.
Keep an eye on unused tools, licenses or subscriptions, contracts with vendors that haven’t been reviewed or renegotiated in a while and of course, use third parties when it’s easier and better than building things in-house.
Opt for little bureaucracy, agile methodologies and eliminate any internal process that could slow down or frustrate employees without bringing any value.
All these for what, you say? Well surely, not just for the sake of doing them because we read it in a blog post. But to make better software, create room for efficiency, headspace and innovation, better usage of budgets and a better company culture.
Thanks for making it this far!