Never mind the MLOCs, here’s the system

I just picked up this chart from Systems Innovation ...

…. and it immeditately struck me how complicated the world is. Way back when I started out as a programmer – maybe I should go back there? – and most of my programming was greenfield. But I remember having to update a system with 30,000 lines of code and feeling intimidated by the whole thing.

Then I read today that complex systems require millions of lines of code …

Source: Visual Capitalist

… and I wonder how they manage that stuff?

Sure, AI, RPA, visualisation tools and micro structuring helps, but millions of lines of code – it even has its own acronym, MLOC! – is a big issue, no matter what industry you’re involved in.

Going back to my mere 30,000 lines of code, you change one line and like a house of cards it has a knock-on effect. No idea what you do if you have 2 billion lines of code, except by organising in a microservices architecture. Little groups who deal with 3,000 lines of code contribute to a networked organisation that links 3 million lines of code.

Yea, maybe.

I blogged about this a few years ago, and pointed at the issue Stripe highlighted: technical debt. Stripe ran a survey a few years ago about bad code that no longer works, and found that over 85 billion hours of developer time is lost each year due to bad code.

It's called Technical Debt. The emergence of millions of lines of code year after year, with little housekeeping or clearing of mess. Think of it this way: you have a room where you keep putting stuff in it. If you never clear it out, you end up with a room where, when you open the door, all the stuff falls out because the room is full. That’s Technical Debt.

We see this in our own lives a lot. If you don’t throw things out, you drown in rubbish. You must clear and scrub regularly, or you end up with Technical Debt or, as I might call it, rubbish.

Technical Debt in banking is a huge issue. Our very own Nick Funnell blogged about this in April:

We layer systems on systems, adding complexity and technical debt over the years so it’s very hard to understand end-to-end how it all works. And we fudge things together that don’t quite fit (‘this system is real-time, but we need to get its data into a system that only understands nightly batches’). So you end up with a system that works - mostly - but that is fragile, brittle, and highly resistive to change: Pretty much the antithesis of the qualities needed to compete.

The result is that most companies have almost half their systems strangled by technical debt (varies by company and industry). How do you overcome it? Serial refreshment.

I’ve met a few big tech companies, like Alibaba, who architect their systems as disposable structures. Every time they deploy a new architecture, they start on the next one. Like Stripe, they may still have 30% of their business strangled by technical debt, but 30% is far better than 70% or more, which is what most banks deal with.

Technical debt is like ivy growing on the corporate tree. It wraps itself round and round and round and, if you don’t cut it back every few weeks, it will strangle the organisation. Get rid of your technical debt now or die trying.