ADVERTISEMENT

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