Code Retreat in Wroclaw

October 21, 2010

Next weekend there’s a Code Retreat in Wroclaw: I’ll be there so If you want to cut some code together retreat with us =)

Developer! rid your wip!

October 14, 2010

I’m big on eliminating waste, I’m big on minimizing Work In Progress (WIP).

Here’s my story: a colleague asked me to pair with him because he broke the application and he didn’t know why. So we sat together. My first question was:

– “Did the app work before you made your changes?”
– “Yes”
– “Ok, show me the changes you made”

I saw ~150 hundred unknown files, ~20 modified or added files. I said:

– “That’s a lot of changes. I bet you started doing too many changes at once so you ended up with a lot of WIP. Can we revert all the changes you made?”
– “Errr… I guess so. I know what refactoring I wanted to do. We can do it again”
– “Excellent, let’s clean your workspace now”

We reverted the changes. We also discovered that there were some core “VCS ignores” missing (hence so many unknown files in the working copy). We fixed that problem by adding necessary “VCS ignores”. I continued:

– “Ok, the working copy is clean and the application works OK. Let’s kick off the refactoring you wanted to do. However this time, we will do the refactoring in small steps. We will keep the WIP small by doing frequent check-ins on the way.”
– “Sounds good”

Guess what. We didn’t encounter the initial problem at all. We completed the refactoring in ~1 hour doing several check-ins in the process. Previous attempt to the refactoring took much more time due to few hours spent on debugging the issue.

Here’s my advice for a developer who wants to debug less & smile more:

  1. Understand what is your work in progress; keep WIP under control; keep it small.
  2. Develop code in small steps.
  3. Keep your workspace clean, avoid unknown or modified files between check-ins.

longing for pair programming

November 2, 2007

Recently I’ve been delegated to consult for the designers team. I spent few iterations on improving: 1. software that helps designers, 2. processes (should I call them barriers?) between them and the developers.

Super SzczeBefore I got back to the real work I received a neat farewell-poster.

Muscles are real, obviously (that’s why I don’t go to gym – I’m afraid I could burst).

As soon as I got to the front line of real story implementation, I realized how I missed pair programming.


Pair programming is a rare win-win deal:

  • If you’re better than your pair you can teach and preach how to do things right 8=) This is how Thoughtworkers roll.
  • If you’re worse than your pair then learn and suck in the experience. This is what I like the most.

Pair programming means passion and fun. Those are the most important ingredients of a recipe for decent software.