Developing With Smaller Steps

My son has been learning to ice skate over the past months. I was lucky enough to use some of my software development skills, to help him become more successful. Here is the story of how my four year old learned how to skate and how you can build better software.

After getting my son all suited up and ready for the ice, he had his first lesson standing by himself. His second lesson started almost immediately: getting back on his feet after falling. His third lesson was how to move his feet. This was where it got more challenging: as soon as one foot moved, he needed to try and regain his balance. He would then move the next foot as quickly as possible to “fix” things; unfortunately, this caused him to fall faster.

He was persistent and kept trying as hard as he could. Eventually, I convinced him to take smaller steps; this allowed him to keep his balance throughout the movement and never need to react to any major changes. He moved slower like this, but he spent a lot less time getting up off the ice.

Somewhere there must be a lesson in developing software solutions:

• Small steps allow you to be in control. 
• Large steps expose many possibilities for failure.
  

So when I started coding my most recent project I started thinking about taking smaller steps. Instead of doing two or three things in my code or test, I just focused on doing one thing. I make a change and immediatly validate the outcome. If it didn't work I need to rework that modification. Once I am satified I have met my expectations, I move on to the next task.

Small steps allow you to get from project start to the other end of the ice without falling. Don't be tempted to code in “big steps” just because you are on a creative roll. Instead, try writing down some “small steps” on index cards; if these steps are written as tests, you will have the start of a TDD solution.

Take those index cards and start coding the solution to the first test. When you can prove that the first tests passes, you can then move onto the next test with confidence. If you suddenly realize you need a new test while coding a small step, write it down on a card. Don't stop working on that small step until it is complete.

If I coded a solution for eight hours without any validation, I can assure you the solution would have bugs. Trying to validate those changes, certainly would take longer then the original solution. Obviously, coding for one hour (a smaller step) followed by some testing would be a better, more efficient practice. Shorten that time to less then five minutes and you will be on your way to success.

How big are your steps? Can you make them even smaller?