Baby steps

May 25, 2007 by Artem

Baby steps is one of the principles behind the eXtreme Programming and other agile methods. It is, namely, performing changes in small steps on every level, be it implementing a feature, changing the database structure or just coding a couple of methods. The ideas behind this principle correlate well with not programming by coincidence and usually baby steps are implemented with test-driven-development based techniques.

Levels

On the coding level baby steps mean changing the code in small bits and verifying that it still works after every small change. Often it means using test-driven-development, running a local set of unit tests after every change and periodically running the whole test set.

On the architecture level baby steps mean that when the need to change or create architecture arises, the change has to be performed in small steps even though the initial and final architecture might differ much. For example, when extracting some functionality into a separate class it might be a good idea to leave "stubs" in the original place and remove those only after all the needed functionality is iteratively moved to the new place.

On the requirement level baby steps mean learning to apply the agile planning methods, learning to divide the user-perceivable features into not big tasks, but smaller features that can be developed, delivered and evaluated separately. User stories can be handy at this level.

Benefits

The advantages of applying baby steps come from the fact that the smaller the piece of work is, the easier it is to think it over, plan and verify. Baby steps allow for verifying the direction often and for changing the plan frequently. When applying baby steps every mistake is only a baby mistake that can be noticed early and corrected easily. For example, when transforming the application from a single binary into client-server, the baby steps can help to see very early if a chosen technique (e.g. COM plugins or AJAXy web clients) fits well into your situation and adapt before months of efforts are invested into the transformation.

Cons

The biggest disadvantage of the approach is in the need to actually verify the application behavior often, be it the code or user-perceivable feature level. For the team that does not use test-driven-development and does not have an extensive set of unit tests, verifying the functions can take a lot of time. If the customer does not collaborate with the team often, it is difficult to verify early that the feature is done.

The "frequent verification overhead" might be a real problem in some circumstances. However, whenever we manage to make it smaller, whenever we manage to make the unit testing set faster and more reliable, whenever we manage to get the customer evaluation more frequently, the speed and correctness of delivery raises quickly.

Your experience

What step size do you use in your environment? Do you run the test sets every every 10 minutes, nightly or monthly? What is the verification overhead like in your environment?