Engineers hate sloppy code. It’s hard to understand, harder to change, and even harder to scale.
But show me an organization that doesn’t have a gnarly code base. At Google, where engineers are brilliant and know how to write good code, it still takes them something like six months to get comfortable making even simple changes.
And that’s a problem. Because arguably, from Day 1, code quality is right up there with serving the right product to your customers.
This is because the engineers who contribute to the code base are the customers of the code base. And unless someone is trying to hear and address their needs, there are a few ramifications:
- Poor retention
- Lengthy on-boarding
- Slower scaling
The highest stakes? Recruitment and retention.
People get really frustrated having to contribute to something that’s hard to work with. If it takes ten hours to get Feature X into one code base when it could take an hour somewhere else, that’s not great for morale.
So how do we prevent this?
Ideally, you have someone keeping your code in good shape the moment you start writing it.
Because it gets exponentially harder as an organization grows.
Now, let’s say you have 30 engineers in your organization. Ideally, you’d have a couple of cross-functional team members, with background in all elements of coding your products touch – whether that’s frontend, backend, mobile, iOS, etc. These are folks that are willing to take on the more thorny issues. Make taming the code base their sole purpose, and you’ll avoid a lot of code rot.
“But I don’t have the funds to clean up the code base. I need to ship features to my customers!”
You don’t need to address all the issue immediately, but you need to have a plan in place. You may not have a shovel, but you need a spoon. You have to make forward, incremental progress, otherwise the time and energy it takes to add even simple features to the code base will grind to a halt.
So yes – it may seem like you’re shipping some features later than you wanted do. But if your developers quit, we promise that’ll delay your roadmap a whole lot more.
How should code base NPS be measured?
While a pure Net Promoter Score (NPS) is useful here (i.e. “Would you recommend this code base to a prospective employee?”), we think companies should use a couple of others to triangulate:
How long does it take for a new employee to get up to speed? In our opinion, this shouldn’t exceed 2-4 weeks – though this obviously changes based on logic and components. But pick a number – because ideally, it should never change. If it does, that’s a sign you need some cleanup.
How comfortable are engineers making changes after X number of days on the job? This should generally reflect your NPS score.
Imagine: You’re new to a job and the code base has architectural changes that are alien to you, because you’ve never made those changes in his work. And deployment in particular is a huge hole – and there’s fear behind it. Fear that your peers will break the website if they deploy.
This is terrible for morale – and not great for productivity either. Engineers are at their best when they have the freedom and creativity to solve problems, and a complex, restrictive code base doesn’t allow for that.
With a solid code base, anyone should be able to kick off a deployment. Whether it goes to production is another story, but it needs to be easy. The moment your developers are afraid of breaking the website, they start being less productive. They’ll be thinking about whether a seemingly benign change will break the website – is what I’m doing safe? These should be two separate questions.
So how can larger organizations improve their code base NPS?
It depends who you are. If you’re the CEO or CTO, you either need to take the lead, or pick someone from your organization who will be your right hand person in implementing a code base”tiger team”.
The first thing to do is establish guidelines for what’s acceptable.
- What metrics will you use to measure on-boarding?
- How will you measure ongoing code base satisfaction? (which, btw, is a really good predictor of employee satisfaction)
Once you have the metrics in place, build your team – and this will depends on the size of the organization. With 500 engineers, 1 person won’t cut it. So pick up a team from different parts of the org, and make sure the code base is super usable based on those NPS metrics.
Remember, your code base is the product you’re building for your engineers & future engineers. It needs to be something they feel happy working with.