Nobody cares about clean code.
Nobody.
You don’t, I don’t, your boss doesn’t, and your business model especially doesn’t.
I have three kids, two cats, a dog, and a spouse. We don’t really care about a clean house when the nights are frantic and we’re busy getting ready for the next day. After all, daughter #1 has soccer, daughter #2 has ballet, and daughter #3 (the 19 month old) acts like Jack-jack from Incredibles 2. When Saturday rolls around, we look around and realize. Oh god, we live in this mess?
And so we spend part of our Saturday setting things to rights.
We didn’t care about it when we probably should have, and as such had to spend part of our Saturday cleaning instead of having fun or preparing for the next week.
And next week, it starts all over again, and it’s this way throughout the school year. When summer rolls around, things quiet down and we pledge to do better next school year. Surprise, that lasts for all of about two weeks.
It’s not that we want to live in a messy house — we emphatically don’t. But, if the choice is ‘be ready for the next day’ or “not be ready for the next day and have a clean house”, we’re gonna punt on cleanliness, every time.
Your work is the same way. If you work in a feature factory (and there’s no judgment there, I’d expect that everyone reading this has worked in one at one time or another — they’re that common), then you’re going to frantically be implementing features for the business to demo and for sales to sell (or that they’ve already sold), and when that is done you get a few weeks where things quiet down before they start up again.
It’s the Saturday morning cleaning all over again.
Why can’t we break out of this cycle?
There’s a lot of value in a clean house. It’s easier to get ready for the next day, the overall level of stress is lower, and if something comes up that demands our immediate attention (like grabbing the kids shoes next to the door so we can get out of the house if it catches fire), we know that we’ll be ready.
A clean house enables us to improve our efficiency in getting ready for the next day, and the one after that, and the one after that.
But you can’t sell your boss on improved efficiency, not unless you can tie it to what they care about.
And until we can tie the work we do to something the boss cares about, it’s hard to sell continuous improvement in the form of Test Driven Development to ourselves, let alone our management teams.
Here’s a few of those things I’ve witnessed personally:
– Projects taking weeks to launch instead of several months
– Projects pivoting faster when the feature set needs changing
– No late night rollbacks due to a regression bug
– Decreased turnover
– Decreased bug count
– Happier customers
– Happier teams
– Going home at 5pm because you know your system won’t crash on you late at night
– reduced need for ‘on-call’ rotations for developers
– Improved revenue from being able to add features without increasing bug count and burdening support
When assessing importance, look for things that are tied to your KPIs or OKRs. If it’s written down, they care about it. If they have quarterly reviews about it, they care about it.
What’s important to you and your team? What’s important to your boss?