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:

stages.png

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

fbloop.png

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:

manyloops.png

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?

9 Comments

Dorian Taylor
I think rather than hopping back and forth between metaphors, we might want to just say that the process of acquiring software is idiosyncratic. Explicitly call out its resemblances to other processes, of course, but still maintain the idiosyncrasy. Software, much like a movie, lacks the glaring negative feedback of the wreckage of a failed edifice. I mean, it may win a Razzie but typically nobody dies. But, much like an edifice and unlike film, software persists — it can encroach and impinge on the people and business in its environment for a very long time. By contrast, an unremarkable movie gets quietly tucked away. I still think, however, that any verb that evokes a construction metaphor should stay far away from software. Use define rather than build. And yes, it pays a great deal to acknowledge the feedback loops at different time scales, much like shearing layers (an architectural concept). How about this mouthful: cybernetic, self-similar software acquisition processes?
Yolanda Logan
Although I agree with Dorian on the one hand, on the other hand, I think the "construction" metaphor works. But I see his point. In this string, construct could perhaps be misconstrued: define/conceptualize/design/construct Let's consider the reason we use metaphors: to help explain something that is foreign. I like to use the architect analogy - the architect creates the plans to designs your home, but does not actually build your home. When I explain our field in this manner, it hits 'em right over the head. "I get it!" Works every time.
Dorian Taylor
The reason why I make the distinction between build and define is because I believe software to be made exclusively of language, and that language is acquired through iterations of increasing specificity. In the world of atoms, the emphasis and effort is usually centred around moving them from place to place, which we all understand as labour. In the world of bits, however, the effort is centred around getting them to say the right thing, and any relocation of atoms going on in the process is purely incidental and usually uniform. When you emphasize labour in a process that necessitates precision, you get a lot of close-enough behaviour on the part of the people involved. In the world of atoms, close enough often is, but in the world of bits, close enough often is not. When a programmer builds software, his or her goal becomes the accumulation of code, rather than uttering just that which would define the right behaviour (and only the right behaviour). I firmly assert that the conflation of these two concepts has a significant (and deleterious) influence on the way software is currently made. The preface of Danny Hillis's book Pattern on the Stone puts it most eloquently. As for iterations of increasing specificity: the language used to speak to computers is of unparalleled precision, and it is very easy to accidentally utter the wrong incantation. It is therefore the role of the interaction designer to provide constraints and hedge what can be uttered. Engineers and programmers themselves must further hedge their language as well (see Program Development by Stepwise Refinement, Niklaus Wirth). Finally, I believe Mr. Cooper says himself that although metaphors are convenient, they lack in where they do not fit what they are trying to describe. Idioms, despite needing to be explicitly learned, are much more robust. I think that applies to much more than just software user interfaces.
Y.
I work in the IT industry but in my spare time I make short films and write scripts. I use professional crew on my short films and have made a few minor script sales along the way. None of it's very exciting though - you certainly won't have heard of me. However I can point out one major flaw in the theory - the software industry would have to make some major adjustments in working style to wind up being as efficient as a film production. For example, cast and crew know that there is one boss on set. The director. Yes, film making is collaborative but ultimately the director carries the can. The director says 'yes' or 'no'. And everyone generally accepts it. Unless the shoot is a complete basket case, no one attempts to re-litigate the decision. Yes, sometimes cast have issues, but that's normal stuff everyone deals with. Also the great directors generally tend to be good communicators, good with people and good technically. And they're on the set for the entire length of time and they approve *everything*. In IT this would translate into people writing code and then taking all of their code, and UI design and testing specs to some person who could not only read it all, but understand it, approve it, tell them (in a level, calm manner) how to fix it and if need be, do all of the work themselves. Yes, sometimes sets and locations are disaster areas (that's down to the director and producer as well). BUT in the end, (especially on a low-budget indie) the money runs out, and the production shut downs on the date specified. No do-overs, extensions or more funding. So you'd better get the shots you need because if you don't... No film. This is a big driver for completion of the actual shoot. If a producer says the film has 30 days to shoot then they have 30 days. That's it. You don't get more time. It's even more brutal in TV where they're turning around an episode every 8 days or so. There are no do-overs in film and TV. Also the normal working days are long (12 - 14 hours) - that's how they get through the work in the time frames they have. Shoots alternate between mayhem and mind-numbing boredom. Which is why productions spend a very long time in script development and pre-production. Better to shut down something that doesn't work early on, rather than commit to filming. Anyway, a bit of a ramble type post. But yeah - the working style is completely different.
uxdesign.com
The key words are "feedback loops."

Agreeing that the metaphor is useful, to a point, but not after because of the more linear process of film development mis-matching the "multi-cyclical" processes of web/software development.

Also, where technology merely conveys the ideas of film, it is completely and persistently enmeshed with them in software. Not to mention user/"audience" participation... the most important feedback loop of all.

Perhaps theater metaphor is more fitting, having potential for improvisation, non-linear creation and "use," and for the front and back stage operations?
Dorian Taylor
Y.: Frederick Brooks tackles exactly your point all over in the Mythical Man Month, especially in the essays The Surgical Team and Aristocracy, Democracy and System Design. That was in the 70s. What's amazing is that we've known how to change for quite some time but for some reason haven't had the language to describe it succinctly enough to business. I agree with your assertion completely that the software industry would have to make some major adjustments — but as I understood it, that's why we're here.
Robert Stackhouse
Several differences between movie production and software development that weren't previously mentioned are the cost of production, the number of players involved, and the size of the audience. I think the huge difference in cost of production has lead to the streamlining of production in movies that was mentioned in a previous comment. Software development does not cost enough to force us into this kind of streamlined state of practice (not that some people haven't tried to get there on their own with things like Lean Software Development). Of course, with this streamlining, the over all quality of movies suffers some. Some people in Hollywood have forgotten that it is their job to entertain, not to make money. I've witnessed the same attitude in software development though. This attitude is most evident in waterfall style shops that like to say, "I built it just the way you asked for it. It's your fault no one wants to use it. Not ours." The software products that offer the lousiest experience are made by companies that have forgotten that they should be building products to help people rather than just to make money. Any venture that's sole objective is to make money is doomed to fail, because it has lost site of its customers. Just look at our troubled financial sector. Generally speaking, more people are dependant on the success of a movie than in a typical software project. Thus, more is done to promote a movie and to ram it down the gullet of it's audience than with a software project. Society as a whole is much more tolerant of a bad movie than a bad piece of software. Movies are for distracting people. Software has a job to do. So, a movie does its job, to provide a distraction, even if it is really awful. The cost per unit is also typically much lower in movies than in software, so people are more tolerant of bad movies than bad programs. When was the last time you paid $9.95 to buy a Microsoft Office program? Software also has many more genres than do movies, making it harder for programs tooled for specific purposes to be consumed by the masses. All these factors work to give any movie a much bigger audience than most software (anything Microsoft being the notable exception here). This comparison works well for software that is put into a cellophane wrapped box and fired out of a cannon at the waiting masses, but this comparison breaks down when software as a service enters the discussion. No one edits movies on a weekly basis over the history of you consuming them. I think stage drama serves as a much better comparison here. The players refine their craft between performances, and some people routinely take in the same show. I also think that movies get away with more because they are "built" for a single use really rather than repeat consumption the way software is. Craft and collaboration are the answer to creating better software, not process refinement. Although process will play an important role as long as cost is a factor in software development.
Daniel Jaeger
Some examples of where I see this loop in my work as a designer are: The concept of personas as a tool were designed to help designers and other people involved in the creation of interactive products. Alan cooper et. al. saw the need to represent users in a way that would be useful to said audiences. (Design and Planing). He came up with the concept of personas and refined it over time (production & refinement). Exposing them to the larger design community lead to evaluation and acceptance of the concept. Individual personas are specific to a product and are created for the individuals involved in the process of creating a specific interactive product. as an individual designer, I create individual personas with their specific attributes. If I do them well, they are generally accepted by other members of the organization. I see the same process in the creation of wireframes (maybe the design ond planning would be establishing standards for how wireframes look, production is the actual creation of wireframes, iteration through different versions after feedback from product owners and developers (evaluation) and finally acceptance. The creation of style guides and behavioral specifications. Planning and designing - who is it for? What does it need to do? - Developers, communicate form and behavior of the artifact. Production snd refinement - creating the specification and iterating through detailed trad-offs with developers. Acceptance & evaluation - well done specifications are mch appreciated by developers but I always collect feedback to see if I an improve the way I create these artifacts. In general, I think it works for every artifact that is created along the design process to communicate design on a concept level (standards for documentation) as well as individual artifact (specific to a product).
Nathaniel Flick
Software is a choose your own adventure book, not a movie. A movie has only one story arc, a beginning, middle, and end. Software is more dynamic than that, allowing for different choices and different outcomes within a framework. Limiting that framework to its most useful parts, connecting a user to her data most efficiently, is the goal of User Centered Design.

Post a comment

We’re trying to advance the conversation, and we trust that you will, too. We’d rather not moderate, but we will remove any comments that are blatantly inflammatory or inappropriate. Let it fly, but keep it clean. Thanks.

Post this comment