Some software architects think that agile development is an irresponsible way of creating (badly structured) software, hyped by a bunch of undisciplined hackers. Some agilists think that software architecture is a relic of waterfall-style development, defended by a bunch of bureaucrats in an ivory tower.
Both are right. And wrong.
This week I saw a presentation by Philippe Kruchten, author of The Rational Unified Process Made Easy and The Rational Unified Process: An Introduction, positioned on #60 and #96 respectively in the Top 100 Best Software Engineering Books, Ever. It was one of the most inspiring talks I have attended in a long time. Allow me to try and convey Philippe's message here, in just a couple of paragraphs.
Software Architecture is Imperative
There is no such thing as "not doing software architecture". When you start writing your first line of code, you have already made some architectural decisions (like platform and programming language). The very act of starting test-driven development also requires that some architectural ideas have already been agreed upon. And when you're setting up multiple teams for one project, Conway's Law tells you that your (implicit) architectural decisions will match your (explicit) organizational decisions.
Agile Development is Imperative
There is no such thing as "not doing agile development". (Well, in practice there is, but there shouldn't be.) The architectural decisions need to follow experimentation and proven concepts. Assessments have to be carried out to see what works and what doesn't, and architecture must be adapted accordingly. And possibly most important of all: nothing should be built that is not going to be used. This applies to both functional and architectural requirements.
Good and Bad Software Architects
Anyone who is creating a big up-front design (BUFD), using lots of bells and whistles, that constrains rather than facilitates agile development, is a bad architect. A good architect knows that he needs to spend a lot of his time among the software developers, how to document only what's really important, how to change the architecture using the developers' feedback, and how to make things as simple as possible, but not simpler. That means... being agile.
Good and Bad Agile Developers
Anyone who writes code without thinking of possible consequences, without keeping all design options open, is a bad agilist. A good agilist knows that, in order to defer design decisions, some crucial thinking has to be done in order to keep the code and the project adaptive. He knows that the code must be able to scale when the project needs to scale, and that code must be partitioned when the organization is partitioned. In short this means... creating architecture.
There is no conflict between architecture and agility.
There is only conflict between bad architects and bad agilists.
People vs. Principles
It's simply a matter of people vs. principles. The principles of architecture and agility are sound. It's just the bad (stupid, naive or uneducated) people that give either architecture or agility a bad name. I would prefer to say that architects are complaining about caricatures of agile developers, and that agilists are caricaturing software architects. But I'm afraid I wouldn't be doing them justice. The caricatures actually exist, which more-or-less defies the concept of caricatures.
There really are bad architects and bad agilists among us!
Note that I'm only talking about roles here. In many small projects the architects and agilists are the same people! They are agile architects, or architectural agilists, or whatever. No matter who does what, architecture and agility are part of every project.
Philippe Kruchten explained that there's nothing wrong with the principles. We just have to take time and educate the people on how to do it well.
My next post will be about Philippe Kruchten's criticism of refactoring, and why I think he might be wrong. Stay tuned...
Subscribe to this blog with a reader or by email!
Latest, greatest and favoritest posts:
Five Agile Competence Levels
The Agile Blind Spot
AINO: Agile In Name Only
