There’s a gorilla in the room and it’s not here to redecorate

By Tom Britton, Co-Founder and CTO of Syndicate Room

At some point in time you’re going to realise the system you’ve built is no longer up to scratch. What started as clean code with a simple relational database has morphed into a hacked together, complex monstrosity that requires a wiki to navigate, a lecture series to explain, and an ibuprofen at the end of every marathon release. Ok, maybe it’s not so bad, but at some point you realise what you’ve built is no longer fit for purpose and the time you’ve spent trying to craft it into what you need would be better spent starting again.

Let me set some context to this before going into the details. When I say ‘rebuild’ I’m referring to the technology stack and system architecture, not a rebrand. A rebrand is easy; update your imagery, CSS, fonts, and boom, it looks like you’ve got a new site. Rebranding allows you to keep the core technology as is and improve your brand, your UX, and surface-level metrics, but it doesn’t improve on your scalability or flexibility, or really attack the core of any speed/load issues your site may face.

A rebuild, when done right, gives you the opportunity to attack all three of these and a whole lot more. And, if you want, you can include a rebrand, or at least a facelift of the site, as part of your rebuild.

Having been through a couple during my time at Thetrainline, and being in the middle of one now at SyndicateRoom, I thought I’d share some of the experiences and processes we went through in determining to rebuild, and the decisions that followed.

When’s the right time to rebuild?

This is, of course, the most difficult question to answer as there is no obvious exact right time. However, there are a few factors to take into consideration when weighing up your decision.

1. Are modifications to the site (new developments, bug fixes, minor changes) taking longer than expected?

It’s important to approach this from an outsider’s perspective – or better yet, actually have an outsider give you an opinion. Reason being, it’s difficult to notice the gradual decline in output over an extended period of time. Subconsciously, we accept the slower speed and attribute it to complexity – and out realising it, the time to develop has doubled.

2. Are you leading the technical decisions or is the system leading you?

There have been a few times in my career when the decision around how we develop a feature has relied not on what we believe to be the ideal way to do it, but rather how we have to hack the system order for it to work the way we want. Not a good sign.

3. Has the support for your stack turned walking dead?

Developers these days want new challenges, they don’t want to be working on the same thing over and over again. So, if you see projects in GitHub involving your tech slipping, or support for versions of your tech stopping, it’s time to think about upgrading.

Ok, let’s rebuild. Now what?

Once you’ve resolved to rebuild, there are a few more key decisions to make and it’s important the full team is involved in this process. Buy-in is critical, so arrange a few half-day workshops to cover at the very least the following: infrastructure (the hardware, or should it be cloudware these day?), database and server side language(s)/API construction, frontend/UX language(s), application security, migration methodology. And then, eventually, work together to outline a loose plan. This will take time, but getting it right and getting everyone on-board ensures less infighting later on.

Diving a little deeper, there are a few key decisions you’ll need to make that are worth extra thought.

1. Same language, different day – or start from scratch?

The first question the business always asks when considering a rebuild, and the wrong question, is how long will it take. Why is this wrong? First, it puts the emphasis on speed, which oftentimes leads to simply reusing the same underlying stack in a newer jacket. While there may be nothing wrong with this, you’ve got to keep an open mind and consider the possibilities a new stack may offer. Therefore, forget about speed and focus on selecting the stack that’s going to enable you to continually, and efficiently, meet all of your customers’ (internal and external) needs.

2. How do you not make the same mistakes?

Much harder than it sounds. When you start on the new system you need to forget everything about your old system except for the objectives of the product and how the different players in the system are related. Don’t revisit your schema, don’t go back through the code, don’t try and get any hints until you’ve got a basic draft of what you are planning to do. It’s only once you’ve drafted a fresh version that you compare notes looking for any relations or players you may have forgotten.

3. Do you have the right team?

Let’s face it, the team you have is the one that got you in the position you are in, why should you believe they can build it better this time? Ultimately, whoever is working on the project needs to develop in a way where you don’t run into the same trouble in 12 months’ time. Throw in that you might decide to start with newer languages, which the team may be less familiar with, and it’s not looking good for your current colleagues. And yet, I find time and time again the right decision is to keep most of the team you’ve got, so long as they are hardworking and quick learners (two things we value more than anything when we hire new developers). A few fresh faces thrown in can help when they know the new stack and if anyone in the current team is not pulling their weight, you let them go.

The unexpected positives of rewarding your team with a rebuild

Forget the spin I’m trying to put on this: there are some massive positives for making the decision to rebuild from scratch and largely keeping your team intact. For starters, there’s nothing a good developer likes more than a challenge, and a rebuild, new tech stack or not, definitely hits the spot. While the business may push back slightly on the idea of rebuilding, since there are always delays in delivering things new and shiny, every team I’ve worked with relishes the opportunity and motivation levels go up big time. This enthusiasm is often compounded when new languages are introduced, as adding a new language to their repertoire makes developers more valuable on the market – and to you.

Going back to the question of having the right team, any developer not motivated by the thought of rebuilding and learning new languages is potentially not worth keeping in the team.

So there you have it, the main questions I think about when approaching whether or not to rebuild, and those I ask before setting out to do it. Ultimately, it is a bittersweet decision to make. You look back at the years of hard work you’ve put into your application and all the good intentions you had when you started it, and have to say goodbye. Hold a memorial if you want, but don’t let attachment to the system stop you from creating something better. I promise the code is always greener on the other side of the server.