The act of writing computer code is usually a solitary endeavour. You know what feature the customer desires via a specification handed to you and it is just a matter of translating that into something the computer understands. There are times however when it is well worth the sacrifice of a little of that solitude and flow for the sake of a better outcome and a happy customer.

This week, Ben Richardson from the Western Australian Herbarium visited the Gaia Resources office to spend a day working with me to put the finishing touches on a new image management application.

We spent the day in the conference room, just the two of us with no interruptions. Just think of it – when was the last time you had the opportunity to spend your entire day with no meetings, no email, no one tapping you on your shoulder to ask you just one-quick-question – and all of that time dedicated to fixing the niggling software issues for your customer.

When I am programming, I don’t like to be interrupted. It is an annoyance faced by programmers the world over because unlike many other tasks, it can take up to 15 minutes just to get into “the zone” before anything productive can occur. Each time I am interrupted, I have to restart those 15 minutes just to get back to my previous level of productivity. It doesn’t take very many interruptions before I discover that the entire day has passed and I leave the office wondering what I have accomplished all day. There is, I have found, one exception to this general rule.

This exception is when the feature is so minor that the solution is obvious. The 15 minutes that I’m spending getting into the zone isn’t just wasted time. I am actively trying to construct an mental model of the software in my head so that I can work out what I need to do in order to write the next chunk of code. When the feature is minor however, you don’t have to spend as much time constructing a mental model of the software. The solution is typically obvious and all that is necessary is to physically type in the changes.

This was the case last week with Ben’s visit. He had a slew of minor issues that he wanted to have fixed and I had an entire day set aside just for these issues (some of which fell under our corporate policy of undertaking bug fixes for free). I didn’t have to worry about requirements because my customer was right there to explain them to me. I didn’t have to worry about prioritisation because my customer simply told me what his next biggest annoyance was. I didn’t have to worry about timelines, issue tracking, budgets or user acceptance testing. I simply had to fix one issue at a time, give a quick demo and move on to the next issue.

From Ben’s perspective, he didn’t have to worry about any long winded procedures or communication delays either. He knew what he wanted and all he had to do was tell me how he wanted the software to work. Being in the same room, he could see how long each task took to implement. When completed, he could give immediate feedback and watch the adjustments being made. Being a programmer himself, this was also the perfect opportunity for a code review.

In all it was a very productive day for the both of us. Ben (R) managed to get many of his issues resolved quickly and to his satisfaction and I get a happy customer with software that actually suits his needs. A win-win situation for everyone.

Leave me a message in the comments below, or drop me a line on email.

Ben (K)

P.S. The limes in the photo warded off scurvy nicely.