Tech debt

When I joined Babylon in 2016, the codebase was in a dire state. A big chunk was done by engineers that came from different backgrounds. This meant that some patterns that might be popular in places like Ruby (and Ruby on Rails), were being used. As an example:

modelObject.update(with: network)

So the modelObject would take a network layer as input and update itself. For most iOS engineers this is foreign.

Throughout my tenure, we went from that, to a modern codebase using ReactiveSwift and something akin to SwiftUI. This refactoring was happening in tandem with a business growing quite rapidly. Both in revenue and users, but also company size. We started when we had 2 Product Managers, and we finish it when we had more than 8 across multiple squads. It was difficult, but we were able to reach a place where creating new features was straightforward and without too many surprises. During this period, the idea of refactoring, was not something I actively discussed with PMs. I knew the outcome of such conversations. PMs would invariably prioritise new things over a much needed refactoring. During sprint plannings, I tried to get as much space as possible so engineers could work in legacy parts. It took a long time (more than two years), but we got there, while at the same time delivering new features.

When I read things like this, I partially agree. If it was down to business, we would have never touched the mess we were in. But beyond that, at no point we had room to negotiate one inch. The approach I adopted was simple: this is not up for negotiation. The same way you don’t negotiate writing unit tests. You write them. Which aligns with this.

If there was a decision between cleaning things, or new features, which one do you think business would pick? The original tweet creates some contention, when the first layer of management is not aligned with refactoring. Say, your immediate manager, doesn’t believe refactoring has value and you are an IC. As an IC, unless you have enough power to influence others, you are stranded between doing the right thing and having your manager against you. It’s not an easy place to be and why I only partially agree with the original tweet.

It also makes me think about EMs and Staff/Principal engineers with long tenures that complain about the mess they are in. Where new features are a slow drag through a quagmire. I wonder who will instigate a much needed change. Who is the catalyst for a new way of doing things. Each case is a case, but if one is not part of the solution, where exactly do they sit?