As a kid, I enjoyed watching MTV’s show “Pimp my ride”. The premise was simple: Transform an old vehicle into a high-tech masterpiece. It taught me that no matter how bad things might look, they can be improved beyond recognition.

Recently, I started drawing more and more parallels between cars and software development projects.

Not so long ago, we took over a legacy project for a client, one of the biggest names in the entertainment industry, whose products are used by millions of people worldwide.

We successfully kicked off the project amidst the start of the global pandemic, worked remotely the entire time, and are now finishing up our fourth release. What a ride this has been!

Working on a new project is like having a brand new car, only without the “new car smell”. The development team is responsible for and aware of every aspect of the product from the very beginning. The way the team “drives” the project affects its shape and outcome.

Yet, more often than not, team members on software development projects will most likely inherit the work of their many past colleagues. Just like the number of previous owners, mileage and age will take its toll on the interior and exterior of a car, the experience of working on a particular software project is shaped by the number of people involved, the size of the codebase, architectural patterns and tech stack.

The question poses itself: Is it possible to “pimp” projects and make them as good as new?

In software development, we often use the terms “legacy code” and “legacy projects” to describe the projects and codebases that are old and difficult to maintain. Yet, some sources state that there is a common false perception that “legacy code” is an old or poorly written program.

The correct definition of “legacy code” is an application system source code type that is no longer supported. “Legacy code” can also refer to unsupported operating systems, hardware, and formats.

I agree this is true, but I would also state that the term “legacy project” is often used colloquially, as it’s mostly used to describe ongoing projects with:

None of the above-mentioned challenges help in the situation when teams are transitioning on and off of the project. However, with proper planning and execution, many risks can be mitigated.

In the following paragraphs, we’re sharing the tried and tested methods for more efficient work on legacy projects.

Even before negotiating cooperation, we knew we would deal with codebases that were written more than seven years ago and developed and maintained by numerous people.

One of the first things we suggested was to review the codebases. We assigned two senior engineers to do a thorough check of both iOS and Android apps and deliver a written report about the dependencies, codebases, architecture, packages, and the data layers used on the project.

The report outlined the main project characteristics and its potential flaws. According to that, we made a prioritised list of action points we would tackle once the project starts. Besides, it helped us manage expectations with the client and schedule the right people for the project.

Experienced engineers are crucial people for the first few weeks of project takeover. We scheduled two of our senior engineers to set everything up as well as to identify and prioritize improvements and tasks.

This made it easier to nail time estimates and helped a lot with onboarding the new engineers to the project later on.

We were taking over a series of apps, so every team member had downloaded the apps and played with them for a couple of hours just to get a glimpse of what we’re dealing with. We also wanted to be well aware of the app features and content before the kickoff sessions.

This made our discussions with the client more engaging and productive because we already had some knowledge about the apps, terminology, and the scope of the future work.

We had a whole day kickoff-session planned for our first day of cooperation. The idea was to get to know each other better and discuss the work agreements that could help us in the future.

The agenda was:

After getting to know each other’s way of working, we focused our discussion to specific tasks that the client had already prepared. Therefore, the team was able to start working immediately after the kickoff.

Although the above-mentioned circumstances gave us the possibility to dive into tasks early on, a lot of challenges arose along the way.

Read on about some of the challenges which we identified and tackled as we progressed.

Initially, we had a lot of trouble with permissions as we couldn’t access some parts of the collaboration tools, design files, external links on task descriptions, and other. It took a lot of back and forth pinging to get a hold of this critical information.

Patience was key here, from our end and from the client’s end. Neither enjoyed the fact that sometimes we had to have a middleman when accessing important info, but the client eventually came up with a solution and we were able to see the things only related to our part of the work.

Due to the fact that it was the first time that the client worked with an external agency, the task descriptions we initially received were often not written to the level of detail we could easily understand. This slowed things down and sometimes made estimating tasks difficult.

The client’s team was as responsive as it gets and each question was answered the minute it arrived. Our team was encouraged to ask about anything that wasn’t clear and their team was patient and precise when providing answers.

I’m proud to say our developers are spoiled to some degree in terms of the tools we use in development. Once you come across an older project, you become grateful for things you sometimes take for granted.

In this case, localization related tasks were the most time consuming because the client didn’t use any localization management tools, something we use on all of our projects. The fact that their apps support 13 languages didn’t work in our favor.

For localization purposes, we internally developed a tool called Polyglot. The idea was to have all application strings in one place and share them between platforms. By using Polyglot, translations across platforms are consistent, and the chance of developer error when copying the strings in the app minimal.

We strongly advocate the use of such tools whenever it’s possible because they not only make us faster, but make our work less prone to errors.

You guessed it – the legacy code itself was our main challenge.

Due to the already mentioned pain points, we faced loads of unused code, and comments like “Have this fixed before person X leaves the company (from 3 years ago)” scattered throughout.

We agreed that we’ll have dedicated time for project improvements and refactoring. It will definitely be a long process but the best time to start is always now.

Chances are, developers won’t be excited to work on legacy projects. I confess that the enthusiasm wasn’t the highest when we were starting our project.

However, four months in and four releases later, we have a team of people who know their voices are heard. We’ve already built a functioning ecosystem with the client and continuously strive to help them with future projects.

I know I can’t make an MTV show out of it, but I still enjoy a good transformation story and I’m really proud to be a part of this one.