Scheduling an extreme programming advocate to talk to software architects might seem a good recipe for an argument, as extreme programming (or XP) emphasises quick and flexible code work over an ironclad developmental plan.
“We love architecture, and we refuse to let an hour go by without working towards it,” he told a meeting of the New Zealand chapters of the Worldwide Institute of Software Architects [WWISA] last week. “But we hate architecture stages.”
Architecture should be evolutionary, he says. The shape of a software system should change according to the evolving needs of the customer and the skills and available tools of the developers.
Agile development processes facilitate change and “emergence”, says Dollery. Emergence is a technical term from chaos theory referring to the appearance of a pattern from phenomena initially generated in a chaotic way.
Such a process will be facilitated better by a “tiger team” of architects seeking out that shape as the system emerges than by deliberate advance planning of architecture, he says.
There is little point to an architect mandating that development be done in Java according to certain standards, says Dollery, when an individual developer may have impressive skills in Microsoft development tools or a certain part of the system may lend itself to development using these tools. Providing an interface can be put in place to relate the Microsoft module to the rest of the system, this will be the most efficient development route.
The need for such interfaces does not compromise XP’s key aim of simplicity, he says. Simplicity is differently defined for different applications, he says, and a system full of intermodule interfaces can still be the simplest and fastest way of developing the system.
An architect at the meeting suggested this attitude would make maintenance difficult. Dollery replied that XP practice draws no hard line between maintenance and development; systems continuously evolve.
It is better to have an agile system than one that was designed to a predefined architecture and subsequently “hacked” when new needs did not fit the original design, Dollery says.
Despite the appeal of the “architect” metaphor, IT development cannot be compared to the erection of a building, Dollery says. The latter obviously needs a plan. Attendees suggested, and Dollery agreed, that a better comparison perhaps lies in civil engineering work, where plans often remain agile to cope with unexpected contingencies in soil conditions and the like.