It is not too good to be true
In 2019 the 20% highest performing software teams had 106 times shorter lead time, 2,604 times faster time to recover from incidents, 7 times lower change failure rate, while deploying 208 times as often, compared to the 12% lowest performing teams. This according to the State of DevOps 2019 report. Some performance factors found are code maintainability, automated testing and loosely coupled architecture. So why is not more effort put into creating codebases that are easy to work with? I believe that some answers can be found on my messy desk.
One parallel between tidy software and a tidy home is about identity. What life do we imagine is possible for us?
The KonMari method for tidying your home talks about the importance of imagining where you want to end up. When you are done with the KonMari method your home “go click”. Then you have changed as a person and will never relapse into messiness again. (You will still need to clean, but it will be much easier.)
So first you get to dream up the life you want to live, get the tools to achieve it and grow into a person who can maintain it. Each step of the KonMari journey is a part of that transformation.
There are software developers thinking that Test Driven Development is a unicorn, that everyone dream of but no-one has really seen. Software deteriorate, even rot, over time, it is said. People see it as inevitable, at least for them. The role models for quality code in real projects are few. That makes it harder to know what we could experience if things were better. Still the DORA DevOps report shows us that there is a real differentiation in the industry. The gap is not only between the highest and the lowest performing teams. Some move quicker than all of the rest and get better results. But do we believe we could be like them?
We need to start dreaming about excellence. Our identity has to shift to encompass the belief that software can be written differently than it is today. It might hurt to think of all the pain we suffered before, when we learn a skill that makes our life easier. It might be scary to imagine all the business decisions we need to make when the technology is no longer holding us back. I was once afraid of a clean kitchen counter, since it left me without something obvious to blame for … anything actually. But we can not let fear hold us back!
Just doing more of the same we have always done won’t work either. Getting rid of one item of clothing every day for December won’t change our buying habits more than any other such challenge. The clutter comes from how we relate to ourselves, each other and our belongings. The same goes for our code. And just as Marie Kondo also teaches folding, organising and storing, there are concrete skills to learn that make writing tidy code easier. But it has to come with a shift in perspective on improvement. It is not about remembering to write unit tests, it is about learning how to test drive code so that the architecture improve. We do not simply have to remember to document the code, instead it is about how we see carrying domain information as a part of the codes purpose. There is a difference between cleaning more often and creating structural change to make cleaning easier. It still does not require a rewrite of the entire codebase, or you moving to a new home, but we need to do something else than what has failed before.
To know what we are aiming for we need to dare to imagine a world where writing code is fun and pain free. We need to believe that we can be part of such a world. Then it will be easier to learn and grow so that we can reach that goal. In contrast to KonMari, best done alone, changing how we write software is a team, community and industry effort. We need a bigger dream, of a brighter future, and believe that we can get there. Please join me!
ps. My home still has some way to go before it “go click” but I will re-read Spark Joy by Marie Kondo to get back on track.
Comments
1. David Ruffner
I'm curious about how far the analogy goes between tidying and coding. Can we get rid of code that doesn't spark joy? Sometimes the differences are meaningful. Tidying is done alone, but coding as a team. But then the team should be allowed to code "alone", without too much micromanagement.
2. EsterDaniel Ytterbrink
I think that we can get rid of most code that does not spark joy. In KonMari there are also things we must keep that do not spark joy, as important papers. They are then kept in a way that minimise the damage they do. Micromanagement is not the way to keep the code clean. I believe in collaboration and intense knowledge sharing. Most of all I think that the change comes when we start to believe that we deserve well written code and that we can achieve it.
Offer
SAMMAN TECHNICAL TRAINING
Send your team to a course and some of them will remember part of it. Use the Samman method and they will apply what they learn from day one.
Book a meeting if you want to talk to me about DevOps to explore how I might help your team. I offer this for free, since I rather talk tech than do sales pitches. Let's explore if I can help you, by trying to solve your problems from the start.
Comment on the blog!
Create a comment by emailing me.
Open an email to start writing.I will then add the comment to the post.