Switching Projects

I've had to work on a couple of different Software solutions in my 5 year career. Each time I've made the transition I've felt like a fish out of water for the first couple of months while I learn what the software does, how the code works, and what processes and tools the team uses. In order to save some hassle during the next transition, here are a few tips and suggestions for transitioning to a new role to maintain an existing application.

1) Read through any documentation that the client is expected to read. This will give you an idea of how the product works (helpful in recreating/unit testing later) and introduce you to the terminology used by the software team and clients (useful in communicating with others).

2) Walk through the software and play around with it. As mentioned above, you will eventually be expected to navigate around the software to unit test it and to recreate defects. The more you become familiar with the project at the beginning, the easier your task will be later. But remember, when doing your testing, make certain you do so on a stable build. Encountering defects while you are still learning the system can be confusing.

3) Setup your development environment and download the source code, following any documentation that your team might have. I really like the suggestion Joel Spolsky made on the StackOverflow podcast #80, if the documentation is inaccurate, fix it. If it isn't detailed enough, add to it. If it doesn't exist at all, then write it yourself.

4) Are there any special design documents, a wiki, or some other supplementary documentation for the code? While these documents are rarely kept up to date, they may explain how certain key features of the software work.

5) Learn the basic structure of the code, and learn what the key methods and classes are. It's best to try to learn this on your own, but if you make an effort to learn the code before asking another member of the team for help, most of the times they will be happy to help you.

6) Learn who the key people for the project are. There's always key people for any project, the project leader, the lead developer, and often there's a business analyst, and a lead QA Engineer. It is important to know who these people are and understand how you will be expected to interact with them on designs, code hand-offs, and defects.

7) If there are any Third Party utilities used by the software, learn where they are used and make certain you understand how to use them. Some may be as simple as an external library, while others may as complex as Document/Report generation tools or Business Logic tools. It would be foolish to expect you could become an expert in these tools, but you should at least know what each do.



This should provide you with a rough outline of what to do when you are assigned to a new project. Depending on the work load you are given, you may not be able to accomplish everything on this list, at least not initially, but everything on this list is important and should be done eventually if you want to be able to contribute to the project at a high level.