1.2 Reasons for Inheritance
It's important to know why people inherit code, because you might jump to the wrong conclusion about which one applies in your case. Perhaps:
The original developer is gone. The original developer is bored with the program and wants to be rid of it. The original developer is reassigned or otherwise has no time to spare. (Don't give up; this might be more negotiable than it first appears.) The responsibility for the function performed by the program has been reassigned from the original developer's group to your group.
You might also have been brought on board because the program might need to be modified in ways that are within your ability but are beyond the capacity of the original developer:
The program needs to be ported from one environment to another. The performance of the program needs to be improved. The program needs a data interface that uses a new protocol or format. The program has expanded to the point where it has to be restructured to make further modification cost-effective. The program performs operations that are needed by other programs and these are to be collected into object-oriented modules for easy reuse.
Here are some extremely unpleasant but feasible scenarios:
The program has grown so large that even the original developer cannot figure out how to make a change to it. The program lives in a very brittle environment of many dependencies on fragile or operational systems and any change or upgrade is bound to break one of them. The program has not been documented and the original developer has been successful at convincing management that such a task is beneath his or her dignity.
There are also a number of unsavory possibilities motivated by politics, such as an attempt to sabotage the reputation of you or your group by giving you an impossible task. Or you might have been given the project simply as something to keep you busy. Sad to say, going into information technology is no way to escape politics.
| 