Helping your developers to maintain other people’s code

What is so difficult about maintaining another developers code? How can you as a development manager or architect ensure that all developers on your team can maintain any other team member’s code?

These are the two questions I want to quickly answer in this post. This post will lead into two other posts about creating a model or template for Batch Jobs and another one for Standalone Daemon Processes.

To answer the first question I posed above, ask yourself “When I was a developer what was the hardest thing about trying to fix a bug in someone else’s code? Where do I start?” You will quickly realize that answer to the question lays in the question itself. “Where do I start?” This is usually the most difficult problem faced by a developer when they begin looking at some else’s process.

As a developer the first thing you want and need to do is run the process on your own machine or in your own development environment so that you can watch what it’s doing and try to observe the bug for yourself. You need to do this on your own machine for a variety of reasons, the first being, it’s obviously not safe and in most industries or companies not even allowed to debug in a production environment.

Setting up your development environment to correct run and then debug someone else’s code is usually the most difficult thing about fixing a bug. The bug itself while challenging is usually a secondary issue when you first start to take over maintain someone’s code.

As a development manager or architect you can help eliminate this issue all together by creating a template or model for ALL Batch Jobs in your system, and then again for ALL Daemon Processes in your system.

It sounds simple, and when you think about you, you will probably ask yourself “Aren’t most systems architected in this way?” The answer from my experience is NO. Usually the collection of Batch Jobs and Daemon Processes in large enterprise class systems vary as much as the number of core developers or team leads your have in your development group.

This presents a big problem when it comes to maintenance of these jobs and processes because you cannot quick ramp up fixing bugs or making enhancements, especially when a developer who original wrote the process leaves the company or moves on to another project.

Also, the ability to reverse engineer someone’s process is a special skill that not all developer possess. I have founded that usually if I can setup a process to run on someone’s development environment in my team, they can then fix the bug or make the enhancement, but the actual setup usually is the problem which I can only rely on a handful of people to cover.

I have touched upon this issue in my other posts on How we Build Software; especially around resource management, where I spoke about ensuring loading of properties or configuration and database connections.

I’m limiting this post to Batch Jobs and Daemon Processes, however the same issue exists across all types of components of an enterprise system, from Middleware to UIs. I choose to limit our discussion today to Batch Jobs and Daemons because they are the most common and simplest examples where issues of different coding styles directly affects the teams ability to turn around fixes and enhancements quickly.

Also, these elements are usually where the most freedom of developer’s coding expression can take form.

By creating a template for ALL Batch Jobs and Daemon Processes within your systems which you mandate are followed by all your team leads, architects, and developers on your teams, you will ensure that the maintenance responsibilities for these processes are more easily be transferred from team member to team member.

Once your developers can run one of your Jobs or Processes, you can be sure they can run ANY of these jobs, and once they have them running in their own development environment, debugging and enhancements follow much more quickly.

If you combine this with my recommendations on resource management, building an Enterprise Commons, and everything else I mentioned in my how we build software post, I’m sure you will have a consistent system which can be maintained for decades.

In my next two posts, I plan on going over my own two templates for Batch Jobs and Standalone Daemon Processes. I will even give you the actual code of the templates.