Pair Programming and course correction

I listened to this episode of Troubleshooting Agile recently, and they were discussing early course-correction. And it made me think of the ways that many people in companies write software.

If you work in iterations or sprints, then you are hopefully showing your work to a customer or product owner at least once every sprint. Why do we do this? Because it gives a chance to look at our progress, and to change direction if we need to.

Of course, it’s even better if we can have these conversations on a more frequent basis. Every conversation with a stakeholder gives us a chance to correct our course.

Now, many people like to program solo, and then have their work peer-reviewed. This, along with feature branches, is a model that works really well with open source software, allowing strangers to contribute to an open source codebase. But it does mean that the peer review is the first time to course-correct. If something is seriously wrong with the design or the implementation, then the maintainer of the codebase can fail the review, and the person submitting the work can start again or rework. This optimises the workflow for the person maintaining the codebase. It might make the contributors life more difficult, but the maintainer is interested in the quality of the software that they are maintaining, and not the happiness of strangers who want to help.

But this is not a good model when you have a team working on a shared codebase. If you don't look at your colleague's code until they have completed some work and raised a pull-request, then your options are very limited. If they made a bad decision to start with, then asking them to rework it completely means that lots of time has been wasted. Maybe they haven't designed the code so that it can be tested, so trying to add in tests at the end will be difficult. But you don't want to make life difficult for your team-mates, and you don't want to waste their time either. So this creates a tension between wanting to maintain quality, and wanting good team relations.

It is far better to build in quality form the start, and to course-correct as early as you can. The longer you leave it after a bad decision, the more you will have to undo. Software is complex, and we should optimise for quality and simplicity. And the best way to do this is to pair or mob. 

Comments

Post a Comment

Popular posts from this blog

We always start from where we are

Image
Earlier on in this year, I had a really interesting discussion online with Duncan Hothersall about Scottish Independence, and Brexit. I support independence, and Duncan very much doesn't. Scotland is currently about evenly split between supporters and opponents of independence, with a small number of hardcore unionists and nationalists on either side. But many people are in the middle, and weigh up the decision based on the perceived pros and cons. In itself, this disagreement between Duncan and myself is interesting. We share a similar world-view and similar hopes for the future. We agree in many ways on the kind of future we would like to see. But we disagree on how we want to get there.  This is of course a common pattern. We often share a purpose with other people, but we disagree on the tactics or maybe even the strategy for how to achieve it, and there is a wealth of literature on how to resolve such disagreements.  But what I found fascinating was how we both responded to B
Read more

Mobodoro

On our mob, we have started using the “ Mobodoro ” technique, which I picked up from Willem Larsen at Hunter.  The idea is based on the “ Pomodoro ” technique, where you do 25 minutes of solid work, then take a five minute break. And repeat.  But with Mobodoro, we have a couple of minutes to plan, then we do repeat mob rotations of 2 or three minutes, adding up to 25 minutes. Then we do a quick retrospective on the previous 25 minutes, have a quick break, and then repeat.  And for the break, we have a rule that we have to leave the mobbing area. Even if we just walk a few feet and back.  The retrospectives have been great. Often we have nothing. Because we’re only retrospecting on the previous half hour. But quite often we find something small we can change: a better way of using our whiteboard; a new chair; changing the mob rotation time; buying some Lego to keep track of our work.  The day seems to go much more smoothly, and at a much more sustainable pace. Two or three minutes brea
Read more

Gilded Rose Katas

Image
Introduction Last Summer, I had the pleasure of bringing Amitai Schleier into my company for a few days, as part of his coding tour . One thing that really inspired me was his emphasis on a Learning Hour each day, and on using katas.  Katas are a short set-piece practices. The word “kata” comes from the Japanese martial arts tradition (形 - literally, "form") and is used to describe a regular repetitive, choreographed practice. Wikipedia gives a good description here  https://en.m.wikipedia.org/wiki/Kata . In software, there is a good collection of these set-pieces. Implementing FizzBuzz in a new language is a good example.  So, after Amitai’s visit, I started running katas every day. It took us a while to establish them, because we don’t have set starting or finishing times. But we now do half an hour of katas every day after lunch. We have used the time to look at TDD, TCR , Haskell, and we have used several well-known katas.  But the one we spent the lo
Read more