Words on software and web development


Posts Tagged ‘software development tactics’

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…

Software strategies & tactics

There has been a lot of hoopla over the years regarding various software development methodologies. Personally, I’ve found that many of them distract from the real issues in software development. The only one that I’ve found appealing is Scrum, which is far more lightweight than most of the more traditional methods.

I find one thing missing from Scrum, however. Like most methodologies, it focuses on the strategic aspects of software development: what are we going to do, what are the steps we can break it into, how can we track our progress through those steps. It does not deal with tactics: how should code be organized, how should code be written, how should code be reviewed (if at all).

Advocates of various methodologies and certification models such as CMM (Capabilities Maturity Model) are probably jumping up and down and screaming, “But our approach WORKS!!!”

And I agree with them. All of the methodologies that have survived do so because they work. However, I’m more concerned with WHY they work than WHETHER they work at all.

Good software development aims at a balance between creative drive and consideration of consequences. There are many bright young engineers who can write code that works and find creative and well thought-out solutions to difficult problems. However, in my experience there is a widespread lack of considering the consequences of code changes or rewrites. Finding a better balance, where “better” means that the quality of code produced is superior, more maintainable, less bug-ridden, and better fits the requirements, involves a different approach.

This is what I like to call “delta-driven coding.” Anyone who spends a good deal of their time managing large chunks of other people’s code through merges will relate to this idea. Creating new code is also introducing a delta, or change.

And this is where we get back to tactics. Most methodologies are successful for a number of reasons, but one prominent (and slightly embarrassing) reason is this: they produce better code simply because they slow things down. In other words, most methodologies produce better software for the same reason that reduced speed limits are claimed to save lives: when people drive slower, they think more about where they are going and have time to react intelligently (if sober).

If we recognize the importance of delta or change, we can focus on the aspects of lightweight methodologies that encourage us to consider the impact of every change. This is the key to effective delta-driven software development.