Exploring the difficulties of taking over an entire system, usually undocumented (see footnote) and understanding it.

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, however there is any documentation, and worse the code can often be appallingly badly written, not following naming conventions, quick hacks left in. etc.

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.

However, there are times when it's the entire system that is dropped onto your lap, often at a moments notice 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.

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.

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.