Catch 22: to die or maybe die?

As it's Friday the Thirteenth I thought I'd cheer you up with yet another core systems renewal story. There’s a great article that resonated with me in the Financial Times the other day, talking about ‘technical debt‘. The line that has stayed with me is this one:

“Stripe estimates that developers spend about a third of their time on tech debt and a further 9 per cent of it fixing bad code.”

Wow.

That means that almost half of Stripe’s developers are dealing with fixing old and bad code. And Stripe is young and new, a FinTech babe, a poster child.

Wow.

What the hell does this mean for a big old bank?

Oh yea. Four out of five developers in an old bank are dealing with fixing old and bad code. 80% of their investment is in keeping the lights on.

In fact, another thing that stayed with me is an article by Anna Irrera on Reuters two years ago, where she cited that most banks’ systems are still running and being maintained in COBOL.

Nothing wrong with COBOL … except that the average age of a COBOL programmer is 61, and they’re a dying breed. Worth noting.

In fact, this dying breed of technical debt is the bane of a banks’ life but, more importantly, the risk and cost of getting rid of it and renewing is equally unnerving, which is why most don’t do it. But if you don’t do it, then eventually the systems will break down anyway. It’s a Catch-22.

To renew or not to renew? To die or maybe die?

Tough choice.

But it is telling that if Stripe has almost half of their people dealing with technical debt whilst a bank has most of their people dealing with it, which one is more agile and fit for the future?