Brighton Ruby 2023: A Cleo Perspective
In June, Cleo sent eight engineers to Brighton Ruby. Sachin outlines the trip.
This is some text inside of a div block with Cleo CTA
CTASigning up takes 2 minutes. Scan this QR code to send the app to your phone.
At Cleo we think that the deliberate, conscious and careful accumulation of tech debt is a powerful tool that lets us ship code and value to our users faster. Fell explains how we manage our technical debt.
This blog post is intended for an audience that’s at least superficially familiar with the concept of technical debt, as well as with the concept of interest rates. If you know what both of those things are, then this blog post is for you. If you’re not, I’ve linked some short explanations of both above; reading them should give you enough information to understand the ideas I’m about to talk about.
In order to understand what interest means on technical debt, I’m going to give an example of high interest technical debt, and then an example of low interest technical debt, so we can contrast the two.
In high interest technical debt, everyone who works in an area of the code base (sometimes other than a handful of Hero Developers) comes to fear working with a particular piece of code, but can’t avoid doing so. These are often God Objects, but not always; sometimes they’re an API whose interface doesn’t well match its intended use, or a piece of business logic that’s both highly complex and regularly updated (the Gilded Rose kata is an example of this kind of code). This isn’t an exhaustive list, either: there’s many ways code can become high interest technical debt, but the defining features are always the same two things:
Low interest technical debt can feel the same as high interest technical debt when you’re working in the area. It’s slow and painful to deal with, and can be very complicated. But the key difference is that in low interest technical debt, working with the code can often be over briefly, or avoided entirely. This can be a complicated piece of business logic that has a well defined interface and rarely changes, or a God Object whose time as a deity is ending as its responsibilities are separated into smaller, more mortal objects. The defining features of low interest technical debt are:
These aren’t static categories that code will be in forever. Whilst a new feature is being built, technical debt in the area may be very high interest, but fast forward to when the feature is released and it may be low interest for a time, whilst the team observes and measures the performance of their work. Alternatively, a core piece of business functionality that is owned by a single team who understand it well may be low interest; but if that feature becomes widely used across the team to promote other features, the interest rate can quickly spiral out of control.
If you want something to measure in simple terms, you can keep track of how long it takes to make a change compared to how long that change would take in a vacuum, with nothing to work through slowing you down.
There’s a lot written on different approaches to how to solve technical debt; going through different approaches is a topic for another blogpost, so in this one I’m going to be fairly opinionated and put forward the way I like the most here at Cleo. In other engineering cultures, other approaches might suit you; this is very much a suggestion for a delivery focussed culture that accepts tech debt as a valuable and useful tool.
Because debt is a well-studied (yes, we’re a finance app) and well understood system, there’s a variety of good explanations on alternative ways to mitigate financial debt. I believe that for technical debt the avalanche method is the most effective: that means that you pay off the highest interest debt first, working your way through the debt methodically. This isn’t a hard and fast rule; the easiest technical debt to solve is the one in the code you’re working on right now, but it’s a useful thing to keep in mind if you’re looking for a way to prioritise.
The reason for this is fairly simple: High interest technical debt regularly costs you, and low interest technical debt rarely does, or costs you less when you pay the interest.
In contrast to finance, having no technical debt isn’t possible (or even desirable, as we discuss in our engineering principles). However, reducing the cost of high interest technical debt to your team can make a world of difference, particularly if you pay down the debt when you’re paying the interest anyway. This means if you’re trying to change a piece of code that’s high interest, think about how you can leave it better than you find it, and whether now is the right time to make it better; after all, you’ll be dealing with it again soon enough.
In June, Cleo sent eight engineers to Brighton Ruby. Sachin outlines the trip.
Josh, Tech Lead, dives into what he looks for when reviewing pull requests at Cleo. If you're looking to write code that scales better, this is a must read.