If the country’s climate has become extreme of late, perhaps it can be blamed on a new programming methodology in use at the Met Service.
The service’s information boss, Marco Overdale, has been introducing extreme programming to staff since attending a seminar on the subject in Auckland last year.
Extreme programming, or XP, is a code-cutting methodology that emphasises constant communication between programmers and customers, and encourages simplicity, testing and delivering code in small, ready-to-use chunks.
“It’s aimed at making the connection between what people want and what programmers produce more direct,” says Overdale, who discovered XP in a computer publication whose name he can’t recall.
Last year he heard US XP guru Kent Beck speak in Auckland. “At the beginning I was cautious about yet another flavour-of-the-month methodology. At the Met Service we say we’re methodology-averse. That’s not to say we don’t use one but we don’t adopt every scrap and rule. We like to use it lightly and to be flexible.
“But as I looked at the logical underpinnings and reasons why extreme programming came into being, it seemed like a good idea. The principles of XP boil down to simple common sense.”
Returning to Wellington, Overdale convinced executive managers that XP would benefit the Met Service and then introduced the concept to the development division’s 30 staff, half of whom are programmers.
“We’re not rushing. We’re trying to get familiar with different aspects because it takes a long time to get deep-seated cultural change.”
Overdale has spoken about XP at divisional meetings, circulated books and set quizzes awarding movie passes to the first person who can reel off the 12 practices of XP. Some staff have attended XP breakfast sessions and at the end of the month XP practitioner Bryan Dollery will conduct an in-house one day seminar.”
Eventually the Met Service will start applying what it has learned to a current IT infrastructure upgrade project.
Aspects of XP that appeal to Overdale are developing in short iterations, constant communication and the need to have courage.
“The approach of delivering small chunks of code struck me as being very useful.
Normally on a project you have to define everything far in advance before you can start programming so you’re locked into a solution that is difficult to change as requirements change.”
He says XP stresses regular ongoing communication with the customer overcoming the danger of technologists wanting to build every possible feature into a system even if that’s not what was asked for.
But it’s having courage that he finds the most interesting.
“It takes courage because you don’t have everything tied down up-front. You have to take a risk that you’ll be able cope with things as they arise.”
He says so far there has been a range of acceptance from staff. “I think it’s related to people's personalities and approaches to their work. Some will say I don’t like starting to code until I’ve figured out what everything will look like.”