Monday, 04 May 2009 12:00

Iterative development is all about state transitions. In a nutshell, iterative development is about moving from one stable state to another in very small steps. This obviously applies to team iterations or sprints, but it also applies to daily development practices. Think of it as "micro-iterations" - it's the idea of "code a little, test a little". I would express it as "code a little (implement a small feature or fix a bug), test a little (does it work?), save your work (commit your changes)".

Now you need to be able to know when you are in a stable state. This is where a comprehensive set of unit and integration tests is vital. Techniques like TDD and BDD certainly help with design, but they also have the purpose of building up a hefty set of regression tests. I also usually run though the application and do some quick smoke tests to make sure everything looks OK. If you got bogged down in an unstable state for too long, ditch it and return to the previous stable state. I time-box my work - I set a maximum time to successfully implement a feature. If at the end of this time, it still doesn't work and I can't see the end of the tunnel, I start considering the ditching option.

Each step has a precise goal, a specific bit of functionality to implement. It might be "Add the Location domain object", "Add a set of region/location drop-down lists with AJAX updates" or "Add a captcha to the review form", but it is small, precise and clearly limited in scope. As soon as it works, I commit my changes.

That's one reason why I like git. I commit every time I get a new unit test (or set of related unit tests working), which can be every half-hour or more at times. Some commits might be experimental or provisory - I don't want to bother other developers with them just yet. I may only commit to the central repository a couple of times a day, when more significant milestones are reached.

I am actually very reluctant to leave my workstation with the code in an unstable state - it can take a lot of time to get back into it the following morning. On the other hand, sometimes you really do get bogged down, and it is unwise to burn yourself out on a particular piece of code. From this point of view, the XP approach of ditching unfinished code and starting anew really does have a lot going for it at times.

Anyway, just my 2¢.