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?

  1. Shall I start from scratch? What if it was 90% done?
  2. Shall I try and understand whatever he has done? What if it was just nonsense?
  • 10
    +1 to counter the IMHO undeserved downvote. I do think this is a decent enough, real, answerable question which is on topic here. It is sad to see this site becoming increasingly hostile and impatient, following on the path of SO itself :-( Jun 14, 2012 at 8:37
  • 2
    @PéterTörök I think it is getting close votes because anybody can write an answer that has to do with any of the multitude of best practices when working with others code. The answers below so far are excellent BTW but I can see this generating 50 lame answers.
    – maple_shaft
    Jun 14, 2012 at 8:52
  • All I need is a decent strategy.Cause when such situations arise everyone is just Screwed up.
    – Shirish11
    Jun 14, 2012 at 9:14
  • 2
    @maple_shaft, IMHO this could apply to pretty much any question on this site ;-) Jun 14, 2012 at 10:27
  • In a reasonable company, the person leaving would have reported daily in the standup what his progress was, and besides his tasks would have been broken down in reasonable chunks anyway.
    – MSalters
    Jun 14, 2012 at 12:29

6 Answers 6


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.

  • Figuring out what the requirements are would also be important to figure out what you're missing?
    – Svish
    Jun 14, 2012 at 15:22

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

  • what the product is supposed to do,
  • what can it currently do and how well,
  • how much time and risk it would take to rewrite from scratch,
  • how much time and risk it would take to finish what's already done.

Then you can sit down with your manager again to make a decision.

  • Trying to make contact with the guy seems like out of question cause they just disappear.
    – Shirish11
    Jun 14, 2012 at 9:05
  • 1
    I meant to contact the guys's project manager, or someone in a similar role who used to supervise his work. Jun 14, 2012 at 9:39
  • managers are not fully aware of what actually is being done in the coding part.
    – Shirish11
    Jun 14, 2012 at 10:09
  • 1
    @Shirish11, of course not, but any project manager worth his/her salt should be at least roughly informed about how far his team member(s) currently are with completing a given task / project. Jun 14, 2012 at 10:32

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.

  • +1 for getting the spec. Sometimes the only place it existed is inside the dev's head and the people who asked him to build it. Jun 14, 2012 at 17:08

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:

  1. Mark off which requirements have been completed (by a quick run through of the system like a tester would)

  2. 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.

  • 1
    I started writing an answer with the exact same (word-for-word) first sentence as yours. This is just common sense. The other question would be - why don't managers/those in charge know how much progress has been made?
    – Anonymous
    Jun 14, 2012 at 8:17
  • @Anonymous Managers aren't working on the project directly so the only progress they know is being told to them. If this person knew they were leaving they probably just blew smoke out of spite or just laziness or just stupidity. I have been in this situation before and it is not fun precisely because when management realizes that they have been lied to about 90% done, it reminds them just how little control they really have most of the time.
    – maple_shaft
    Jun 14, 2012 at 8:56
  • @maple_shaft - In that case, the managers in question are not doing their job correctly. Their job is to manage a team to arrive at particular goal. If they are not tracking progress and delegating tasks accordingly, what are they there for?
    – Anonymous
    Jun 14, 2012 at 9:00
  • 1
    @Anonymous- You been working as a software developer for very long ;-) ? Over the years my opinion of a good manager has fallen to a person that stays out of my way and occasionally clears roadblocks.
    – maple_shaft
    Jun 14, 2012 at 9:15
  • 1
    @maple_shaft - Lol, that's fair enough. Obviously that management style hasn't worked out for the op's company. :-p
    – Anonymous
    Jun 14, 2012 at 10:22

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.

  • +1: If possible to do, this is probably the simplest and most effective solution.
    – Leo
    Jun 14, 2012 at 9:28

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.

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