Moviemaker
Volume Number: 10
Issue Number: 10
Column Tag: Inside info
Think Like a Moviemaker 
You may have a roster that really does look like movie credits
By Chris Espinosa, Apple Computer, MacTech Magazine Regular
Contributor
If your development shop is more than just yourself, you probably have some
separation of function among the people working on a project. Usually there’s a
separation between development and testing; if you’re big enough, documentation is a
third branch. Some organizations last a long time without really breaking the
organization up into more parts than this.
But as your development team gets bigger, you may need to break the developers
into teams. Often one team is set to work on the core technology and another on the
interface, or one team does user interface work and another does system-level stuff. If
your project gets very large, you may have more than two teams working on different
modules of the project.
And everybody knows that as you increase the number of teams, the development
time increases geometrically, because of the added burden of communicating among the
teams. This stage of growth can be fatal for small companies. Things stop working like
they used to. The kind of easy collaboration that happened over cubicle walls doesn’t
happen from hall to hall, or building to building.
And unless carefully managed, the teams can go in different directions, duplicate
each others’ work, or leave holes in the product big enough for competitors to drive
through.
And nobody’s making it simpler for you. With each year the requirements on you
go up: you need experts in cross-platform development, better user interface
designers, and multimedia mavens to keep up with new technologies and user demands.
At some point the credits in the About... box start looking like the credits at the end of a
movie.
Take a cue from that. Movies are pretty complex creative processes, taking
dozens of people months or years to create. And while the analogy breaks down pretty
easily (a bug in a movie doesn’t generate tech support calls, for example), there’s a
lot to be learned from the way a studio organizes a movie production.
And I’m not talking about big-budget epics here. Thousands of made-for-TV
movies, direct-to-rental releases, and minor studio pictures are made each year, and
there’s a lot of consistency in the way they’re put together from studio to studio.
First of all, somebody’s in charge: there’s a producer responsible for bringing it
to market and managing the investment, and a director responsible for the creativity
and quality of the picture, and managing the people. The director may work on only one
picture at a time. How different this is from a software company of moderate size! In
such companies, people probably report up through functional organizations that work
across products, and there’s no equivalent of a “producer” until you get to a division
VP, who doesn’t have enough personal involvement to make authoritative decisions. To
correct this, you may have a project leader to function as a “director,” but without
the management authority to tell people what to do.
Next (and most distressing for people who want job security in high-tech): most
people who work on a picture are independent contractors. There was a time when
actors, directors, and cinematographers were firmly attached to one studio, but
nowadays they float from studio to studio, picture to picture. Even sequels and serials
are made by different teams of people. This is easy in Hollywood, where tools,
equipment, and raw materials are pretty much the same from job to job. The training
time currently needed to learn and understand a large body of C++ source code puts a
damper on hiring journeymen programmers for a specific job, and the desire to not
have your trade secrets go to the competition is a reason to keep your engineers
around.
But I predict that over time that will change, as less and less coding is required to
develop saleable software, and more and more the job of creating applications becomes
one of fitting new components into an existing structure, or redefining the
relationships among components. This is already happening in other areas of
technology (like VLSI design, where designers rarely work at the gate level, much less
the transistor); that software programmers still write code a line at a time is as crazy
as trying to make movies with a still camera.
So in the organization of an application team, you may have a roster that really
does look like movie credits: a producer and a director; a couple of assistant producers
and directors to manage the relationship with the platform vendor; an overall architect
(like a scriptwriter) and a few lead programmers (the lead actors); a supporting cast
of programmers and testers, brought in for the job; an interface stylist, a sound
editor, a technical crew doing tools and integration; and of course second unit to port
the application to a different platform. After the project, the work gets filed in a good
source repository, the leads may stay with you, but the majority of the team moves on
to other studios and other jobs.
Next month: making the movie
Referenced by (2):