My blog has been moved to

Thursday, August 16, 2007

Legacy vs Lateral (2): Design for the future, not for today

Did you ever try to assemble and create a great product but lately much more better, powerful and yet cheaper components are suddenly available, and were they available sooner, your life would have been significantly simplified? Setting aside first that nobody can really predict the future, it is important here to emphasize that often - but not always [1] - it makes more sense to design something for tomorrow or next year, rather than just for today.

The classic example for this is game development. Unless you're coding a simple Pong clone, the whole process of game development (think the upcoming id's Rage or Crytek's Crysis - but certainly not Duke Nukem Forever) can take ages. By the time the game is finished, the whole digital world already makes a few leaps here and there. Thus, it is absolutely necessary to predict the trend and ride the curves so that the shipped game will match the available technology and cover the intended market as it may completely change many design decisions during the development phase.

For the sake of giving an example (I'm not saying this is what's going to really happen), say you're 1000% absolutely sure that Physics Processing Unit card ala Ageia would be ubiquitous in platforms you're targeting, just like today's accelerated graphics chip, then it will be less sensible [2] to use physics engine which won't take advantage of the said unit, let alone optimize it to death, because right after you launch the game, it might have hard-time competing with other games which are e.g. specifically designed to exploit the physics processor.

The same goes for any non-trivial things that needs engineering love. We're not in the 70's anymore, a satisfactory achievement needs more than just a weekend, a copy of Popular Electronics, a bunch of vacuum tubes, plus a TV [3].

But the real challenge remains: how can you convince your superior that it's the right thing to do?

[1] For example, if your software is supposed to work well even on old systems
[2] There are of course obvious exceptions to this, e.g. you don't need fancy graphics nor physics
[3] Like a project to show the actual time at the corner of the TV screen

Postscript: To avoid misunderstanding, it does not mean that things like software bloatness is endorsed. Quite contrary, because bloatness is typically caused by careless uses of system resources and superfluous features while design for today implies imposing restrictions (which will not exist anymore in the future) unnecessarily. Between these two extremes we must stand.

No comments: