For quite some time now, I’ve questioned why traditional software vendors in the banking space can’t seem to evolve their software alongside the evolving market and user demands.

Google keeps their search software fresh. Uber, Facebook, Microsoft and Palantir – their software consistently meets the demands of the user. Just look at all the features that Facebook has added in their main app, starting from a simple social media app for college students. Microsoft has evolved their flagship Windows software many times during the last 25 years.

And yet banking legacy vendors appear to be stuck in time. They do not have a good set of APIs. They are slow in delivering change. They say they are cloud native, but this is not the same thing as taking a big monolith and deploying it on a EC2 instance in AWS. Upgrading their software requires careful planning and it is an entire project of its own.

I believe legacy vendors cannot keep up because they do not build software in a sustainable way. 

Their software engineering teams have been stripped back, reduced. They’re treated as a cost centre with the goal of making software delivery as cheap as possible. There is no culture, the morale is low, and the product teams feel they are working hard just to keep the lights on. Their voices are not heard. They don’t have a seat at the table. 

Senior management is focused on doing reorgs over reorgs, as if this would somehow avoid the inevitable, like switching chairs on the Titanic. 

Their sales teams have taken up the slack, and instead of selling innovation they are telling banks to adapt their way of doing business to the software, rather than the other way around. But even the best sales team will run out of steam. And client feedback and references will outweigh the voice of the best salespeople on the planet.

Banks have started looking elsewhere, either to modern fintech upstarts or by building software in-house. They feel the pressure of change way before the vendors do.

What if developing banking software could be done differently? (And actually be great.)

What if it could be developed in such a way to be sustainable over time – always being up to date with the latest innovations in cloud computing and beyond, and also with new client demands in an evermore digital world?

Sustainability in software needs a precise definition, and a number of key ingredients to make it happen. First let’s define what sustainability means in this context.

By sustainability (as per Google’s definition) we mean software that allows for the possibility of cost effective change either because of business demands or changes in technology. 

Sustainable software engineering needs to maximise speed, quality and maintainability at a reasonable financial cost. Design decisions need to ensure that the impact on any of these metrics are factored in. Scaling costs need to grow sublinear with the increase of number of engineers, processes, customers and geographies.

Design decisions should be based on quantitative metrics as well as qualitative assumptions (customer feedback, metrics, back of the envelope calculations, test results, engineering best practices and computer science), rather than hunches, ‘It worked before’, politics or organisational setup, or just ‘Because I say so’.

New technology shouldn’t be adopted for the sake of it, because it makes us cool. Old technology shouldn’t be kept simply because we are afraid to change it. Software should be written with the future in mind, with the idea that it will be maintained or expanded on by someone else.

I believe investment can be allocated by making changes at the right time, in the right order. Overengineering, gold plating, as well as technical debt, need to be carefully managed. 

This is only possible when you have the right raw materials in place.

Talent density in engineering and a high bar in hiring is key. And that doesn’t mean that building software should be a large expense. On the contrary, a skillful team will unlock the ability to scale software cheaply over time, which at the end of the day will far outweigh the staffing costs. 

Having a strong team of individuals is not enough though. Take football, FC Barcelona are on the brink of exiting the UEFA Champions League this season despite investing €150M in new players. You can have a team full of stars that fail to win because they do not share principles and a clear vision, and therefore fail to play together as a team.

An engineering team needs principles and a strong culture (that favours the development of sustainable software over time) to bind talented engineers together.

Without principles the software loses its design integrity and becomes a hodge-podge of different approaches. This affects the speed, quality, maintainability and cost, many times in an unknown way until it becomes visible, most often when it is too late. Without a strong principled foundation the software will be rewritten many times. It will cost a huge amount of money to build even trivial features and it will never fully satisfy customer demands; while the cost of scaling will become prohibitive. Worst case it might affect the viability of the entire company and lose people jobs. 

In the next posts we are going to explore some of the key principles enabling sustainable software development.

These principles will help guide engineers to find the optimal balance of speed, quality, maintainability and cost when building software. 

We can use them as beacons or north stars when making any engineering decision impacting the software.

As a taster, these include: 

• Shift left. Maximise the speed and quality of feedback loops.

• 80/20 rule. Prioritise the 20% that provides the 80% of value.

• Design options. Build iteratively. Eliminate bad options at design stage, and build the chosen option in stages, from prototype to full production build.

• Design for volatility. Favour encapsulating and decoupling the potential of change in software (volatility) above everything else.

• Fail fast. Minimise for cost of failure rather than for probability of failure.

I welcome you to share your thoughts and experiences as we go along, thank you.