Marie Kondo is that Japanese woman who became famous with her method for reaching a tidy home and a tidy life.
Her method can be summed up as:
Throw away most of your shit.
You don't really need it. It's holding you back. It adds to your mental load, it bloats your life and living space.
Everything that doesn't make you happy (or is very useful) must be thrown away.
It's hard to describe how liberating it feels to just have less. It's a feeling very few people will ever actually experience.
But as humans, we are anxious creatures afraid of scarcity. So the act of throwing stuff away can be very difficult.
Why is it so hard, and why is it also so important? Let's discuss.
Is it really that important?
Yes. But you can't really know this if you never experimented both sides: the clean and the dirty. As I explain in this article about the technical debt, most developers never worked in the clean and don't understand just how huge the difference feels.
Just as throwing your shit away is important for living in a clean space, throwing your code away is important for working on a clean, debt-free codebase.
Removing a line of code is much harder than adding one.
Blaise Pascal (not Mark Twain) wrote :
If I had more time, I would have written a shorter letter.
The best code is short, DRY and simple. The least good code is long, repetitive and complex.
Adding code is easy. You have a need, you just throw code at it until the problem disappears. But more code means more maintenance, more bugs, more complexity, more problems.
Removing code is hard. You need to either accept that your need won't be fulfilled, or you have to write the best, shortest, most elegant code to fulfill that need.
No code means no problems.
You're not really throwing anything away.
Are you using Git? If not, stop reading this and go implement Git.
If you're using Git correctly, then you have a trace of every line of code ever written in your codebase.
Many developers will complain that it is hard to find deleted code because their Git history is a mess. When we dig to find out why they can't keep a clean commit history, we soon realize it's because their codebase is a mess.
Don't be a victim of tautology. A messy kitchen only attracts more mess. Break the cycle and be free.
Marketing VS Technical
The marketing like new features, and for good reasons. New features are good. They supposedly attract new clients, and new clients are good. More clients means more money, and money is good.
Experimenting and changing to see what works and what doesn't is a great way to develop your product and achieve success. But adding a feature is like buying an air-fryer: there is a risk that you actually won't be using it.
So adding stuff is great, but you have to follow rules:
Dont add crap to your app. Add clean, well-coded, well-polished small features. Go for a good little MVP (Minimum Viable Product), don't go for the huge, badly-hacked feature.
You can't keep adding stuff if you don't remove stuff. If a feature is not used by a majority of your users, you probably want to just throw it away.
Conclusion
This article was originally about 1000 words, but since I had some time, I made it under 600.
Throw your shit away, today.
Also available on my blog
If you want to thank me, coffee
Latest comments (27)
Re "marketing vs technical": you can, with careful architecting and good practices, satisfy both demands by implementing features in a modular way where they can be cleanly and transparently removed as they fall off the roadmap. Submodules are great for this, with the right interface rigor. "How hard will this be to re-enable if need be?" is a good question to ask yourself, and sooner rather than later; entropy only increases.
Seems a bit dubious to me. Sure you can do quality and quantity if you're good; but the trade-off still exists, albeit it will be more subtle, and especially if you have short deadlines.
Now that Marie Kondo has overcome her tidying habits, this post may be in need of refreshing... or not.
format c:\
Nice article. Thanks Samuel.
I JUST LOVED this article <3
I totally agree with this statement, but it also depends on the language/ecosystem you're working with. In the Elm language community, it's very easy for us to remove dead code, as explained in this article: jfmengels.net/safe-dead-code-removal/ (disclosure: it's my article and my tool behind it). The biggest blocker that remains is, as you mentioned, the developer's fear of throwing code away because it's too hard to find it back if you need it again (which in my experience, is extremely rarely needed).
Oh this is so true! Thanks for this article 🎉 I know a few colleagues that should read this.
Also comparing features to an air-fryer : SPOT ON 👌
A friend says that it's funnier to delete old code than write new code
I think it's easy to get carried away with minimalism. It always feels good to make things simpler because it decreases the mental load on awareness, memory, comprehension, etc. Looking at nature is a good example. Nature can be quite complex. The human body is complex, ecosystems are complex. But usually, if not meddled with by us humans, nature loses inefficiencies. It does't make it simple or easy to understand. It's that things that have no value are lost. I think that's the way we should design things. Strive for elegance, symmetry, multi-purpose where possible. If the requirements are complex the solution will be complex. That's okay. That's how it has to be.
nature bad
If it doesnt spark joy.
rm -rf */DROP DATABASEin production.I imagined Marie Kondo coming to my computer, taking an overview to my Projects folder and let my console start point at Projects/ while adding
alias cd='rm -rf'😆Laugh will be sin! 😂 this joke make me crying! Oh shit!
I can have so much fun with this.
Mostly good suggestions here ;D
based