Understanding bad code

I always used to think that there was probably a good reason behind things I didn’t understand. Now I’m far quicker at deciding that the reason is that the person who created the thing didn’t understand either.

I’m currently working with a client to aid in the handover of some source code from the original developer to the rest of the development team. An unusual project because the original developer is still around for a while. Usually this kind of work is done long after the original developers have left the project.

The original developer has worked alone on the project for 18months or so and employed some unusual coding techniques. The rest of the team don’t understand the code, find it difficult to work with and are scared of changing it. I’m here to analyse, refactor and transfer knowledge.

I quite enjoy this kind of work, and there’s a lot of it about. Too many pieces of software are allowed to decay to the point that they’re fragile and difficult to change. Some, like this piece, were even built this way to begin with. Often the team responsible for the code can’t make the changes required to enble the code to be developed further. The owners have invested a lot of money in some software that their development team is now telling them they have to throw away. It doesn’t have to be that way. I can come in, examine what they have, suggest some incremental way forward and help them clean up the code and move towards something that they can maintain and extend.

Refactor, refactor, refactor!

One of the main things I’ve discovered from working with bad code is that often it’s hard to understand what the code is doing or why it is doing it. This lack of understanding paralyses the maintenance effort as developers are scared to change things. Questionable design and unusual practices become cast in stone because people try to work out a sane reason for why it was done this way, fail, decide there must be a good reason, and leave the code well alone.

Rule 1: There probably isn’t a good reason the code is the way it is. Rule 2: Test well…