Taking Over the Project with Legacy Code

Contributor: Vladimir Tutov, PM at Archer Software


“Hi there!”, said John, “I wanted to add a few small features to my app. You should remember it. You developed it 2 years ago.”

“Good afternoon, John. Well, yeah, there was something like this. And I think we still have the source code. Let’s go over what you want to add, so we’ll estimate the changes,”


John ordered the Transporter app at the beginning of 2012, and the project was was finished up by late autumn, complete with full documentation and tests cases. Based on the fact that we have all the documentation and even the source code is still in our repository, John was absolutely sure that it will be easy to add compatibility with GPS devices instead of manually entering coordinates.


Before starting work with inherited source code, please prepare:

  • Source code

  • Requirements

  • Documentation


The phone rang the next day. It was the good news that John was looking for – the contractor said they could make the changes in a week plus 3 days for testing and polishing.

“Ok, deal. Send over the contract for me to sign. I want to add one thing: I want daily updates on your progress so I can watch the budget.”

The clock started ticking.


The next day the environment was set up, the developer got the source code from the repository and was in the middle of research. “Everything is going smoothly so far” was the report for the first day.


The day after, the developer sat there sweating, but things were at the same stage: research is in progress. Development hasn’t started.


It's recommended to have a support contract and to maintain a SW periodically.

It can be small bug-fixing, outdated components update etc.

In this case every new feature would have a predictable development size.


Ok, what’s happening today? Where do we stand? “ asked John at the daily meeting.

“It seems that the iOS application hasn’t been updated since 2012. Apple now requires 64-bit support for all applications that are uploaded to the AppStore. But the fact is that we can’t add this support without updating a few libraries. Right now we are updating the libraries and dependencies.”

“Okay. We haven’t been updating the app periodically, so now we gonna face the music.”

“Exactly! It’s like a car: you missed a few planned maintenance tune-ups, so you have to be ready to deal with some extra risks and higher costs when you get to the service station next time. It can also happen with the server application. Some of the modules are deprecated and won’t work. You should update them, but that means updating all of the dependent modules aswell.”


It was late afternoon on the 3rd day when John got the email he had been waiting for: it was a hard nut to crack, but it works now! Finally, the app compiles from source code, but at least it was ready to be updated now.

“So, what’s the plan? Are you adding the feature today?

“Not so fast. It will take 3 days just to plan.”

“Alright, alright, I know. It was just wishful thinking.”


The next 3 days the developers were busy little bees. From time to time there were comments like:

“Who wrote all this crap? I want to chop off his hands!”

“Charlie, don’t you remember? It was you 3 years ago!”

“Holy cow! Ok, at least I can tell that I am a lot more experienced now.”


Development approaches are always changing and developers are tempted to constantly adjust the code according to current best practices.

Be careful with these minor improvements. They are no doubt useful, but should be grouped in batches to keep an eye on your budget.


All this time John has been collecting suggestions on how to update and improve the existing app. The ideas were ok, but he knew that everything should be done at the same time unless the updates are critical. He decided not to throw them out and instead came up with an improvement plan.


Refactoring, unit-tests – 3 years ago these words meant nothing to him, but fortunately he agreed to  invest the time into doing it. Now it was obvious that this investment paid off and the app was ready to be updated. It’s not always needed, but it is something that should be specifically.


“Alright then, it was 1 day to set up the environment, 2 days to update the existing app and 4 days for development. Now let’s see what have we got here.” John was excited to see the new logo on his iPhone.


But after a quick test they found a few defects and his excitement gave way to exasperation.


“What’s wrong with you guys? I always set my photo from the front camera but now it simply doesn’t work! How can you say that you tested the app, if you didn’t even find this obvious problem?”

“Well, you know. We haven’t done a full system test because it would have been weird to send an invoice with 7 days of development and 15 days of testing. So, we only tested the affected areas.


Automated tests can save you a lot of time and money, especially for small changes.

At least you'd better have test cases for manual testing.


We would get the most reliable results if we use automated acceptance tests. In this case, we would just run them and get a defect report. But, I know what to do: let’s develop a test plan for the app together and test it that way. It’s a pity that we don't have a plan like that already, but better late than never.”


“And how many days does all this mean? “

“It depends on testing volume, let’s calculate.”


Four more days went by, but finally the tests are ready to be run and passed successfully. Having passed all these tests, the system was ready to be uploaded to the AppStore. Everything was prepared in advance for this step. The contractor kept the developer’s account and certificate, so they were able to easily upload the app.


While the development cost John a little extra money, it will save him money in the future, as well as help us gain some experience for free.


Let’s recap.

  1. Create automated tests during main development flow, it will save money and will help maintain quality. If you don’t have auto-tests, at least prepare some written test cases and store it along with the other documentation.

  2. Store all the documentation, requirements and source code in a cloud repository, you’ll own all these assets ultimately and will be able to provide them to developers anytime.

  3. Sign a support contract, and let the developer maintain your software. Discuss all your ideas with them about what should be updated and what can wait.