Take back control of your code quality


The best engineering leaders know that you can have both speed and quality when developing software. Indeed, the only way to keep up the pace of delivery is to build high quality software. Everybody wins.

However, all too often, it can feel like you are not in control of the quality of your code. You can feel like your team doesnโ€™t have time to develop high quality code. You can feel like you are forced to make a trade off between the quality of code and speed of development. And when you do you typically end up with neither.

How do you take back control of your code quality? How do you get your team and stakeholders to believe that this will enable you to develop faster? What practices do you need to put in place to make this true>

In this talk I illustrate the dynamics between team members and with stakeholders that lead teams to lose control of code quality.

And I share a set of practices and techniques that you can take away and use to support your team to take control of their code quality, deliver rapidly and keep stakeholders on your side.


Slide 001

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.

Slide 002

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, and sales, all pulling in the opposite direction and saying, “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.

Slide 003

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.

Slide 004

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.

Slide 005

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.

Slide 006

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.

Slide 007

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.

Slide 008
Firstly, the scouts have a rule, which is to always leave the campsite cleaner than when they arrived.
Slide 009

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.

Slide 010

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.

Slide 011

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.

Slide 012

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.

Slide 013

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.

Slide 014

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.

๐Ÿ“Š Slides

Download the slides

๐Ÿ‘ Thanks

Thanks to the whole team at LeadDev for all their support and to Marina, Nicky, Robbie and Sorrel for their invaluable feedback that improved this talk.

Further watching, reading and listening

โœ๏ธ Added transcript and slides in Feb '24