In my professional life I'm finding it's more and more common for me to be working with a legacy code base. Whether that's because a system we've written is simply long-standing and has become legacy or whether it's because we've inherited a system to support and maintain, the problems you encounter are pretty similar. However I think it's worth pointing out one of the major differences, and why it's sometimes better to be involved in the latter situation rather than the former.
I'm a big fan of egoless programming but trying to separate people from their code can be hard to achieve. Indeed, if you were responsible for creating the system that has become legacy it can be extremely difficult to be entirely honest with yourself about what state the system is in. Now that's not to say people cannot admit their own mistakes, just that sometimes because your head is filled with all the history of why certain decisions where taken it can be difficult to look at things entirely objectively. Ultimately, the system is where it is and how it got there is relatively unimportant.
As it transpires though, I'm currently involved in working with a legacy system where I've inherited the code. The original developers are gone and whilst their experience and skills are most definitely missed, their absence allows a certain amount of freedom in moving things forward.
I think being able to look at a system without the baggage that often builds up helps in two ways:
- You don't have any pre-existing priorities about the things you want to fix - I know that whenever I deliver any system there are always things I'm not happy with and this can sometimes cloud my judgement about what is really important.
- You don't worry about upsetting anyone - I know from painful experience that developers can be sensitive souls and sometimes they simply cannot be separated from their code.
So from my experience I'm convinced that it's always nicer not to have had a hand in the original system development if you're going to moving it forward...
 |
 |
