Tuesday, 8 December 2009

Perfect Code

If you write a basic code class, such as a stack, a list, a queue, you can get the code to be clean and readable and fast. You can optimise it and make it very small and fast and readable too.

You can perfect the code. You have the capacity to actually make something that cannot be improved. This is because there is a finite number of ways to do it and the finite number is not too large for human time scales.

Now, in your mind, imagine doing that for a full size development project. Can you see the towering complexity of doing it perfect in your mind yet? Okay, well, that's what's called clean room development. It takes moderately more time than normal development, about 100-200% more, but returns almost perfect complex systems. Almost perfect, because at some point a human will have made a mistake or an assumption. There is no escaping errors when the possible set of solutions is so large that to even count it would take a multitude of universe lifetimes.

So, should we adopt the clean room development model? Can we adopt it? I don't think we can, or even should, because one of the main features of a clean room project is that the full project definition is known about from day 1. That's something we never have.

Now, consider bridge building. Would you submit to clean room development on a bridge, where lives are at stake in case of the collapse of the bridge? Would you spend a little more time making sure that everything was perfect and there were gross over tolerances in all the materials used? Yes should be your answer. And do you think that real world mechanical structural engineers use clean room development model?

They don't. They get a half finished proposal written on a napkin, told a random budget and time frame and get started. Just like us. The only benefit they have is that their product can't get exponentially more complex after the initial design.

If the only difference between physical engineering and software engineering is the linear vs exponential complexity. That alone is enough to explain why clean room development is so successful in programming. It stems the complexity bleed we get in computer software. It stops the applications or games from getting out of hand. It makes the job more linear.

So, now I ask again, should we use the clean room development model?

I think we need something like it, if not it. We need something to stop the constant complexity increase. What can that be? Can we reign in our apps and games to be made of "materials" that don't grow in complexity? Can we do this with well engineered architecture model that allows modules to be used without adding any more than a linear increase in complexity?

Behaviour oriented development might be a solution to this for games where much of the complexity of the game comes from relatively independent subsystems connecting where it's only just about necessary. Behaviour oriented development also allows for simpler upgrade path if the game is developed iteratively with napkin design changes.

1 comment:

Unknown said...

Thing is, though, it's a rare project where the complexity comes as a direct result of the design itself. Complexity in games seems to come mostly from two sources:

1) Edge technology (and its many, many unwritten rules)
2) PEBKAC, with the chair in question being management.

Poor management decisions created 90% of the complexity at BS, and I find it extremely difficult to believe (from accounts from elsewhere) that the same doesn't apply to other shops. Trying to legislate in code to cope with the PEBKAC factor only added further complexity, which in turn necessitated more management intervention and so on.

We COULD clean-room a game dev cycle, but it wouldn't protect us from the thing I just mentioned. The only way to do that is the lone ranger model - one designer/artist/coder doing everything themselves. That's why Flash games tend to be so bug-free; they're effectively clean-roomed by default.

So what's the solution? I'm not entirely sure. But whatever it is, it's going to meet resistance, because convincing the people who run development houses that THEY are the problem with games development is a losing game.