Take back control of your code quality

Wow, it’s amazing. There’s so many of you. How exciting.

I’ve been leading software development teams for over two decades and I work as a CTO coach and advisor and so I’ve worked with many, many engineering teams over the years.

And all too often I find that the engineering team ends up in a tug of war against the rest of the company. You have engineering and they’re pulling really hard in one direction. They’re saying, we must slow down. We must focus on our code quality. We must keep our development sustainable. And on the other side, you’ve got product, marketing, design, um, sales, all pulling, going, we must go faster. We must make the company a success. And loads of effort and energy goes into this tug of war.

Both sides feel like they need to defend themselves, like their expertise is not being respected, like they’re not being supported. Neither engineering nor the other disciplines feel like they’re being listened to. And yet we’re all trying to make this a success.

This often results in code bases that are hard to change, where it’s really difficult to be productive and teams that are no fun to work in.

Our responsibility as engineering leaders is not just about bringing technical expertise to our companies. It’s about creating alignment and trust between our teams and the rest of the business so they can work together more effectively.

We need to find a way of stopping pulling against one another and feel like we’re working side by side on the same problem.

This is not easy. In this talk, I’m going to share some of the perspectives and practices that have helped me and the teams I’ve worked with build trust and bridge this gap.

High quality code is code that is easy to keep changing.

This is the definition of high quality code that keeps you aligned with the rest of the business. And I think it’s the only definition that matters.

It doesn’t matter if you have a microservices architecture or a monolith. It doesn’t matter if you’re using a functional programming language or an object orientated programming language. It doesn’t matter if you’ve got a hundred percent test coverage or not. It doesn’t matter if you’ve written your code to scale to a billion users, unless of course you have a billion users.

What matters is that your code is easy to keep changing.

I want to show you some made up graphs to help illustrate why this is so important.

The first made up graph is for a typical software development project.

With time along the horizontal axis and pace of delivery on the vertical axis.

To begin with, it’s a greenfield project. It’s exciting for you and your team. You’re delivering lots, but slowly the coat base becomes larger and more complex and more brittle and it becomes harder and harder to make changes. You and your team start to feel like you’re wadding through mud. And to begin with, it’s at your ankles and then it’s at your knees, and then it’s at your waist and it’s at your chest and your team is working harder than ever and making less progress than ever. The pace becomes glacial. Other teams lose faith in your ability to deliver.

I’ve been responsible for projects like this.

Let’s contrast this with another software development project. The blue line on the graphs above represents this much higher quality code base.

You’ll notice that the pace of delivery is slower to begin with.

You and your team are focusing more on code quality to make it easy to build on the code that you are writing. There’s a much greater focus on refactoring and things. And this enables you and your team to maintain that pace forever.

Taking this approach makes us and our teams feel smarter and we’re able to deliver far more. Everybody wins.

I haven’t put scales on these graphs, but in my experience that crossover point happens much sooner than we expect. Typically happens hours or days or weeks into a project rather than months or years.

How long is the code base you and your team are working on, been around? How long are you planning for it to be around?

You need to be heading along that blue line, if it’s months or years.

You don’t have time to develop low quality code.

High quality code enables you to go fast forever.

Code quality is invisible to the rest of the company. So it’s our responsibility as engineers to make sure we do this. Our company expects us to do this. They trust us to do this.

The graphs I showed implied that it’s a single decision at the beginning of the project, develop lower quality code or higher quality code.

But that’s not quite true. We face this choice every time we make a change to our code base. And every time there is a temptation to go a little bit faster today and pay for it forever.

I’m going to share with you some of the practices that help us build trust and the discipline to keep us on the path to high quality code.

We can apply this rule to code. Improve your code quality with every change that you make, every commit, every pull, request, every feature.

This means that your team will be working on code quality all of the time. It’s part of what you do. It’s part of the cost of work.

And what counts as higher quality code is a judgement call. This will provoke some really interesting conversations in your teams about what it means for this code to be easier to change in future. These conversations will help develop a taste in your team for higher quality code.

The scout rule needs to be the norm if you’re gonna develop higher quality code.

Secondly, if your company is successful, there will always be many, many more good ideas for changes that you could make to your code than than you have time to implement, however big your team is.

It’s not about removing that pressure to go faster because that will always be there. It’s about thinking about how we respond to that pressure.

Do we immediately go, let’s just make the code lower quality, or do we negotiate on scope? Because cutting the amount that we are delivering is the only sustainable way to reliably deliver sooner.

When we’re asked can we go faster, we need to be asking ourselves this question, how can we deliver less and have a similar impact?

This gives us an opportunity to work creatively with other disciplines, with marketing, with sales, with product, with design, to come up with creative solutions to this problem.

It’s really important that we as engineers show that we’re on side with a goal, that we want to have the impact, that we understand the need for the impact. And it’s important that we listen to the ideas of other disciplines at this stage. If we listen to them, they’ll listen to us. This gives other disciplines agency. It means they’re not just faced with engineers that say, “no”, or engineers that silently sacrifice quality and later on complain that they’re drowning in technical debt.

More importantly, this often enables us to deliver sooner, to learn faster from our customers and build less. And our systems are easier to maintain if we build less code.

The last practice I want to share with you is quantifying your case for change.

Inevitably, however good you are at those previous practices, there will be times when you need to make bigger changes to improve the quality of your code base.

Like Sahana said in her earlier talk, you need to think about the impact of this.

High quality code is about enabling us to go faster. What are we prepared to invest? This is typically measure in time for engineers. It’s one of the most valuable things in your company. And what are you going to get in return? Again, typically this is saving the engineering team time.

It’s okay that these are estimates you don’t know the exact answers to how long something’s going take or how much time it will save, but it’s really important that you make these estimates. If you don’t make them, other people will assume the impact is zero or negligible. So you need to fill in that gap.

Think of it as a bet and making these will build trust and get other disciplines onside.

This will get your work on the roadmap. This isn’t a separate technical roadmap and I encourage you to start small to build trust.

Start with something that is two weeks rather than six months of investment you’re asking for.

To round up.

High quality code is easy to keep changing and it enables you to go fast forever.

There are three practices that will support you with this

1. The scout rule
2. Negotiate on scope, not quality
3. Quantify your case for change

Take a moment now to have a think. What can you do to take some of these perspectives and practices back to your teams and help them feel more supported and to go fast forever?

Thank you very much for listening.