The best practices for design and creation of software - Agile - and Architecture - Design/Build - have so much in common, one wonders if the design wheel is simply being reinvented in different domains. The previous approaches to software design and architecture (still very much the dominant approaches unfortunately) have been to create a comprehensive (read: large) design based on requirements gathering, and then throw the design over the proverbial wall to the engineers for development or construction of the final product. This legacy approach - called Waterfall in software and Design-Bid-Build or Design-Tender in architecture - creates the same problems in each domain:
- Miscommunication between designers and engineers is inevitable when 20-lb design documents are triumphantly delivered to engineers.
- Lack of accountability for designers/architects is the result of this miscommunication. Ever heard the following? "I'm sorry Mr Client, you signed off on the design/blueprint. If you had more requirements you should have provided them during requirements gathering."
- All these problems stem from a more fundamental problem - treating the design or blueprint as real progress. One of the 12 principles of the Agile Manifesto, in contrast, is "Working software is the primary measure of progress. " I can hear the voice of Shigeo Shingo, a guru of lean manufacturing, who observed that it's only the last turn of a bolt that tightens the nut - the rest is just movement.
Increasing the accountability of designers by tearing down the walls between designers and the final product thus unifies both these approaches. There are differences, though, in how these walls are torn down in architecture and software design. Perhaps architects can learn from software designers and software designers can learn from architects. In fact, with the rise of smart houses (is it a building or is it software?), perhaps architects and software designers will have to learn the following lessons from each other.
What Design/Build Architects can learn from Agile Software Designers
- We engage best with actually existing products that we are using, not with designs of products on paper. That's why agile designers release early and release often. Creating a complete design can't be done in one's head or on paper, no matter how much requirements analysis is done. This isn't the fault of clients, it's the way we are hardwired. This is obviously more cost-prohibitive with architecture. But think of the example from interior design - find one good piece (chair, painting, etc) that you love, live with it for awhile, and then add pieces around it. Could a more modular approach to architecture enable this kind of iterative approach to architecture?
What Agile Software Designers can learn from Design/Build Architects
- Design can't be divorced from Engineering, but requires a Master Builder. The Code of Hammurabi fixed absolute accountability upon master builders for both design and construction, and most of the great cathedrals and Greco-Roman public buildings were designed by master builders. Only in recent times did architects throw blueprints over a wall to a general contractor. Architects using the Design/Build approach are engaged in construction - they are master builders. Software designers, in contrast, emphasize their role in the process as distinct from development, and a proliferation of such roles have now emerged: information architecture, wireframing, usability analysis, etc. Software designers generally know far less about the inner workings and possibilities of their raw materials (code) than do design/build architects. Master builders in software design are thus few and far between - Jesse James Garrett is a good example of a master builder software designer. Perhaps the emphasis of software design as a distinct set of stages was needed at a time when everyone thought they could do software design, but as that time passes perhaps software designers need to understand their raw material better, like good architects do.
Comments