The world of programming has changed quite a bit since computers were first developed. One relative constant is the way in which programs are created; specifically, the idea of source code represented as standard ASCII text. It has been decades since we evolved from using hex editors or punch cards to using text editors. I think it’s time to look at how we work with the source code (presuming that the idea behind source code does not evolve anytime soon).
Most of the programming that I’ve done required me to come in behind someone else to make changes. It is fairly rare that I do “clean slate” programming. I suspect that most programmers are primarily doing maintenance at this point. For the maintenance programmer, the number one challenge is to find out enough about the code so you can strive to be as effective as the original programmer. This is just some of the information maintenance programmers have to pick up in short order:
- Learn naming conventions well enough to be followed so that the new code mixes well with the original code.
- Find out where the documentation is and how to update it (and what kinds of information belong in it).
- Learn where and how to make common presentation-layer changes, such as error message text, font sizing, or the images used in the application.
- Discover where input validation occurs and what the validation rules are.
- Learn how to produce output in a way that is as similar as possible to the original code; in other words, if the original code combines an external resource file with a presentation template, your code should not contain hardcoded output.
- Uncover “gotchas” such as long-running loops that block the main thread, making the application appear to be hung when it is actually operating normally.
This is why it often takes two days to make a 10 minute change — or even longer if the maintainer has never worked with that codebase.
If you believe that most programmers maintain code much of (or even most of) the time, the cost of programming can be dramatically reduced by making maintenance more efficient. If you study the above list carefully, you will see that having a clear conception or model of the code in your mind is the key to being able to perform maintenance efficiently. Many of the tools from Microsoft Research’s Human Interactions in Programming (HIP) group are designed for efficient code maintenance; in particular, Backstory, Code Thumbnails, and Software Terrain Maps.
It is unfortunate that none of these items are shipping products or even in a public beta state yet. Backstory is quickly making progress; I am told that it should be available in some condition in a few months, and I am hoping to catch up with its creator then. I am looking forward to using Backstory, particularly since my current project is 95% maintenance (much of my learning about the code is to learn where in the configuration to change things).
I learn a piece of code by reading through it once or twice and then stepping through the execution in a debugger (I really like Visual Studio’s auto watches for this task). The IntelliSense in Visual Studio is a huge help because it lets you quickly see the available methods and properties of a class; the Go to Definition command is a lifesaver as well.
How do you become familiar and comfortable with a new piece of code?