This is a guest post by Rebecca Wirfs-Brock, who will be an IEEE-featured speaker at SATURN 2011, which is being presented by the SEI in collaboration with IEEE Software magazine.
Here is the abstract for Rebecca Wirfs-Brock’s SATURN 2011 plenary talk. She is also giving a tutorial at SATURN 2011 with Joe Yoder of The Refractory, Inc., titled Ultimate Agility: Let Your Users Do the Work.
Agile development has been around for over a decade. These days it isn’t edgy to adopt agile practices, merely prudent. Agile development practices bring real value to organizations that want to improve their business flexibility: the discipline of incremental delivery of well-tested software, more transparency in understanding the actual cost of developing product features, and the ability to change requirements late in the development cycle.
But yet, what if you are building software that takes years to unfold? Can you build a complex system without determining some of its architecture first? How should you tackle thorny architecture problems? What exactly is the role of software architecture for agile projects? There are two popular views on this.
The first is to simply let your software architecture emerge. This belief is founded on the practice of conscientiously evolving your design as you go. You won’t end up with a sound architecture unless you rework your design as you incrementally develop and deliver software.
The second view is that some critical investigations should be performed ahead of time. However, these explorations should be grounded, practical, and bounded in scope, and should deliver timely results that support mainstream development. Just as with any requirement, any architectural decision can grow stale if it isn’t applied.
It is tempting to say that the first approach is “more agile” than the second. But that view is overly simplistic. Both approaches avoid lengthy speculation. One supports decision making as a consequence of short experiments; the other encourages on-the-fly architectural decisions during the normal course of work. Both have uncertainty and risk: experimental results may be improperly vetted; on-the-fly decisions may be faulty.
The approach you find more appealing is partly a matter of how you react to uncertainty and how you like to mitigate risk. Do you think it prudent (or wasteful) to consciously invest in making an anticipatory decision? Do you find it rash (or empowering) to make architectural decisions in real time?
Those who divisively argue for one approach are acting like tweens who are more comfortable with concrete, black-and-white decisions than nuanced ones. But life and software development and architecture are often nuanced. It’s time to grow up. The role of software architecture activities in agile development is to support change, not guarantee that it will be painless.
And so, in these tween years of agile development, we need to recognize our options. Both approaches can work and have spectacular results. You don’t have to pick one and exclude the other. Sometimes investigations won’t pan out and sometimes on-the-spot decisions will be rushed and faulty. When we learn more, regardless of what approach we took, we may need to change our minds and our software’s architecture. Designs do evolve. Not every decision will hold up. But we’ll get better at making software when we acknowledge shades of gray, choices and change.
– Rebecca Wirfs-Brock, Wirfs-Brock Associates