I’ll be running a preview of my Agile 2009 workshop ‘Debugging Pair Programming’ at Skills Matter on Monday 10th August.
If you’re on a team that’s using or trying to adopt pair programming, this is a great chance to explore and understand some of the complex reasons why this is such a difficult skill to master.
The session is free, so sign up soon to avoid disappointment: http://skillsmatter.com/event/agile-scrum/debugging-pair-programming
Estimate: an approximate calculation of quantity or degree or worth
Commitment: the act of binding yourself (intellectually or emotionally) to a course of action
- Estimates are not commitments.
- Plans based only on estimates are bad plans.
- Commitments based only on estimates are at best foolish, at worst dishonest.
Estimates are certainly a useful tool for making realistic commitments, but there are many others too that are equally, if not more, useful. Working at a sustainable pace, measuring data about past performance, and facilitating the genuine consensus of the whole team when committing are the way to make plans that can actually be achieved.
I’ve written before about my views on the importance of pair programming as a way of building a common conciousness in a team. When two people work on a piece of code together, not only is it instantly reviewed for correctness and readability, but already two people on the team understand exactly why the code is like that – the design decisions and trade-offs that went into building it that particular way, and are aware of any re-usable modules, patterns, idioms or conventions that emerged during the coding session. When each of those people goes off to work with other members of the team, those memes propogate around the room surprisingly quickly.
When you write code alone, you immediately lose this benefit, and on a system of any significant size, this is really important. You might be writing terrific code, making great decisions and innovating really creatively, but if nobody on your team has experienced those decisions and innovations with you as they happened, all you are really sharing with them is the much more shallow end result: the code.
It’s almost like they never even happened.
Last night in the pub I was introduced to the term ‘corncob’, a label apparently used in some software development circles for a disruptive team member. I’d love to know how on earth that particular word was chosen.
I rather dislike this tendency to put people into boxes, as the next obvious step is to write the person off, but I guess giving these stereotypes a name at least gives you a framework for discussing them and starting to figure out what is driving their dysfunctional behaviour.
Plus we can all recognise a little bit of them in ourselves, and our fellow team-mates. Anyone else lucky enough to have a bit of an EXTRA TERRESTRIAL on their team? (Hi Brett!)