As you may know, I’ve recently started at a new position here in London. Last week I was pair programming all day, every day, with a couple of the other developers, learning the ins and outs of the system. It reminded me of an important tip for beginners: good pair programming requires both driver and observer to maintain focus between making a decision and implementing that change.

Renaming a class or a method can be done throughout your code in a fraction of a second with built-in IDE shortcuts. But something like promoting a static method to an injected service (still a pretty common refactoring) can easily take a couple of minutes to actually do. In this time, there’s not much going on for the observer, except listening to the sound of typing. And waiting. And trying not to get bored.

(If you’re unlucky enough to be paired with me, I’ll probably be completely distracted and playing with all the things on your desk by this point.)

Now, I am no stranger to pair programming, and have used it many times before for small tasks. But this is the first time I’ve ever done it solidly for several days at a time. This past week has been a real eye-opener for me in terms of quickly making code changes; although I have been using ReSharper for a while now, I have a new found appreciation for its keyboard shortcuts, and people who can use them effectively. Which sadly doesn’t include me yet.

Using your mouse to navigate code and poke through menus is just too slow, and it really shows when you are refactoring code in front of someone else. A good driver minimises the lag between agreeing on a change and effecting it with lighting-fast typing skills. So unplug your mouse, and go learn your tools’ keyboard shortcuts!

March 4th, 2010 | 5 Comments

Yesterday I attended BarCamp Agile Wellington, and although I had to leave early, I thought the event was a great success.

In keeping with the theme of BarCamp I thought I’d share my notes from one of the sessions: an unmoderated group discussion on Agile advocacy in large organisations, and how to convince stakeholders to adopt it.


  • Unfamiliar jargon.Terms like Agile, Scrum and Extreme Programming can be unfamiliar and scary to those who don’t understand them. What was wrong with regular programming?
  • Agile can’t guarantee certainty. A CIO’s job is to manage risk, and having watertight specifications locked down before projects commence is one way to combat it. Agile may appear riskier by leaving too much room for change, particularly in the public sector.
  • Getting the customer on team. Heavy time commitments and taking a burden of responsibility for the project’s success may not be attractive to customers.
  • Agile is not about playing cowboys or cutting corners. Agile is actually more disciplined than traditional waterfall-style frameworks.


  • Hold the jargon, please. Don’t mention Agile, Scrums, Extreme Programming, or the Agile Manifesto by name. They aren’t really that important anyway. Perhaps ‘Agile: Everything but the name’ would be a good mantra to adopt?
  • Agile produces a self-managing team. With greater involvement from team members and customers, the traditional project manager role becomes redundant.
  • Lock it down. Sell a fixed timeframe with a fixed budget, but leave the scope open. Focus on the overall end result of the project rather than individual requirements. This way the size of your project box will be limited, but the blocks that fill it can be swapped and rearranged as you go.
  • Sell it inside out, from the bottom up. Instead of trying to convince CIOs about Agile (who more-likely-than-not will see any change as risk), focus on the people who will actually use it. Change and new ideas are interesting to developers, but scream risk to stakeholders.
  • Don’t tell upper management. Do they even need to be aware about Agile before it can be used? Do they even know what current frameworks their organisations use? Trying to convince them on the benefits of Agile may be a complete waste of time. Sell them on completion of a successful project instead.
  • Just get on with it. Why bother convincing people about Agile at all? The evidence is there, so just get on with it!
December 8th, 2007 | No Comments Yet

This Friday I will be attending my first BarCamp here in Wellington. A BarCamp is an “open source” workshop-style event that focuses on user participation and freedom of information.

Mike Riversdale (who I worked with briefly at the Christchurch City Council last year) is running BarCamp Agile Wellington on Friday December 6 at Deloitte House. The theme is Agile and will include seminars on related topics like Scrum and Lean, and how they can be applied to other disciplines such as project management and information architecture.

Mike has assured me that BarCamp’s Fight Club-style “everyone must present” rule will be relaxed, which is lucky for newcomers like me!

December 4th, 2007 | 1 Comment