A couple of days ago I wrote about how important it is for designers to know their materials. The material for interaction designers is code, so a baseline understanding of what code can and can’t do is essential for designers to be effective.

I learned this principle in one of my favorite books: The Art of Computer Game Design, by Chris Crawford (Osborne/McGraw Hill, 1984). Crawford was one of the early Atari game designers/implementors. (I use the slash because the distinction wasn’t as clearly drawn then as it is now.) His book lists seven design precepts for computer games. The seventh of these is titled “Maintain Unity of Design Effort,” and includes the following passage:

Games must be designed, but computers are programmed. Both skills are rare and difficult to acquire, and their combination in one person is rarer still. For this reason, many people have attempted to form design teams consisting of a nontechnical game designer and a nonartistic programmer. This system would work if either programming or game design were a straightforward process requiring few judicious trade-offs. The fact is that both programming and game design are desperately difficult activities demanding many painful choices. Teaming the two experts is rather like handcuffing a pole-vaulter to a high jumper; the resultant disaster is the inevitable result of their conflicting styles.

More specifically, the designer/programmer team is bound to fail because the design will make unrealistic demands on the programmer while failing to recognize golden opportunities arising during programming.

Crawford illustrates this by using a couple of examples from his career. One that’s stuck with me comes from the development of the game EASTERN FRONT 1941, a war game for the early Atari 8-bit computers. While he was programming the game (which he’d also designed), Crawford spotted an opportunity: a simple addition to its calendar routines would allow color register values to change as game time progressed. This allowed the color of trees to change to reflect the seasons. A minor detail for sure, but one that added depth to the experience. (Keep in mind that programming for these early computers meant always optimizing for limited memory. This minor change came at the expense of only 24 bytes of computer memory; a “cost-effective improvement” in Crawford’s words.)

Software development is much less painful today than it was in the late 1970s and early 1980s. Still, limited budgets and timeframes call for trade-offs. Knowing where the opportunities and constraints are helps when you’re called to decide what to include and exclude in the work.