Software is a movie, not a building

In a previous post I suggested that film making is a good analogue for discussing software design and development, that lessons learned there could help us think about better ways to approach our own projects. I established the similarities like this:


Much beer has been spilled over comparisons of software to physical architecture, and while the analogy is interesting it is inherently flawed. For the industrial-age activities of designing and constructing a physical building are vastly different than the post-industrial process of designing and building a digital artifact of conceptual ideas, where cost is measured by time rather than materials and success measured by consumption and desirability. The primary reason the architectural analogy fails is its inherently linear development process. There's not much an ironworker can do to influence the design and performance of a bridge besides following directions and adhering to specifications. Software and film, as expressions of ideas, relationships, and behaviors, rely on a chain of feedback loops to disseminate expertise, opportunities, and motivations across the team and throughout the product life cycle.

This conceptual feedback loop has three steps: 1) design and planning 2) production and refinement 3) evaluation and acceptance


There are macro and micro iterations of this loop between and within each point, so as the process unfolds, the product is explored, communicated, evaluated, and adjusted countless times:


What's important to recognize is that every role on the team has incentives and responsibilities to be involved in each of the stages at various times, across many parts of the process.

How do you see similar feedback loops in your own software development projects, and where do you think there should be some where there aren't?