Words on software and web development


Posts Tagged ‘Tactical software development’

Deltas in software development

One of the keys to quality in software development are deltas, or changes. This is an aspect of what I call tactical software development, or those aspects of software development that are more focused on “how you should write and test code” rather than “how should you plan and organize projects.”

Pair programming, for example, is often considered a part of Extreme Programming, a popular lightweight methodology, yet it falls under the umbrella of what I’d call tactics.

Pair programming is effective because it puts two pairs of eyes on every line of code that is written, as it is written. One person is always waiting to get his or her hands on the keyboard, and in the meantime can think about how the next piece of code can be written. Pair programming also speeds up the ramp-up time for getting a new person started on a project – the new programmer is paired with someone who is already familiar with the project, so there is very little time needed for the new programmer to try to figure out where to start.

Pair programming has its drawbacks, however. It only works when schedules are normalized so that everyone works the same hours – not always a problem in the traditional office environment, but it means that alternatives like occasionally working from home will either be restricted or will be done outside the pair programming paradigm.

Adding a lightweight process called Technical Walk-Through (or TWT for short) provides many of the benefits of pair programming but with added flexibility. Here’s how Technical Walk-Through works:

  • All changes to a project, whether changes to existing code or adding new code or components, are broken into change units. A change unit should correspond to a single version control commit, and should always represent a functional change. It is unacceptable to check in code that will break the build or that is incomplete, other than in some exceptional circumstances.
  • Before a change unit is checked in, the person who worked on it will prepare a directory where copies of the before and after code along with diff listings are available for review. They will then write a document which explains the changes enough so that another software engineer looking at the diff or source listings will be able to make sense of the changes.
  • Another team member will then go through the document and all the changes. Reading code changes can be tedious but is meant to catch oversights. It also provides cross-training on different areas of codes. The reviewer need not be someone as experienced as the person preparing the changes, but they are responsible for understanding every change.
  • Finally, if the reviewer is satisfied that the changes make sense – the reviewer is not responsible for testing the actual code, only for making sure that the changes make sense and don’t have any obvious errors or omissions – the changes are checked in with a checkin comment which may contain a synopsis from the change document, and perhaps a unique identifier for the TWT.

If one prolific coder has worked for two weeks adding a new subsystem to the Linux kernel, for example, it could take another experienced programmer an entire day just to read through and understand the changes. Part of the benefit of this process is that it makes the person who’s about to commit changes think about “why did I do this?” and in many cases, problems or loose ends will be caught before even submitting the TWT for review.

It also makes coders more aware of the need to write code in a way that appropriate comments help someone who is reading the code for the first time to quickly grasp what’s going on. But that’s a topic for another day…