It happens that some one just leaves the company all of sudden. Now his work needs to be completed and you are being assigned it. Having no idea what was he up to (was it 90% done or 9%), how do you manage the leftover?
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.
In order to figure out what to do, you need to know what you have, and how good shape it is in.
So, start with having a quick look of all the source and see what you have. If it is vividly clear then it is easiest to just finish what is missing. Do unit tests to find out what works and what doesn't.
If it isn't vividly clear then start figuring out what works with new unit tests. If this is impossible then bring out with your team leader that you have an issue and that you may not be able to make it. He can then decide if the left work should be salvaged anyway or if it is just too bad and you need to redo it.
In addition to what others wrote, I would suggest you talk to anyone who had direct contact to the guy. I understand from your description that he was working alone, still he must have been reporting to someone? And there may be QA personnel having tested what he had produced... These persons should (normally) have at least a rough idea of how far the guy got with his project before leaving. Unless of course the info/product supplied by him turned out to be completely unreliable, contributing to his layoff.
Discuss this with your manager and allocate a time frame for the initial exploration / testing of leftover code, and understanding the specification and requirements. This could be roughly a day for a project on the time scale of a few person months, at most a week for a project of one or more person year's work, etc.
After this initial exploration, you should have a rough estimation of
Then you can sit down with your manager again to make a decision.
In my experience this isn't an uncommon situation. Unfortunately, you really have two problems here:
1) The left overs of this project 2) The reasons you got into this mess in the first place
For (1) you need to consider the size / complexity of the project. If it is a week's work, you probably need to start all over again. If it is a year's worth of work, you might need to see what you can salvage from the existing code.
Either way, you need to take these steps immediately:
a) Tell your managers that you have a big problem
b) Get the project spec and get a thorough understanding of what you need to achieve - or talk to the project sponsors if there is no spec.
c) Talk to managers / customers etc. and find out if anyone has / thinks they have any idea what the state of the project is.
Once you've done that, you'll be in a position to start examining the code / working out a strategy.
(I don't think unit tests will help you much - they might tell you if the functions that have been written actually work, but they don't tell you what functions should be there.)
What I'd no next is get an overview of the architecture of the code that exists, and how this maps onto the problem defined in the spec. Then work our what the sub-components are of each of these main components, and see how they fit in to the big picture. Doing this will tell you (roughly) what components are missing.
Once you know what exists, you need to start examining the existing code to see if it does what it is supposed to do.
Once you've done all this, you'll be in a position to estimate how much work is left to do.
As for part (2) your company may need to look at hiring policies / staff retention policies, find ways of keeping programmers accountable for progress.
Finally, you should also consider how you could prevent this happening to the company should you leave in a hurry.
You definitely need to try and run the software to see what works and what doesn't.
You'll then need to consider what documentation has been left. Are there written requirements? Are there specific tasks - are tasks tracked in some way? Has anyone been testing it - if so, they'll know what's done and what not.
I think a plan of action would be:
Mark off which requirements have been completed (by a quick run through of the system like a tester would)
Look at the code - can you make sense of it? Is it well written?
Clearly if it's 90% done and the code is well written, you'd just finish it off.
Not mentioned yet.
Try to contact the guy that leaved. Its not possible in every case. But if he is healthy and at least liked a little bit his work, he will help and give you a honest answer of progress and missing parts. And he could explain the big picture to you.
Congratulations, this is your chance to shine and make a really positive impression on your bosses. What you have here is a priceless opportunity. So what do you need to do and how?
First, get the code. He may not have checked everything in (the guy who did this to us did not) and so have someone with admin rights pull it off his computer and check it in for you.
Next triage the problem. Take the requirements and note which parts seem to have code written and which do not. This is the rough list of what isn't finished. It will grow as you do the next step. Then go through the code and evaluate it and run it and see what is currently working and what appears not to work even though there is code written. Add the not working parts to the list. Look for unit tests (I'd be surprised if you found them, the people who bail out just before a deadline because they know they are failing tend not to write them). Now at least you have a good idea of how bad it is. Also look through the requirements and see what questions you need answered. A lot of time, project failures come about as a result of poor requirments and a developer who doesn't want (for a myriad of reasons) to ask further questions.
Now you make your project plan. Start with a list of the questions you have from the requirements (write it up formally in a document) and then list the things you need to do to complete the work. Make an estimate of how much time each will take. Determine if what currently exists is salvageable (and if not, be prepared to justify why not).
Now have a meeting with the project manager (and your boss if they are two different people) and tell him or her the bad news. (It's almost always bad news when someone leaves suddenly and you have to pick up where they left off, good developers don't leave people in the lurch - they at least leave with a list of what they have done and what is left to do. The exception may be if someone left due to health issues.) In your discussion, you may get some of the answers you need and you and the PM may rework the project plan a little.
Follow up the meeting by sending the PM and other critical stakeholders (the PM will identify who), a copy of your questions that need to be answered and the project plan you worked out.
Now you have what you need to get started on the actual coding, so get to work.
In the meantime, you have probably been pulled off something else to salvage this project. Make sure your work is in shape for someone else to pick up or for you to pick up after you finish the project. That means the same types of things, a document where you say what is done and waht isn't and a check in of all source code (not necessariliy to the trunk if is isn't done, but somewhere that someone else can access it.
If you haven't been pulled off your existing work, then you need to work out with your boss how much time in the workday you will spend on each. This is one of those times when overtime may be needed and will be appreciated. The closer it is to the actual deadline, the more desperate management is, you may be able to work out overtime pay or a large bonus if the deadline is close. If this work is going to significantly delay the other work, then you need to make sure the stakeholders in that project are aware of that.
Once you succeed in salvaging the project, make sure to brag about that in your next performance review.
