[ Home | Library | Contents ]

---

[ Prev | Next ]

by Andrew Welch

Better Late than Lamer

Software development is akin to exploration of the New World: you can plan as best you can, but until you get there, you don't know exactly what to expect. Each new software project really is an expedition into the unknown. Certainly, you carry with you a certain amount of experience that makes finding the path a bit easier, however because each piece of software is unique in scope, they each present unique challenges. Not all of all of the challenges can be planned for, or are even known ahead of time.

Thus, even if the product spec is nailed down from day one, software development can be a journey of discovery and ad hoc problem solving. The fact is that good software design includes a feedback loop: you develop the product to a certain point, and try it out to see how well your ideas translate into a real-world product.

Initially, this feedback loop should be done by experienced game/product designers (in addition to the lead programmer/designer). Although the products are ultimately aimed at consumers, you'd no more want your customers to do the initial design phase of your product than you'd want a fan composing/producing a rock song for your band. That kind of customer input is invaluable, but at a later stage in the product's life cycle.

Even in this early phase of product design, you'll find things that you thought would work well in the product that just don't. This is especially true for games, where you are trying to capture that illusive "fun factor." Making a "fun" game is a skill that's diametrically opposed to the skill set you need to be able to do the actual programming, and games more than anything else are constantly tweaked and tuned far into the product's development cycle.

Any revisions you make set the product's release date back, sometimes far more than you might expect. Often you'll get to a stage in the product's design, and realize that in order to make it work properly, you have to entirely scrap months worth of work. For instance, in Snapz Pro 2, the basic technique which it used to record video was scrapped twice before I got it right the third time. The whole base of code was just chucked out the window, and I wouldn't have known how to do it properly had I not taken that course.

To draw a parallel, comparing the software industry to the car industry, imagine how hard it would be to design a car if you had to create almost everything from scratch -- taking only your experience with you -- each time you went to build a car. Sure, there is some code reuse, but honestly it isn't all that much.

However, even if you plan everything perfectly, guessing at release dates really is an exercise in prognostication, because you simply don't know the challenges you will face ahead of time. We do our best to buff our crystal ball, but sometimes it's just plain murky.

Bear with us, we only delay a product because, as the quote Ben Spees related to me goes "A product's only late once, but it can suck forever." We don't want our software to suck.

Andrew Welch
Thaumaturgist
Ambrosia Software, Inc.

[ Prev | Home | Library | Contents | Next ]