After proving that good project management and software engineering could result in on-time, in-budget, high quality results for contract software development, I was designated as the project manager of a large fixed-price development project. Despite my objections, a second project manager was also assigned to this project. The relationship was explained as “like the director (me) and producer (the other fellow) of a movie.” This 18 month project came in on time, under budget, and had only 1 bug in its first production release. On reflection, this producer/director arrangement did contribute to its success.
Since then, I’ve wondered about what the software development community could learn from the making of movies.
To start with, how does software development resemble making movies? A unique creative and/or commercial vision is defined and funded. A team of diverse specialists is assembled, often with prima donnas that need to be coddled to extract peak performance. “Chemistry” among the principals is central to success. The management of practical (producer/project manager) and creative (director/architect) aspects are often separate and conflictual. Besides the stars, hundreds of technicians and specialists must collaborate to achieve a common vision. The extent to which this central vision survives or is enhanced as the collaborative process unfolds is critical to coherence. Then, once in the can, identical, localized copies of the work product are presented to a mass market for its judgement.
There are significant differences. Movie sequels almost never improve on the 1.0 version. For the viewer, movies are necessarily a time-sequential single-path narrative; software has a huge extent of unique possibilities. A good editor can cut out weird and bad paths; a good tester is lucky to find them. As viewers, we only rely on a movie for a few hours of entertainment; as users, we may be risking our health and wealth.
These added dimensions provide the engineering imperative for software. Many people have argued that software development could beneficially learn from manufacturing, or at least from certain techniques (resuable off-the-shelf components and six sigma QA for example.) However, the dynamics that focus hundreds of technical specialists to produce a movie probably has more to tell us about making software than a study of repetitive manufacturing processes.
The relative importance of a unique development effort versus creating copies of the resulting artifact is the key difference. In all software projects I know of, the development effort is unique and dominates the quality and effectiveness of the artifact. The copying (manufacturing) work is straightforward and simple. There are a very wide range of manufacturing processes (automobiles versus oil refining, etc.), but generally the repetitive work is where value is created and quality is determined. Engineering development work (design of the vehicle and/or the plant) is necessary, but does not dominate results to the extent it does in software.