Agilistas are to architects as Neo is to...
This is not The Matrix. But it is
QCon 2009 Agile development practices may be growing in popularity among developers, but agilistas aren't getting much love from software architects.
The irony? Without the architects, agile will never be fully accepted in the enterprise.
That's according to ThoughtWorks chief technology officer Rebecca Parsons, opening this year's Qcon Conference, who believes agilistas need to help solve the problems architects face in gaining enterprise cred. Martin Fowler, ThoughtWorks' chief scientist and co-author of The Agile Manifesto speaking with Parsons agreed. ThoughWorks is an IT consultancy that specializes in agile development methodologies.
"Before we can get to why architects should run blindly behind agile and support it the way we think they should, we have to see the problems they face," he said.
During their Agilists and Architects: Allies not Adversaries presentation the two agile advocates talked about the benefits of light-weight development methodologies for enterprise software architects.
To illustrate what they see as a disconnect, they opened with a clip from geek favorite The Matrix Reloaded, in which Neo meets The Architect, a smug egomaniac in a white suit who tells Neo he's an anomaly in "what is otherwise a harmony of mathematical precision."
"Why is that funny?" Parsons asked the chuckling crowd. "Because it reinforces so many of the negative stereotypes - and in fact, negative examples - that we've all seen of architecture gone awry... There is a disconnection among architects from the problems that software developers are actually trying to deal with."
One of the basic principles of agile software development could repair this disconnection, Parsons argued. "Within agile there is this fundamental notion of the relationship between the development team and the customer," she said.
"It's a contract that says, 'As the customer, I get to say what I want and what's most important; as the developer, you get to say how much it's going to take to build it'. That's the contract the developer has with the business owner [in an agile project]. Why not include the architect? The architect is a stakeholder in a similar way."
Fowler laid out other benefits of agile methods. Agile brings transparency to the dev process that can free an architect from the need to create monolithic specifications that will never be followed through the life of most projects.
"Instead of trying to lay down a statement saying this is what should happen and trying to force that through," he said, "why not have a system that makes visible what is actually happening? When you can see what's really going on, you, as an architect, can react to it in a reasonable way."
Another benefit of agile is its ability to support code re-use. "I'm convinced that you don't get re-use by building something re-usable and expecting people to use it," he said. "You do it by building something use-able and then harvesting re-usable things from that."
"Sometimes when I give this talk people say that I'm too hard on architects," Parsons said. "But I understand that they have a very challenging job... They're put into very difficult positions, and organizations in general do them a disservice.
"The important thing to realize about this is that the problem is a systemic one," Fowler added. "It's about how the organization is set up, rather than a failure of individuals trapped within that system. No matter how good your people are, you can always mess them up with a bad process."®
You post anonymously and you say nothing more than "This is better than crack stop dissing it". You're the penguin that gets pushed off when we already know there're seals.
usual agile nonsense
It is typical for the agilistas to rail against anyone who doesn't drink their kool-aid, and so typical for them to create a straw-man to attack.
Software architects are the guardians of the design-it-up-front process. Agilists demonize this process as the Dreaded Waterfall Process. Thus architects must be demonized as Not Listening To Customers, so that their successes can be dismissed and their failures focused upon. Only it turns out that designing things up front works too. It's especially appropriate when you are going to have only one release (think space shot), or when your only means of communicating with coders is through a legal contract (think offshoring, think government and defense industry).
Prescriptive agile methods like XP claim it's impossible to do up fron design, but that is only true if you don't know how, and don't want to learn. Users needs don't change that much. It's only our understanding of their needs that changes. It evolves, it matures from no understanding at all to full understanding. It can mature in cycles of writing and discarding code, or by thorough analysis. This is the design-it-up-front secret that is heresy to the agilistas.
Someday we will come to the post-agile world. Process evangelists will someday lighten up and acknowledge that up-front-analysis can streamline coding. They will discover that user needs can be sussed out with techniques already written down and taught, but not in common use. They will come to understand that the XP practices are not the only or necessarily even the best set of practices, even though they are vastly better than no practices. They will encourage dev teams to ask WHY they should use each tool, not just whether they should. And they will learn to collect and act on feedback from their sprints, which is the forgotten half of the reason why interative design works.
Unfortunately, I'll be retired by then.
You dorks just don't get it
Look - agility is a relative term, it should be a gauge rather than a methodology in and of itself.
Architects are moving towards more agile styles of architecture such as REST/WOA and away from turdy things like SOAP.
I have many colleagues that I have fashioned from cardboard; they all agree with me. So there.