Your checklist for seamlessly taking over existing dev projects

Working as a developer means you need to know how to dive into existing code bases. When you inherit a project, there are a lot of specifics that you don’t know, like why some of the code is written a certain way. So when it’s time to go into a hand off meeting you need to know what to ask about. This is your time to get the information you need to get up and running.

These questions come up in every project. You could be starting a new job or working on a different project at your current company. Regardless, here are a few things I’ve learned you should bring up in transfer meetings.

Know what it’s supposed to do

What exactly is this application used for and who uses it? It might sound ridiculous, but this can be overlooked or misunderstood in the beginning. Without this context, it’s going to be really hard figuring out how to implement new features or fix bugs. 

So make sure to ask about the overall use of the app. Learn about the workflow for different parts of the app. If there’s a task list, get a walk-through or more details about each of them.

This is one of the times everyone is prepared to focus on answering questions about the project. So if there is anything you’re unclear on, don’t leave that meeting without clearing it up. Of course things come up when you start digging in, but this is your chance to preempt a large chunk of confusion. Try and get a high level understanding of the app before you dive into specific questions. Learning about the industry the app operates in can help answer questions that come up in your development as well.

One client I worked with was so deep into the details that at the end of the first meeting, I had to specifically ask what the application actually did. When we took the time to discuss what we were building and why, it cleared up so many of the complex questions that they arrived with.

Always start with who the application is for and why they would use it.

Know how source control is handled

While most projects use Git, not everyone uses GitHub. Some projects could be hosted in BitBucket, Azure DevOps, or even on a SVN. You need to know where code is kept in version control so you can pull it down to your machine and also so you can do troubleshooting when those inevitable production bugs appear. 

Make sure that you have access to the code and that you have the right level of permissions to do the work you need to. When you receive your login credentials, check them immediately. I’ve had cases where I thought I had the correct level of access until it was time to deploy. Trust me, that is not the time you want to tell the client you’re having problems with something this simple. (Especially since they’ve likely asked if you’ve had issues earlier.)

The sooner you can find little problems like these, the smoother the project will go in the long run. Fix a small bug and do a quick commit to make sure that you can push up your local branches to wherever the remote repository is. Also, take a quick look at who has access to the repo. This will be useful info when it’s time for pull requests and code reviews. 

This is also the time to ensure that only the necessary people have access to the code. Note any users you are unfamiliar with and check with a project manager or someone to see if they still need access.

Know how to run the project

The hardest part of taking on a new project can be getting it set up and running on your machine the first time. There are a lot of one-time commands that can be lost if the process hasn’t been well documented. A few things you need to check that might not be obvious include your PATH variables, the versions of the software you’re running, and the file names you are referencing. Other things that might come up are setting up a new local database and getting the seed data in there and changing any connection strings to APIs or databases.

If you are going through setup and you notice yourself running into issues, make sure you’re documenting them so that it’s easier for the next developer to do it. Plus you never know when you’ll need to factory reset your computer and those notes will come in handy.

I had to do a factory reset on my computer and I had projects in PHP, Node, C#, and other tech stacks. Those notes were invaluable. Help yourself and others by writing a small start-up doc to get through the tricky parts.

Once you have the app running, check that everything is functioning like it does in development or production. You should see the same behavior across all of the environments until people start pushing changes.

Know the testing process

There are many different forms of testing that your app can go through and you need to know how to jump into that flow. Unit tests are common in most projects to some degree so always check for those. Some places do integration testing to make sure no breaking changes sneak into the build or deploy pipelines. Other places even have dedicated software testers that will run through user scenarios to see how things will work for real users. You need to be aware of all the steps your app will go through.

When you start this new project, looking at the tests can give you a good idea of how the app works. If there aren’t any tests in the project then this is your chance to start adding them. Having some code coverage sets the tone for the app in the future that there should probably be more tests added as code developed.

There was one project I inherited that had zero code coverage and there were constant complaints about the number of bugs making it to production. So I spent some time walking through the app from a user’s perspective and wrote tests around the most complex scenarios. Figuring out what the users were doing made it easier to find bugs and write tests to prevent them from getting through the other parts of the development cycle.

Working with software testers is a different process you’ll have to learn. Usually there’s some kind of system in place like Jira or Basecamp where bugs and features can be discussed and tracked through sprints. Follow the process they have in place and it’ll help get your code to the pull request phase faster and more consistently.

Know the deploy process

Although cloud services have just about taken over the hosting needs for most companies, you might still need to work with a physical server. Having this information will help you understand the deploy strategy you will be working with. 

For example, is there a continuous build/deploy process in place or will you need to do manual deploys from your machine? Know how migrations should be handled across different environments. Get all of the common parts of deploying an app clarified for this particular app.

Little wonky things happen with the cloud services that only the people that handled the deploys before know about so make sure you ask about any weird things you should look out for. Since you’ve already fixed a small bug to check that you can push up your changes, go ahead and deploy that small fix to the development environment. This is your test to see if you really understand how the deploys will work. Hopefully you won’t have to do many manual deploys and you’ll work with CI/CD pipelines so the process will stay consistent.

There was one specific deploy process I still have nightmares about. To start, the whole process was manual with absolutely no testing. There might be months in between deploys and no one ever documented the steps in the process. So every deploy always had issues in production. Sometimes inheriting a project means you get the ugly duckling and you have to turn it into a swan.

Taking over an existing project is a special skill because it’s not something you do all of the time. Some people work on one product or product line for a bulk of their career so setting up new projects only happens every now and then. Although if you ever do consulting or freelance work, you’ll need to know how to do this with confidence on a regular basis. Usually there are small configuration changes that you have to figure out and once you set then you never have to worry about them again.

These are just a few things I try to check for when I’m setting up a new project. Some of these tips apply to open source projects as well. Do you have anything you always check for when you’re getting set up?

Like what you’ve read? On Growth Quarters, we strive to go beyond generic ‘fortune cookie advice’ and learn directly from the people who have ‘walked the walk.’ And this summer, at TNW Conference 2020 in Amsterdam, we’ll take Growth Quarters offline again with a vibrant program dedicated exclusively to sustainable business growth. Listen to keynotes from leaders from the world’s most successful companies and get actionable guidance to help you grow professionally. Get early bird tickets now and learn more about the Growth Quarters track.