Black Holes and the Buddy System
I recently fell into a black hole. I was creating a demonstration for Cruise Control. When I got to the part about running FitNesse tests via ant, I got all wrapped around the axle with java classpaths. I don’t know about you, but classpaths are my nemesis. It took me a long time to get it right, way too long. That is a black hole – a time sink that you didn’t anticipate and, once you fall into it, it has no obvious end point. The solution seems right around the corner, just one more experiment away. Experiment because that always seems like the most expeditious route to success – because taking the time to actually study the situation will obviously take more time than the next little experiment. It is a common pitfall for software developers. Black holes can quickly nullify your estimates.
There are various ways to get out of a black hole. There is one that I talk about in my training classes and it shows up under a couple of topics. I usually introduce it with this burndown chart, taken from an actual project.
I was the Scrum Master and also one of the developers. I was new to all of this agile stuff and probably waited too long to ask the obvious question. It came to me in time, though. In case you are also new to this agile stuff, the question is “Why are we stuck? Why do we show no progress after 3 days?”.
When I am talking about the wonderful qualities of the burndown chart, the EKG of the current sprint, I offer some possibilities for this stalled pattern. One is unlikely – that we have discovered just as much new work as we have completed for 3 days in a row. One is more likely – that it is flu season and everyone was out sick. Another is that the annual corporate re-org is in progress and we were at “strategy” meetings for three days. This graph came from none of those scenarios, however. It indicated a team problem.
On the day that I finally called timeout and asked the question in the daily standup, the first response went like this:
Developer One: “Well, I got stuck on a problem with task #14 and I knew the answer was right around the corner. I was working alone and I felt stupid and did not want anyone to know. Besides, everyone else looked really busy.”
Developer Two: “Well, I was working on task #6 by myself and I fell into a black hole. I was embarrassed and did not want to tell anyone.”
Me: “Hm. I was working on the deployment scripts. I am really bad at batch scripts. And they are really boring. I got into a black hole and didn’t want to bother any one.”
Developer Four: “I was away. What are you guys doing, working alone? You know better than that!”
We were able to break the log jam quickly then, simply by resuming our practice of pair programming. This leads me to the other training time that I bring up this story – when talking about pairing. This is something that I learned long ago, before I knew about the agile mindset. The very cheapest way to solve a sticky programming problem is to describe the problem to someone else. Even if that person knows nothing about the topic, even if they don’t say anything, your brain begins to think differently just by putting the problem into words. Often a good solution comes to you right away. Failing that, the other person may ask questions that break the spell. Or, even more likely on an agile team, the other person will have useful solutions or insights from their own experience.
I am going to claim that when working in pairs, black holes are both less frequent and much more shallow. By thinking together, discussing and proding at the code, you are less likely to get trapped by a sticky problem. By talking about it, the time spent in experimentation is usually less. If nothing else, two people have less tolerance for an extended lack of progress. And, hey, the rest of the team should be nearby to help, too.
