We’ve discussed the benefits of Agile development before and that the iterative approach to building the architecture — where you explore architectural issues (very few apps are completely new and unknown) a little bit through each iteration — is an effective method for arriving at a good application architecture. What is less obvious is the psychological benefit to working in this way.
It’s frankly been a while since I’ve participated in a large waterfall project directly (one benefit of working for a firm that does agile software product development), but I regularly talk with folks who are still in the corporate trenches doing things the old fashioned way. One thing that hasn’t changed is the BIG ARCHITECTURE wrestling match up front. Management wants to know the architecture, the guys with “architect” in their job titles want to know the architecture (so they can criticize, natch), the project manager(s) want to know the architecture. How will we scale? How will we ensure security? More useless brainpower is spent on this ultimately fruitless task — solving problems that end up being no problem at all — than almost any other activity in the project.
What mostly isn’t recognized by participants and observers is the psychological burden this puts on the development teach. Making big decisions early, often in the absence of critical information, produces a lot of anxiety. This often leads to poor decision making and procrastination (where necessary decisions are pushed back to a later date).
Agile, in contrast, provides a natural divide and conquer approach to breaking big tasks into smaller tasks and allows the development team to make decisions at the right time with the right information. I’m halfway convinced that all of those “enterprise architects” at big firms are really just stress counselors for tech leads suffering from waterfall anxiety.
