Yesterday I ended my post with a quotation from Wikipedia on development hell, and that’s where I want to start today. There are many reasons why film (and software) projects go wrong, and they all have to do with the script.
The script is central.
When producers and directors are looking to attract talent into a project, they use the script. When producers and directors are trying to get funding for a project, they use the script.
The script is central.
It represents an embodiment of the idea that sparked it all off, the problem that needs to be solved, the market with a barn-door sized gap, the customer itch that needs to be scratched, the business plan that’s looking for funding.
And unlike the past, unlike the waterfall and cascade days that led to their development hells with inflexible scripts, the script now evolves. We iterate through scripts. We cut the script down into bite-size chunks so that everyone understands what is needed, what is happening, what each individual’s role is. This iteration process helps us visualise what is happening, what needs to happen.
It is only when the script is stable that funding can be obtained. It is only when the script is stable that the project is initiated. It is only when the script is stable that we can speak about going “into production”.
Development is about scripts. Production is about making those scripts leap off the pages and becoming alive. Post-production is about making the experience available to all.
What are sets? Nothing more than reusable infrastructures with temporary skins. The key thing is that set designers really worked on making the sets reusable.
What about stock shots? Nothing more than reusable commoditised components that add limited value, yet remain necessary. So it’s important to spend as little time and money on them as possible.
The concept of calling a “wrap” is nothing more than really understanding modular design. You’ve compartmentalised something so that it’s got high cohesion and loose coupling, you’ve iterated through that piece until everyone is cool with it, then you’ve said “Enough”. Not Perfect. But Enough. You have time in post-production to fiddle with it, this is not the time. Move on.
More in the 3rd but not final part, which I hope to write sometime later today or tomorrow. It will summarise what I consider the lessons that parallel the two sectors, in tabular form. So why will it not be final?
Because Stephen Smoliar kindly pointed out that Tom Davenport wrote some parallel thoughts down in Information Ecology in 1997, particularly in a chapter headed “As shown on TV: A new model for information staff”. I promise to find a copy, read the chapter and try and tie it all together in a fourth and final post. Can’t say when, it depends on how long it takes for me to receive the book. I could cheat and use Search Inside, but I’m not like that. I’d rather fight to change the law.
And because I want to read the book now that I’ve peeked inside :-)
I think this metaphor is apt, but my take is a little different – it is that both the Hollywood process and the traditional corporate software development process suffer from centralised choke points:
http://epeus.blogspot.com/2006/11/hollywood-software-and-net.html
There is no doubt that the script is central, which is why it deserves more rigorous epistemological and ontological consideration than those emerging from JP’s efforts to develop his analogy. Most important is that, to invoke language that I have used in this forum before, we need to honor the fact that a script is fundamentally a DRAMATISTIC (rather than SCIENTISTIC) artifact (which entails the corollary that software development is also more dramatistic than scientistic, that being what JP REALLY means in his proposition that software is about stories). (Needless to say, neither the filmmakers who follow the Wikipedia model nor most parties involved in software projects, including the customers, are particular interested in either epistemology or ontology; but WE need them to keep our own thoughts in order!) In my own research I have decided that Kenneth Burke’s pentad provides a useful grounding for both epistemology and ontology; and I have tried to offer an overview of this approach (along with related approaches) at:
http://blog.360.yahoo.com/blog-Mff23hgidqmHGqbcv.lfskakEtS6qLVHUEMFUG4-?cq=1&p=34
Lest anyone think this is just a philosophical exercise in abstraction, I have now performed an initial exercise at putting it into practice. The exercise is based on what is probably now a “classic” case study in the first chapter of the DECISION SUPPORT SYSTEMS text by Keen and Scott Morton. The study concerns a manufacturer of laundry equipment dealing with forecasting sales and then projecting requirements for manufacturing. This case study concerns the “real world” (albeit a bit dated) of decision-making, rather than the world of support software; so, in spite of the fact that it reflects an earlier business era, I find it a good way to focus on those stakeholders who are NOT fixated on things like software artifacts.
The problem can be cast in the ontological categories of Burke’s framework as follows:
* Acts (what takes place)
o Manufacturing “sells” consumer products to Marketing
o Marketing prepares sales projection
o Manufacturing prepares requirements for manufacturing and inventory
o Marketing-planning manager resolves conflicts between sales
forecast and production forecast
* Scenes (situation in which it occurs)
o Negotiating parameters for sales forecast model: Marketing
manager Marketing-planning manager
o Negotiating parameters for production model: Marketing-planning manager Production manager
* Agents (who)
o Profit centers
. Marketing
. Manufacturing
o Planners
. Marketing-planning manager
. Marketing (sales) manager
. Production manager
* Agencies (means or instruments)
o Sales forecast based on computer model
o Forecast of manufacturing and inventory requirements based on computer model
* Purpose (why)
o Project sales for next twelve months
o Manage production consistent with sales projection
. Work force levels
. Production schedules
. Inventory management
o Define pricing and merchandising strategies
In this framework the key problem comes down to whether or not the agencies are doing a good enough job to facilitate the resolution of conflicts between the sales forecast and the production forecast. To invoke language that JP holds so dear, this involves facilitating CONVERSATIONS THAT WORK, where much of the “work” has to do with aligning the agencies to the motives of the agents (in this case both individual and institutional), in order that the negotiation “scenes” are furnished with the necessary information. The punch line is that the dramatistic stance allows us to examine the nature of negotiation through the subjective lens of motivated action, rather than trying to see the world in terms of the objective numbers (whether or not they are visualized in “dashboards”) compiled by the bean counters who drive the enterprise software.
Final disclaimer: This exercise is far from cast in concrete. I just decided it was time to start trumpeting the virtues of Kenneth Burke and anchor his stuff down to a concrete example. All sincere efforts to refine the details of the exercise will be most welcome!
I agree. I am developing a software application for the film industry called Mewa Film and I found interesting that filmmaking and software development have so many things in common.