Getting up to speed on an existing project

Question

Say you are the new guy on an existing project. You know the language that is being used and you may even know the framework. You want to get productive as soon as possible. What do you do to get up to speed and get familiar with the current code base?

Do you read every piece of documentation available? Do you pair program for the first couple of days?

Similar questions (such as this one) take the perspective of the team hiring the new guy. I'm interested in the situation where you are the one that wants to get productive.

Answer 1

(Answering in the context of a large, complex code base.)

Use the product intensively for a while, so you know it well from the outside.

Then run it again in the debugger, stepping through the code to see how it works from the inside - how the various modules call each other, and how the individual algorithms work.

Set breakpoints at interesting places in the code, then look at the call stack to see how the code got to that point.

Then start to test yourself - think about how you'd expect the code to achieve a certain thing, then look to see whether you were right or wrong, again using the debugger.

Above all, don't be afraid to ask questions - the team would rather spend ten minutes explaining something to you than have you spend a day figuring it out for yourself.

Answer 2

I would do (did) the following:

1. If they have some class diagrams / architectural document, then read it to get a good overview of how the system is structured.
2. Start going over the codebase by following typical application scenarios. Say if you have an online store follow scenarios for searching/buying items. This can be done nicely by debugging the code and going step by step through each stage.
3. Ask! Although initially it may be inconvenient and nerving, but ask your (more experienced) team mates on how things are done and possibly do them better. But the key essence is that you have a common style of doing things.

Answer 3

1. Have one of the senior team mate as a mentor for you in the project.
2. study and understand the requirements already implemented.
3. for one cycle of the release work as unit tester or help other developers in doing unit testing.
4. get responsibility for a independent module to start with. work with your project mentor on how this will get integrated into the project.
5. Study and understand the architecture and design of the project.
6. get an overview of the modules you will be resposible for from already existing team member.
7. Study and understand the process followed in doing the builds.

Answer 4

I'm in a similar situation at the moment a with large project using web services so you cant really examine it from the outside. No one person understands everything about the system as its just to great in scale.

The best advice i can give is sit in with the other members of your team and try to get a good overview of how the system works. Ask questions and get involved so you absorb the information as well as you can. Then start out small, perhaps bug fixing in a particular area and try to learn that one section well. Over time and as you get acquainted with more and more small areas you will improve your working knowledge of the larger system.

Large complicated systems by definition are hard to understand, take it one step at a time. Its better to know one or two areas very well than to have a shaky understanding of large portions of it. This is something you will come up against repeatedly over your career and its better to be patient and accept that it will take time.

Answer 5

Absolutely read all coding documentation available for the project - if it's there, someone wrote it for a reason.

Start with fixing bugs, not writing new code - this is great opportunity to get a quick glance at all areas of the codebase, and also to get to know people responsible for them (or, in general, find out who on the team knows what best). Start with low-hanging fruits, then go for bugs that require spending some time in debugger, and asking people around about "how it actually works". Don't rush with new stuff.

If your team didn't do it already, ask for someone to be your "peer mentor" - a guy whom you can immediately ping with quick technical questions as they appear (and there are always a lot as you start) without any qualms that he's busy or generally doesn't have time to waste on such mundane matters.

Answer 6

Having done this a few times, I'm not enamored of the "read the docs" approach. The docs probably aren't any good anyway -- who has time to keep architecture docs updated?

Pairing doesn't hurt. Make sure there's somebody you can go to with code & architecture questions. Get an overview of the application from a user's point of view; get someone to explain the basic pieces, in terms of architecture and business logic.

Then just dig in and start fixing existing bugs, and/or adding whatever new feature the experienced team members think requires the least prior knowledge.

You'll be productive pretty quickly, more productive over time, and in a year you'll be a subject matter expert. :)

Answer 7

I agree with most of the things written here, but don't agree with working as test engineer helps in getting up to speed.

Answer 8

My initial steps on the job:

1. Ask what development methodology is being used and at what state is the project. This helps narrow down which of a few different starting points make sense. For example, if something is in its 3rd round of QA and is mostly done, then perhaps my work is best done doing some tests and filling in through that role to be productive quickly. In contrast, some projects may be where I just need to take some pages and convert the English into code as the starting point.

2. Assess work environment and begin assimilating to it. Does everyone usually start at a specific time? Are there core hours where everyone is expected to be there? Is there a standard number of hours a week that I'm expected to work,e.g. could be 60 hours if the project is trying to meet a deadline? The key here is that while there are a few questions up front, it is more about observation and mimicking to my mind as it may be that lunch is handled by half going at 11:30 and the other at 12:30 or everyone leaves at 12:12 to go get lunch for a couple of examples.

3. Depending on the methodology, either pair with someone else on another machine or pair to get my machine up and running with the code and all the settings I should note, e.g. settings in hosts file, IIS settings, Visual Studio configuration, source control access/use, continuous integration system, etc. This is where I'm getting something done which may be a lot of knowledge transfer but hopefully should be something done within that first week or two.

Answer 9

some good thoughts in this link and this link

Answer 10

In general what is difficult when starting is to get an overview, you can read all the code you want but to get an overview you need diagrams and somebody who goes through them with you. Reading lots of documentation is useless, in my experience most of the documents are either out of date or badly written.

Another point is to make sure you have the product compilable and runnable on your PC. IOW when you start you shouldn't be spending days figuring out compiler/projects settings, if you can debug on day one you have a great advantage.

As others have said, having a person who has time allocated for you to bounce questions on is gold worth, if you don't have this there will be a lot of reverse engineering. Important is that he really has gotten time allocated and is not helping in addition to his normal work. This could otherwise cause some stress.

Look at unit and integration tests, this give a lot of information how stuff will be used. Especially useful is higher level tests written like by QA, these are valuable because they give more information about how the user will use it.