Broloco

In my continuing adventures with legacy code I've inherited a code base that initially had over 500 compiler warnings. Now many of these warnings were pretty straightforward to fix but some of them are proving a little more interesting. My current personal favourite is CS0252.

I've got around half a dozen places where it's really unclear as to exactly what the original programmer was intending to do. Was he/she really meaning to do a reference comparison? Unlikely. So now I've got an interesting predicament. Do I change the code to remove the warning or do I leave the code as is and accept that as it's a legacy system the code must work fine. Safety (and sadly professionalism) must win and in these situations I must leave the code as is until I get round to covering the relevant code with tests. However it's like a real stone in my shoe and I've got to ask: wouldn't it have been so much nicer if the original programmer simply looked at the warning and thought, "I don't think that's quite right...."?

So the moral of the story is please pay attention to your compiler warnings. They'll help you identify potential bugs in your code and they might even help write code that's easier to understand and consequently more maintainable.

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:

1. 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.
2. 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...