Taking over someone else's code

There will always come a point in any software system where the original developers move on and yet someone has to maintain what has been written. In an ideal world the system would be well documented, with pictures covering the high-level design, low level documentation is a waste – we can all figure that out from the code.

Rarely is ther any documentation and even worse the code can often be appallingly badly written, not following naming conventions, quick hacks left in.

Always aim to understand the minimum possible, and assume that the rest of the code is working as it should (even if it isn’t – it’s the mental process that is important).

Often I’ve had to take over someone else’s code – that’s not too bad, fitting into a team and taking over is fine – the support of the team to guide you in the early stages, discussing what should be done.

Try to understand the big stuff first – how each part of the code hangs together and what is being achieved at a high level, then work downwards.

Sooner or later a large system will become your responsibility. and it’s time to learn it. This process can take months, depending on the complexity even a year. The goal and the only way to approach it is to be fully conversant by the end of the process, sometimes even understanding the way that the system is constructed better than the original designer.

Being a junior won’t protect you from this. I’m speaking from experience as my first project at my first job was to take over and maintain a system that was 6 inches high when printed and contained 200 modules.

Many systems are not designed, or at least start off with a design, but by pressure, ignorance or ineptitude evolve, sometimes, and all too often into a sprawling mass of code. We have to understand this, and in the first instance make sure that any new pieces are built sympathetically, to the current system and also mindful of where the code and system should end up at.

After months of effort usually you can take an existing system and repair the design
the implementation and most of the code. Almost always you end up with a something that is similar rather than different.

When working with production code the first thing is check the current codebase built and working – and verify that it is as per the production system.

All too often programmers fail to comprehend any given piece of code, and re-write it, rather than taking the time to figure it out, on the assumption that some amount of design went into it.

Rewriting existing code is dangerous, throwing away code without understanding it is also dangerous. Much better to take longer and understand what is going on, and then fix it.

After time has passed, and changes have been made you will have adopted the orphan code – lovingly nurtured parts of it back to live and genuinely had to remove the rotten parts. The most useful comments in any piece of code tend to be the revision history – that way with a quick look I get to know the original developers and how good they were. Sometimes just seeing who wrote a module is enough to convince you that it probably would never have worked – and should be re-written.

A large sheet of paper and a pack of 10cm^2 post-it notes always help me along. Each post-it is a component of the system, and I can move them t