I've joined as a fresher (trainee) a software company developing for Windows Store. I don't know much about C#. My company has started Windows Store development recently. They didn't do .Net development before, that's why my company got an Senior .Net employee to complete the project.

Whenever he completes the project he will leave the company. I will have to maintain the project after him. So I need to study the project flow and analyze the project to be able to maintain errors in future.

Can you suggest how to start to analyze the project and what to pay attention on?

closed as too broad by Ixrec, user40980, durron597, Dan Pichelman, user22815 May 29 '15 at 10:56

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • possible duplicate of How do you go about training a replacement? – gnat Feb 28 '13 at 9:24
  • @gnat, I think this question isn't a duplicate especially because the senior wasn't asked to train the OP (I suppose so because the OP is clueless where to start). – superM Feb 28 '13 at 9:41
  • 1
    @superM "Whenever he completes the project he will leave the company. I will have to maintain the project after him." - this means OP should go to the manager, point them out to this and ask that the senior be assigned to train, which, well, will lead us exactly to that "possible duplicate" question – gnat Feb 28 '13 at 9:44
  • 1
    @gnat, I thinks that's the best way out ))) – superM Feb 28 '13 at 9:45
  • @gnat Thank You to edit my question and makes it good. You requested this question is a duplicate. But which question you requested is to be " How do you go about training a replacement? " in the Developer point of view who is leaving the Organization. But this is different from that. I am sorry to say the question which you preferred doesn't contain much good answer in my point of you. – Kumar Feb 28 '13 at 10:10

Where to begin depends on if you are familiar to the technology you're using. I don't think that you need to have a deep knowledge of the technologies, but having a firm understanding of how things work is necessary.

Start from the documentation. First read the requirements to have a clear picture of what the project should do. Than try to analyze the architecture to get an overview of the structure of the project.

When you're done, have a discussion of the architecture with the senior developer, try to understand why this or that decision was made.

And only after this dive into the codebase. Read, debug, execute, change/break the code to understand it. If anything isn't clear, don't spend to much time trying to figure out on your own. Ask questions. Take small tasks on the project and complete them.

You need to do as much as you can before the senior developer leaves. So pay special attention to the things that are most difficult to figure out on your own. Start from those things.


Load it up in Visual Studio. Pick some small part of it, some form or page, and set breakpoints in the load events, and then step through, line by line, section by section until you begin to see a pattern emerge.

If you don't understand something, take a guess, look up syntax to see if you were right. Hovering your mouse over variable names will give you details of what's inside.

After several run-throughs, you may begin to see what the senior developer was trying to achieve, and why.

When your coffee-cup is empty, take a break. :)

  • 1
    +1 for "you may begin to see what the senior developer was trying to achieve". – Siamore Feb 28 '13 at 12:51

Sometimes, it takes a more skilled engineer to be able to maintain a less skilled engineer's code.

If the project is simple, it could be worth the struggle to write it yourself, because it will also be a struggle to understand somebody's code within such a short time and you are a fresher.

If the project is complex, your company should really wait to hire a long term and more experienced engineer.

To have a developer leave right after the first roll out is such a bad idea for all involved. Most programs have some critical bugs at first, and if success(relatively speaking) for the first roll out is important, you are likely heading for failure. If first roll success is not important and can wait, then again why not wait for a more experience employee to come along or let you take your time to build something new?

Not the answer you're looking for? Browse other questions tagged or ask your own question.