Taking baby steps

Adi and I have been thinking about doing a session around using source control during the coderetreat. It should be a session that really motivates you to commit fast and often. It should help you to focus on taking the smallest step possible. It is only through taking the smallest step possible that you can really focus on the behavior of your system and let the design flow out of that. We really wanted to find something that helps you stay disciplined about taking really small steps.

One specific situation where this technique can prove extremely valuable is when you are discovering what a legacy system is all about. These fast commits can be a good tool to help you understand your system if you are unsure about the next step to take in your refactoring. By taking small steps and committing these, you can really start to understand the system while reducing the risk of making mistakes. You can really experiment with your system and revert easily.

First you need to setup your source control repository. It doesn’t really matter which one you use. We choose git for our example because it’s fast and easy.

Set up repository and working branch

  1. in the console/terminal: go to your project folder
  2. git init → initialize origin/master branch
  3. do initial setup (adding references, building project structure, …)
  4. commit
  5. git branch working_branch_name → create a branch of the master/origin
  6. git checkout working_branch_name → choose to work on the working branch
  7. git status → to check that there are no pending changes
  8. start working

How the session will run

  1. Setup a timer for 2 minutes interval when you start
  2. 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
  3. Restart timer
  4. Refactor
    • If the timer rings and the refactoring is not complete then revert start over.
    • If the refactoring is complete before the timer rings then commit
  5. Go to step 1

One important note: there can be no discussions in between timers, everything needs to happen within the timeboxes.

Apart from this we also need to know some basic git commands to commit changes to the branch and revert the branch to the last committed version:

How to commit

  1. git add . → track all the new files of the branch to version control
  2. git commit -a -m “commit message” → a = commit all changed files, m = message. The message cannot be missing or be empty.
  3. git status → to check if all changes were committed

How to revert

  1. git reset –hard → revert to the last committed changes on the branch
  2. git status → to check if all changes were reverted

How to delete the working branch when the session ends

  1. git checkout master → revert back to the master branch
  2. git branch -D working_branch_name → delete the working branch
  3. git clean -f -d -x → delete all the untracked files. f =force, d=directories, x=remove ignored files too
  4. git status → to check if all changes were reverted


What have we learned so far
After two experiments with this session we can already give you some feedback from several participants. The 2 minute rule is frustrating at first but it keeps you extremely disciplined in looking for the smallest step. It really helps you to keep yourself and your pair focused on the real problem and behavior. There is no time for gold-plating and design discussions.

A couple of the people were interested in putting this technique to use with a bigger time limit, 5 or 10 minutes for example. We had to keep the limit low enough because of the 45 minute time limit during a session. And we totally agree that when using this technique you want to aim for a bigger time limit.

If you try it out, let me know what you think about it and leave a comment here.


  1. How are you doing Erik? First of all, thank you very much for having written this.

    Almost 6 years later here is my comment: we’ve tried it out while facilitating the first code retreat in Asturias (Spain). Some brief notes:

    – Making it in 4-minute cycles, participants (without too much experience in TDD & pair-programming) became less frustrated than expected 🙂
    – Certainly expected, one of the shared learnings has been: “I’ve learned how little code can I produce in 4 minutes.”
    – This session has been reported by some participants as the “thing which surprised me” during the closing circle. They’ve explained how forcing themselves to work in small units helped them lead the solution’s design in a really iterative and directed manner.
    – A common reflection during the closing circle: “I’d like to improve my development environment setup.”
    – (Pointed out during the session retro) It’s been an awesome exercise helping participants realize the gap between “my day-a-day level” and “the perfect level”, which Corey used to remark during his introductions: ”

    In addition to that, and interestingly enough, we realized, that even if the general feeling was “these cycles haven’t been long enough to do anything”, participants have completed way more red-green-refactor cycles than in previous seasons.

    I’m looking forward to use this constraint again and again, and already have some ideas to get most out of it in the future (e.g.: insist on heavy usage of shortcuts and snippets, leverage “fake it until you make it” and triangulation, etc.).

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s