Words on software and web development


Archive for August, 2009

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.

American claims InfoSys CEO is Dagwood’s PHB

Recently the CEO of InfoSys generated a bit of buzz by claiming that American programmers are mostly unemployable. I’d have to agree with him on one count – someone with his outdated ideas of organizational behavior should probably go elsewhere to find people more experienced in passive-aggressive colonial dynamics.

To put this in perspective, let me recount an adventure I had while in India a few years back. I was living in a rural area at the time, and on a visit to the greater New Delhi area to get a laptop fixed I ended up in the same building as a recent acquaintance named Ganpathi. I called him to ask if I could visit and he agreed. I came upstairs, signed in, and he took me into the office where he worked, and introduced me to his boss. The boss asked Ganpathi and I to follow him to a conference room and told Ganpathi he was not allowed to have any visitors here, and when we were done chit-chatting he could go home and don’t bother coming back again. Then he left the room.

In case you missed that, the guy was fired without notice or warning. And in case you were wondering, he didn’t work in the control room of a nuclear reactor. This is the management paradigm that InfoSys can’t really keep in the US because of employment law, but at the very least they would prefer to hire people who don’t object to being treated this way.

However, the companies that are really successful in India, like Microsoft and Convergys, have taken a more open approach to management which fosters creativity rather than the old-school colonial approach. They suffer from the same problems as technology companies elsewhere, such as competition amongst middle management and pressure to work more hours, but have discovered the real key to taking advantage of the Indian talent pool: you have a lot of raw talent to pick from, and you just need to create the right environment (both literally and organizationally) for them to thrive.

There are also those who feel the advantage of outsourcing is just getting things done cheaper, and there’s a niche for them as well. InfoSys is happy to take on their big projects and put hordes of people on them, and if any of them misbehave, they will be fired and replaced because with a billion people you can always find a replacement.