Backend engineer Jack Kleeman explains why we held an internal hackathon to clean up some old code!
If all banks regularly did this they wouldn’t be up the bog of eternal stench without a paddle.
Those legacy banks aren’t touching their 1960’s/70’s/80’s code with a barge pole for fear of a TSB style meltdown, while Monzo are rewriting 2015 code…
I wonder who is going to be around in 20 years and who is going to be in the toilet? 
6 Likes
Thanks for this update! Really interesting insight into the process and a model that I imagine you will continue to utilise in future 
1 Like
Have your coding standards changed dramatically in the last couple of years? It sounds like a LOT of refactoring after a relatively short period.
As a developer myself for many years, a week seems a very short timeframe for the number of changes that have been made. My biggest worry would be whether everything has been tested thoroughly enough.
Not knocking the team, sounds like they’ve done a great job. Just surprised at the amount of changes in the really short time frame!
They just built a bank in three years..
16 Likes
on that note, imagine what they can build in 6 years then…
5 Likes
@bea: There’s two different copies of the blog post live on the blog home page and in the RSS feed, one from the 30th Nov and one from the 4th Dec!
Two banks…?
7 Likes
Two banks? Two continents? Two planets? Who knows!
Er, OK… not sure I get your point? I’m talking about changing over a hundred thousand lines of code in a week and the risks that involves.
My point about coding standards is that I’m surprised developers writing code three years ago were doing it in a wildly different fashion to new developers who have joined the company recently. Surely they all work to the same coding standards?
1 Like
Not necessarily. I’m a developer myself and just had a peer review a few hours ago and my coding style was wildly different to that of the senior dev. Different devs have different styles and you can’t be 100% certain that a) every organisation has coding standards and b) they’re adhered to.
7 Likes
They didn’t code with certain features in mind. Those features have been added on. Not surprised a thorough review is needed. Nothing wrong with a regular spring clean.
Not a developer though so could be wildly off base here.
2 Likes
I’m aware that many organisations don’t have coding standards but that’s very poor practice. I’d be amazed if Monzo don’t have coding standards in place.
Apart from the issue of ensuring that all developers adhere to strict guidelines, good coding standards are vital in terms of security.
Wasn’t the iOS app originally built by like 1 or 2 engineers? It’s completely understandable to me that 100+ new engineers of the highest calibre would collectively code differently to a couple of guys working in a little startup, up all night eating pizza.
2 Likes
Let me put it another way… the best footballers in the world all have their own skills, talents, attributes, etc. You wouldn’t just throw them into a side with no management, tactics or plan of attack and expect them to perform as a team on the pitch. Think of coding standards like the tactics a manager discusses with their players, ensuring everyone is clear on how they are expected to play.
(Not sure if that’s a good analogy but it’s what springs to mind!)
All developers do have their own style but that is one of the reasons you should have good coding standards. It shouldn’t matter who wrote it or when it was written, you should be able to open a file and be familiar with the coding style. This makes maintenance much easier in future.
1 Like
Know what you mean!
They did not mention here, but I assume they have some form of automated testing as part of their CI setup that works both before and after the changes. Wonder if I assume correct
Hopefully most of the changes were fairly minimal - renaming to use new interface and removing boilerplate
2 Likes
At the risk of going off-topic, I can think of a particular manager who seems to be doing just that right now…
1 Like
Jose…
The platform and our practices have evolved considerably over the last few years. As one example, things like the way services communicate and the libraries we use have changed. When we made some of these changes we introduced compatibility layers so the old libraries and APIs continued to work. This effectively let us reap the rewards of our improvements sooner and defer some refactoring until later, consistent with our engineering principle of technical debt as a tool. Since many of these changes were made, our platform has grown dramatically: https://twitter.com/obeattie/status/1040541401971351552
New services use the new libraries and conventions by default, and many older services have been refactored as changes have been made to them, so the proportion of services using these compatibility layers has decreased. It’s become extremely rare to encounter code that does things “the old way”, and as our team has grown much larger many engineers have never written code in the old style. The time came to pay down the technical debt and refactor the holdouts.
These changes are very systemised, and in some cases the rewrites can be automated entirely, so the risk associated with these refactors is low. And of course, these changes were subject to all of our usual testing, rollout, monitoring, and – if necessary – rollback procedures. 
25 Likes