Tag Archives: agile


Etherpad was a great idea, online simultaneous editing. After the team was acquired into Google Wave they dumped what they had in open source, and moved on. A few brave souls tried to improve it, but it was a beast, and seems to have died on the vine.

Fortunately a few new brave souls have decided to try to build a conceptual fork from the ashes of etherpad. The new version is written in node.js (all the hipness now), and called etherpad-lite. The install isn’t too bad, and I’ve gotten a couple instances up and running so far.

Etherpad has become a critical tool to me for coordinating distributed teams. We use etherpads as part of remote planning sessions. While it’s not quite the same as a whiteboard, it’s closer than you’d imagine, and the fact that everyone has a cursor makes it easy for anyone to speak up and make changes. The most important part of a plan is that everyone that’s part of it buys into it, and participation is one of the best ways to ensure that happens.

Agile Resistance

One of the things that’s most inspired me at IBM over the last couple of years has been a division wide initiative to adopt Agile development methodology among the teams. There remains a lot of resistance to such a change, but for those of us that really think this is a better way, it’s opened up a new freedom to demonstrate how much more effective we can be. We can actually point out that multitasking is bad, and completely wasteful, and not sound like lunatics any more, as it’s part of the standard training. We can plan with 1 to N priority lists, instead of time estimating tasks 18 months in advance, and have a leg to stand on. And for those of us that have really embraced Agile approaches, and surprised ourself on the effectiveness, it adds new focus and drive to the tasks at hand.

Yesterday, in a “scrum of scrums” (quotes because it’s really just a status meeting, as many of my peers aren’t really getting what Agile is) I shared with my peers some of the recent successes we had because we had stopped splitting up our 3 person team on various independent tasks, and instead got in the mindset that we, as a team, are tackling one thing at a time until it’s done. Every time we focus in this way, we get much more done. It does take vigilance to keep this focussed. Inevitably in the past we’ve backslid into slicing, and dicing, and multitasking our way into a spinning ball of busy that doesn’t seem to accomplish anything. I’m hoping this time the habit will finally stick.

I was just interested in sharing my experience at the end of our recent break through on a problem (which had happened only 10 minutes prior to the meeting). I got unsolicited comments from two of my peers effectively saying the old ways were just as good. It caused a good chuckle in a back channel.

Culture changes are hard, I know that. And with a ship as big as a division of IBM, turning it is something that’s going to take many years. But at least we’re starting.

(Disclaimer: my words are my own, represent my own perspective based on what I can see and who I interact with, and don’t represent the views of my employer.)

Pair Programming, why it works

I was recently forced into a pair programming exercise at work because we’d gotten to a critical bring up part of the code where nothing was really able to be done in parallel. Given that we are all noobs on this source base, there also wasn’t really anyone that should just go take the lead on it either. Given that 1 member of my team is actually in the same office as I am, we decided to try pair programming through it, because what else were we going to do. Jeremy brought in his laptop, and he mostly drove while I navigated as he was writing code. The results were impressive. In 2 days we got from a server that wouldn’t start, to one that was responding to half the nfs commands.

When first presented with Pair Programming most developers / managers have the same response: I’m going to have 2 people to do 1 person’s job?  That’s just crazy inefficient.  I admit, that I had my doubts, but as there is a decade of success behind this technique I decided it was worth trying.  The generic “it’s actually more efficient” statement didn’t sit well with me because there was not explanation behind it. The why it works is actually really interesting, and I think it also explains the types of problems it is good for and the ones it is not.

Anyone that’s developed software has run into programmers rut at some point.  This isn’t the same thing as writers block, it’s not the inability to create something, it’s having something not quite work and looping for hours to try to figure out why.  Typically it’s solved by going away from the code for a while (often overnight) and the solution is obvious in the morning.  When tackling a complex problem, you start building a model in your head that matches the software you are writing.  Sometimes you validate that model as you go, but often you don’t.  After hours working with that same piece of software you’ve made hundreds of assumptions on the model, any of which might be wrong.  But once it’s fixated in your head, tearing it back down to validate each and every step seems defeatist.  There is “just one more thing” that you could try and it will get you past this block.  How many times have you said that to yourself… just one more thing.  These “just one more thing” loops can easily become 4 hours in a shot.

When you walk away and come back, assuming your brain was focused elsewhere at the time, you’ve got to rebuild that model.  It’s not actually an exact copy of the model before, that’s why it takes time to get rolling on a complex software task.  And, as often as not you make slightly different assumptions this time, and low and behold you easily see where you were wrong.  Problem averted, and we move on.

But in pair programming, you don’t have 1 model, you have 2. At a superficial level, those are the same model, that’s the architecture of your project. But on a deep level, the level of actually assigning variables and doing test conditions in the code, those models are different. Those differences are why we enforce code conventions on software, because left to our own devices those differences in mental models would spill into the editors in somewhat surprising ways, making the software itself completely incomprehensible. Look at someone’s collection of private scripts they’ve written to automate small tasks, stuff they never intended to be shared, and you’ll see what I mean.

With only one person at the keyboard, and 2 mental models of the code in effect, you’ll get a nice amount back and forth when the 2 models don’t line up.  It’s kind of like unit testing for your brain.  During this exercise there was a lot of “wait, why are you doing that? … isn’t that supposed to be this other value? … are you sure that value is actually initialized in the called?”  I have no idea how many times I was right or wrong vs. Jeremy, it doesn’t matter.  What mattered is that we were constantly checking each other.  I mentally noted at least a dozen times where left alone, I would have been stuck for hours.  While not perfect (we had one rut that got us stuck for 2 hours because we’d both made the same bad assumption in our model), it seemed like we eliminated 90% of our ruts by having the second mental model.

And that’s where the efficiency comes from.  On anything other than rote code, software development is not continuous output.  It’s some number of hours hours stuck in a rut, then an hour of speedy implementation, then a new rut, then a burst…. rinse, wash, repeat.  It’s a set of fits and starts that as developers we convince ourselves was a much smoother process because we felt busy, or just because it’s the only way to do it.  But it turns out those fits are actually huge inefficiencies in the process.  They are probably one of the primary causes behind the observation that “great developers” produce 10 – 100x more output than average developers: great developers figured out how to pop out of ruts faster (either consciously or subconsciously). Pair programming gives you a simple tool to get some of that efficiency with your existing team and developers, making everyone a bit greater in the process.