Less Is More

I discovered this web site completely dedicated to Agile Software Architecture. In fact, when I search the web I can’t find anyone that thinks that Software Architecture is dead or gone with the Agile Software movement. For once, the world agrees with me.

The web site outlines what we would like to achieve with Agile Software Architecture:

1. Deliver working solutions
2. Maximize stakeholder value
3. Find solutions which meet the goals of all stakeholders
4. Enable the next effort
5. Manage change and complexity

In my experience the first objective is the most important. I have always wanted to deliver a working solution as soon as possible to test out the ideas of the architecture. In fact, I often work on the implementation before the architecture is completely documented or modeled.

The web site also lays out a set of principles that align with the Agile Manifesto but are specific to architecture:

1. Value People
2. Communicate!
3. Less is More
4. Embrace Change: Plan It, Manage It!
5. Choose the Right Solution for the Enterprise
6. Deliver Quality
7. Model and Document in an Agile Fashion

My favorite of these is #3, Less is More. In my work, I consider the expense of everything. I once had a colleague who was a master requirements writer. She wrote hundreds of requirements for each feature where I would write about a dozen or two for similarly sized features. From my experience, each requirement had a high cost. A test was created for each requirement on each of our product platforms. If that requirement failed, error reports would be generated. If the requirement was truly necessary, then these things (tests, error reports) were indeed necessary. But what I found was when there were too many requirements, very few people would read them and thus their usefulness went downhill.

With documentation and requirements, I like to use advice that Robert C. Martin gave at a seminar I attended: “Rip content out until it hurts!”. After all, you can always put it back in.