|
|
When you're making software, you test your code before you check it in. If
you don't, may the Archangel Gabriel laugh in your face. I gather his database
is more reliable than whateverthehell project you're currently thwarting. As
though I'd known it all along but had never given it any grey-matter CPU time,
it dawned upon me how often bugs make it into software because the underlying
systems change - not the feature itself.
For instance, you check in changes to a game level design, dropping the ceiling
by a dozen centimeters. You test it, it works. Sometime down the road, changes
to the camera are checked in, but they are not checked against the whole system,
only enough of it to be economical. There's enough testing to minimize possible
damage, in other words. If the new camera can't handle the new, lower ceiling
and ends up outside the room, well, that's software.
Software bugs are little islands of entropy in very large systems which live
in attempted violation of the second law of thermodynamics. Entropy is the
reward for entropy in a software system. The more you change - especially at
the lower levels, the more you will find yourself doing fixes... which brings
on more entropy.
Okay, so how to solve the problem? Obviously, minimize change.
It seems like an absurd argument. To get from an empty project to a complete
one, you have to implement features - you have to make changes. This is very
true, but you don't go out and rewrite everything from scratch, do you? I've
probably used printf more often than any other function, but I've NEVER
implemented it.
Get as much of your software out-of-the-box as you possibly can. If I hear one
more developer say that they can build X cheaper than buying it, I'm going to
have to hurt them. You are only going to use X once in your software - they
get to sell it many times. They get to amortize the cost across many customers,
which means that you get it cheaper than it would be to develop it.
But you don't need all those features? How much of it do you need? Ten
percent? Fine, can you really build ten percent of that product and get it
tested to the level that they did for the cost of buying it? You think so?
Are you keeping in mind that it takes more than 10% of the effort to develop
10% of the features?
Then how about this: Can you deliver it on day one of your project, in a state
that will not change time and again through the life of your development? No,
you can't. You will develop something that falls short of your design, in
more time, with more bugs, and those parts of your system - you know, the ones
that MAKE YOU MONEY - will suffer as a result of that entropy and your lack of
attention.
If you are in the games industry - get a third party engine. If you're in
data services, get a database system. Rolling a website? You're going to be
heavily reliant upon apache, perl, ruby, sql, etc. You wouldn't think of
writing your own C++ compiler for a single project, so why on earth would you
write your own physics, rendering, particle systems, animation, shaders, AI,
design tools, audio system, memory manager?
Yeah, you might want to do some of these things. But choose what your project
is supposed to be FIRST, then start making it. Only tinker with the foundation
when you find something totally unacceptable. Game design is the talent of
getting the most out of the resources you have available. Work within your
restrictions and play to your strengths and you're going to make the best game
you have the potential to produce. Waste your time writing an animation
system that makes you look the same as everybody else and you WILL fail
eventually.
-rbarry
|