Wednesday, March 08, 2006

Swamping the System

I've been quiet recently because I'm programming a game. A lot.

However, before I start with today's programming (I've already done some art and algorithm design), I want to talk about swamping the system.

The world is full of systems. The IRS is a system. NASA is a system. College education is a system. The game I'm making is a system of systems.

These systems are built in a certain environment. They are built with a particular amount of resources in mind, a particular number of users, and a particular application.

Then the universe changes around them. In an attempt to adapt, they put patches on their system. They try to translate the new world back into something the old world's rules can handle. Sometimes this works okay: the IRS does okay for itself. Sometimes, it works poorly: NASA totally failed to adapt. Either way, the system gets steadily more and more bloated. In addition to actually being less directly applicable to the new environment, they would also actually be less efficient in their old environment.

The core assumptions you make when you design a system - any system - limit the ways in which the system can meaningfully expand. Robust core assumptions increase the time and money it takes to create the system around them, and even the most robust assumptions can't keep a system young and efficient for long. They just let you get old and creaky while still being useful.

There are only two ways to keep a system - any system, from a corporation to a cancer treatment - efficient.

One is to totally replace the system every chance you get. Create it from scratch. This is what we do with games: the game gets old, we make a new game.

The other is to have the vast majority of the system's internal workings be people instead of paper. Leaving a large amount of the system's operation up to individual discretion has definite flaws, but also has definite advantages. It blows the successes - and failures - way up in proportion. It allows an excellent cog to drive the whole engine at mach 3, but a bad cog will immediately crash it into a tree.

These are really the only two options. The patch-and-patch-and-patch method that we try to use ends in tears. Who is pleased with government spending? Not 1% of the population. Who is pleased with NASA? Nobody who knows much about them. Who is pleased with our social norms? Nobody I know.

The universe is continually changing. New environments constantly swamp the old systems. Trying to "adapt" is a flawed premise. Your system needs to be either re-invented or serve only to enhance your own choices, like a nice car. Even cars have to be replaced and reinvented, however.

So, don't try to "adapt" your system. Don't "adapt" your game ideas, don't "adapt" your social self, don't "adapt" your company. Reinvent. Reinvent lighter, trimmer, more agile. Burn all the paper, start from scratch. Drop the bad cogs, empower the good cogs.

It works for Google. It works for Dreamworks.

Theoretically, it should work for you.


Duncan said...

This sound like it directly relates back to the Law of Leaky Abstractions.

All systems, computer or otherwise, are attempts to abstract people or processes from each other. This has the practical up-shot of making interactions between groups easier. It also creates problems when the systems (or abstractions) get mis-aligned an can no longer easily interact. Thus we patch the abtraction, creating bloat and ill-fitting abstractions. Or we can create a better abstraction.

Craig Perko said...

Pretty much!

Eric Poulton said...

Funny, not even fifteen minutes before reading this post I finished listening to a lecture from the Long Now Foundation on the exact same topic.
Down near the bottom (Nov. 2005) is a seminar called Making Digital Durable, by Clay Shirky. It looks at what you're talking about here, and how it relates to preserving information and its context for the future.

I don't know if you're familiar with the Long Now Foundation or not, but they've got some really fascinating seminars for download.

Eric Poulton

Craig Perko said...

Hm. Thanks, I'll look into it when I have the time.