Calculating the risks of inherited code

At some point in their career, most software developers will have taken over a project from someone else. I tweeted about this briefly, and at the time 140 characters was probably a wise constraint in terms of forcing me to compress the issue, but the more I think about it the more it makes sense that there must be some good resources out there covering this topic in more detail.

When you inherit a codebase from someone else (be it internal person, external person, another dev company, whatever) there’s often a large amount of risk involved. The previous developer(s) will have made decisions that you  may or may not agree with, for reasons that you may or may not understand, and it’ll fall on you (and your team if you’re lucky to have one) to deal with the consequences of those decisions.

In the past I’ve simply used gut feeling to get an idea of the risk involved – I’ve looked for code smell factors to give me hints as to what to think about the risks involved, as well as analysis of other factors such as external dependencies (external dependencies with licensing implications, external dependencies which are outdated, external dependencies which you’ve not worked with, external dependencies you dislike for no logical reason) but there must be a better way. In my mind, I’m thinking of something similar to function point analysis except geared towards risk analysis, especially in the area of identifying unknowns.

So.

What steps do you take to analyse the potential risks before taking on a project like this? How far does something need to stink before you decide to walk away, if you have that choice at all?

Finally, the most important question – if you do decide to take on the project, how do you explain this risk to the customer? How do you explain the level of risk involved in a way which doesn’t come across like scaremongering?

 Print | Posted on Monday, August 02, 2010 12:46 AM |