I’ve talked about the more traditional way of software development and management in part 1. Now I’m going to introduce you to the other extreme: agile software development.

On first instinct, the word “agile” conveys the feeling of flexibility and speed. My first contact with agile software was with extreme programming. I actually had flashes of pallid faces sticking it through the night cranking out code, like extreme sports or something…

There seem to be quite a few variations of what agile software development is. From what I gather, the key points are:

• Frequent development iterations
• Focus on customer needs
• Simple designs

There are a few other points, such as delivering working software in weeks rather than months. I feel the above 3 points most affect how you can be an effective programmer personally as well as when working with others.

Frequent development iterations

The software development life cycle (SDLC) primarily consist of

• requirement gathering
• design and development
• user acceptance test
• deployment

Those phases are usually very distinct, meaning they don’t overlap in terms of timelines. This makes for very rigid deadlines. If a major bug is discovered during testing, there might not be enough time to correct it.

It also counts as one development iteration. Fine, it just runs once, so it’s not much of an iteration. But in agile development, there are many iterations. They are just much smaller in scale.

Suppose you need to develop 10 independent web forms. Don’t wait until all 10 are done before testing. Finish one, let the user test it while you continue to code the next web form. Then when the user’s done testing on the first one, your second one might be finished.

Perhaps the first one had errors. Perhaps not. Either way, you can continue to code, correcting the first or starting the third.

Hopefully you see the picture. You get feedback almost immediately, and both development and testing are done in tandem. You get a finished product very quickly, even if it’s just one well coded and well tested web form, it’s still a finished product.

The other advantage is that if pressed for time, you always have some kind of finished product at hand. It’s not the full thing, but you get something very close to it.

Focus on customer needs

In part 1, I mentioned that the point of creating software is to make people’s lives better. In particular, you want to make non-programmer lives better. The software is not very useful if you’re the only one who finds it easy to use.

Focus on how other people interact with your software. Focus on your customers because they’re the ones who are in contact with your software everyday.

I’ve found that once I start using my created software from my users’ point of view, what I originally thought was flawless code seemed riddled with inconsistencies.

I talk with many of my users on a fairly regular basis. Through an unfortunate combination of circumstances, I was laden with much maintenance and legacy code, and mostly user interfaced based. What this meant was that the moment users get an error on the screen, my name popped immediately into their minds. And I’ll receive an email or a phone call.

Through the conversations and emails, I gained an understanding of how they went about doing their daily work. And I applied that knowledge to my future development work, incorporating enhancements and design considerations I never would’ve thought of.

And one of my greatest light bulb moments came when I understood the importance of one word…

Simplicity

Make everything as simple as possible, but not simpler.
Albert Einstein

This is one of the most important points in practical programming. The Agile Manifesto says

Simplicity–the art of maximizing the amount of work not done–is essential.

For example, Microsoft Office has many options for doing the same thing. Say you want to save that Word document you’ve been furiously banging on the keyboard for the last half hour. You can click on that diskette save icon. You can do a Ctrl + S. You can click on the menu “File”, then “Save”.

Having options is good. But there’s also the case of having too many options. And the user gets overwhelmed and fails to interact with your software effectively. Why else do you think Microsoft toned down the menu bar and pushed more frequently used items to the forefront in Office 2007?

I develop smaller scaled software. So I stick to a much simpler rule. Make it one option.

There’s only one save button on the web form. There’s only one way to get to the next screen. There’s only one way to retrieve and display data, using the standardly placed “Retrieve” button, which is also standardly named “Retrieve”.

Once I started doing this, my development work simplified. Testing also simplified, since the testers don’t have to test all sorts of saving functions for instance. The users are happy, because they don’t have to think whether they did something correctly, because there’s only one way of doing it, so they must be doing it correctly! And they can continue doing what they’re supposed to be doing: driving the company business.

Closing words

I have obviously a bias towards agile software development. Yet I don’t adopt all the practices some of the proponents teach. My reason? Practicality.

I work in a small team, sometimes being the only developer. As a result, I find it hard to follow any software management method, even one as flexible as agile development.

More than anything, I need fluidity.

In the next and final part, I’ll talk about how I managed a hybrid of the rigid SDLC and the flexible agile models. If you’re a lone wolf programmer, you will find it familiar.