Project Transference

Question

I would like to know your experience when you need to take over somebody else's software project - more so when the original software developer has already resigned.

Answer 1

The most success that we've had with that is to "wiki" everything. During the notice period ask the leaving developer to help you document everything in the team/company wiki and see if you can do code reviews with him/her and add comments to the code while doing the reviews that explain sections. Best for the "taking over" developer to write the comments in the code under the supervision of the leaver.

Answer 2

We actually have a specified set of "Deliverables" that has to be present for us to take over a project.

If we have the chance we try to push in one of our folks within the group developing the project at first. That way we get some firsthand knowledgde before our group takes over the code. (in the line of what @Guy wrote)

That being said, the most important part for me would be:

• Some kind og highlevel overview(drawing?) of what the code do.
• Easy access to ask questions of the people who actually wrote the code

This for me is alpha omega when taking over code and projects

Answer 3

Cases where original devs leaved before handing over the project are always the most interesting: you're stuck with a codebase in an unknown state. What I always find intriguing is how the new devs often do their utmost best to comment on how badly designed the code is: they forget about the constraints the old devs might have been under, the shortcuts they might have been forced to make. The saying is always Old dev == bad dev. What do you people think: I would even call this out as an official bad practice: bad-mouthing the ones who have been before us.

I try to take as much a pragmatic approach as possible: learn the codebase, wander around a bit. Try to understand the relation between requirements and code, even is there is no clear initial relationship at all. There will always be the "aha moment" when you realise why they did something was done this way or that. If you're still convinced something is implemented the wrong way, do your refactorings if possible. And isolate the pieces of code you cannot change: unit test them by using a mocking framework.

Hail to the maintenance developer.

Answer 4

I once joined a team which has been handed over a pile of steaming crap from outsourcing. The original project - a multimedia content manager based on Java, Struts, Hibernate|Oracle - was well structured (it seems like it was the work of a couple of people, pair programming, wise use of design patterns, some unit testing). Then someone else inherited the project and endlessly copy-pasted features, loosened the business rules, patched, branched until it became a huge spaghetti monster with fine crafted piece of codes like:

List<Stuff> stuff = null; 
if (LOG.isDebugEnabled())
{
    stuff = findStuff();
    LOG.debug("Yeah, I'm a smart guy!");
    for (Stuff stu : stuff)
    {
        LOG.debug("I've got this stuff: " + stu);
    }
} 
methodThatUsesStuff(stuff);

hidden amongst the other brilliant ingenuity.

I tamed the beast via patient refactoring (extracting methods and classes more of the times), commenting the code from time to time, reorganizing everything till the codebase shrunk by 30%, getting more and more manageable over time.

Answer 5

I had to take over someone else’s code of different degrees of quality on several occasions. Hence the tips:

• Make effort to take structured notes of any piece of significant information from minute one: names of stakeholders, business rules, code and document locations etc. It is best to dedicate a fresh spiral notebook, so you could tear pages out if you had to.

• Make use of one of the better free indexing and desktop search tools available on the market (Google Desktop Search, MS Windows Search will do). Add all document, e-mail, code locations to it.

• Before developing anything do document analysis: find everything you can get you hands on electronically on network and printed out docs, make effort of simply reading it. There is amazingly much of useful information even within unfinished drafts.

• Mind map the code, architecture etc as you go.

• With lesser documented and maintained systems you inevitably will have moments of despair that are likely to push you into procrastination mode. Especially during your first days or week when amount of new information your mind has to digest is overwhelming. At these times it is nice to have someone to remind you (or just do it yourself) to take it easy, concentrate on important things first and revert to making smaller steps in trying to gain understanding instead of trying to leap forward.

• Keep taking notes, making diagrams, drawing rich pictures, mind mapping. It really helps to digest the copious amounts of new information, mostly disorganised.

Hei, good luck!