The history of Taking Baby Steps
Let me tell you a story on how I thought about teaching other programmers how to take small steps to help them minimize the mistakes by focusing on a small thought.
A couple of years ago I was working on a legacy project, meaning I did not know anything about the business, and it was written in Delphi .Net which was totally unknown to me. I needed to translate this medium-sized code-base from Delphi .Net into .Net / Silverlight.
All the team was using a centralized source control system, namely TFS. But I needed to be sure that the steps I take are safe in my routine of translating the code from Delphi .Net to Silverlight, so I put in place Git. It helped me ensure that the steps I do locally are the good ones. I had done this before, using Git or SVN as a local source control while my team was using SVN as a centralized repository for the source code.
I started copying the Delphi code into C# class files and changing just the syntax so that the editor will not complain. This was my first step, then commit locally. In the beginning I did not know how to change the syntax fast enough so I did everything by hand. After doing that for a couple of classes I realized that I was repeating some actions that I could automate by using the replace function with some regular expressions or wildcards. Anyway the first milestone for committing was the editor check.
The second thing was to start and write tests for every interesting behaviour I saw in that code base. I was doing the usual steps when writing tests on legacy code: write the simplest test, see it is red, steal the output, put the output as the expected value and make the test green. Of course, the second milestone for committing locally was the green test. I promised to myself to commit only on green. I kept my promise around 95% of the time…
I continued adding all the necessary tests by applying the value sampling and behaviour slicing techniques. When I was happy that I wrote all the tests it was time for the fun part: REFACTORING :). I don’t know about you, but I love refactoring. Almost always I was using The Four Elements of Simple Design to take the refactoring decisions. I was refactoring small methods into the existing class and then those methods to new classes out of the initial class. Then I was adding some more tests needed because I was adding collaboration behaviour between the two classes. Again when all the tests were green was the third milestone to commit to the local source control.
When I was happy with the refactoring and with the design I took the next class and refactored that one and so on… until the big ugly class arrived! It took me two weeks and a half to refactor that one class! I extracted around 35 classes out of it and I was still not satisfied, so the number of classes reached around 45 in the end. But in this process it happened that I had to go back some 7 commits because I had made a terrible mistake in all that messy code: I had changed the behaviour of the initial code. I did not know exactly where I did that, but I looked into the good commit messages and I figured it out fast enough. Then it struck me: I cancelled almost two thirds of my day’s work! Why is that? WHY?? I was so annoyed so I started to figure it out.
It seems that the commit time increased drastically and the 7 commits happened at a distance of around 45 minutes. Then I realized that if I had made smaller steps I could have prevented this. I was just not focusing enough, and the commit contained so many changes so I needed to cancel all that work.
That is the time when I combined this frustration of mine with my desire to create a session for coderetreats where people would commit their code into source control repositories. The result was that I wanted to see how often I could commit, still respecting the rule: commit on green. In a couple of days, maybe one week I ended up lowering the average commit interval from around 45 minutes to 4 or 5 minutes. Some commits were really fast, after 30 seconds of work. Some other commits were longer at around 7 or 8 minutes. I started analysing those longer commits, and I understood how I could transform them into more shorter commits.
In the end I was happy that I was seeing progress, I was focusing on one thing, and the log of my Git looked great. If anyone wanted to ask me what I was working on, the answer was simple: git log 🙂
A couple of days after that I talked with Erik and told him about this idea: let’s make a session to force people to commit every two minutes. I can commit at 4 minutes, on average, on a legacy project where I don’t know the business and one of the languages, so they should be able to do this on a new code base with a simple problem and a language they know! Erik liked the idea from the start, and then refined it until the form of today. Then we gave this name “Taking Baby Steps”. Why? Because a small step is sure and steady, whereas when taking a large step you could be in danger of falling.
Setup source control repository.
Setup a timer for 2 minutes interval when you start.
Write exactly one test
If the timer rings and the test is red then revert and start over.
If the test is green before timer rings then commit.
Restart timer (no discussions in between timers)
If the timer rings and the refactoring is not complete then revert and start over.
If the refactoring is complete before the timer rings then commit.
Restart the timer (no discussions in between timers)
Go to 3.
When session time is up delete the code.
I will come back with a post about the technique itself and the learnings triggered by facilitating this session this last year.
Please take a look on Erik‘s write-up about this workshop: http://talboomerik.be/2012/01/16/taking-baby-steps
Many thanks to Erik for creating this session together with me!
Update: Please read my other post about Taking Baby Steps here.
Baby steps image credit: http://pixabay.com/en/baby-monkey-blue-outline-symbol-23991/