By Jeff "nonick" Solomon
That weíve become so accustomed to buggy software is testimony to the fact that the computer industry in general is still at a very underdeveloped and frontier-like phase of existence. More established industries, like consumer electronics and automobiles, operate in dramatically different ways in regard to product failures.
For one, there are far fewer instances of "buggy" radios, toasters, pens, or even cars. This is not to say that products in other industries donít malfunction or always ship in perfect condition. There are problems with nearly every complex product on the market. However, these industries typically take a more extensive and comprehensive approach to quality assurance, and operate on timetables that allow them to take more time to market for their products.
In the computer industry, where release dates are often set ambitiously and continuous upgrades are the rule, thereís often less time to exhaustively test a given title. Itís not that quality assurance is not taken seriously, but rather, the basic nature of software is fluid. While a team of engineers working on a new razor blade can sit back and relax for a while once the product has been completed and sent to market, a software release is little more than the process of officializing and distributing a given version of source code. Once this happens, work often continues on the product; new features are added, problems are fixed, and so forth. There is, in other words, no single "final product."
Plus, in this age of growing Net connectivity and user-savvy, companies often assume that, if need be, they can distribute patches for buggy software. For most other product types, this option doesnít exist. A malfunctioning product can either be repaired by a technician or recalled. Toaster heater element 1.01, which fixes the spontaneous neutering problem with 1.0, will never be a reality.
So, what exactly is a software bug? It could be the result of a programmerís typo; a glitch that occurs when software is forced to run on hardware that isnít fully (or properly) supported; a problem that arises from poor software design in general; or a zinger that pops up because designers failed to ask enough "what ifs?".
All of these scenarios count as bugs. Depending on who you talk to, youíll get a different answer as to a technical definition. Many developers, for example, consider the phrase "Y2K bug" to be a misnomer because the problem arises from an intentional decision to use the two digit date system, as opposed to four. While this scenario can wreak havoc when calculations extend beyond the year 2000 (or when a variety of other situations occur), many people donít consider the problem to be a bug, per se, because it isnít an unintentional failing on the behalf of the developer. If, however, the Y2K problem was caused by a compiler glitch, or something along those lines, then it would classify as a bug according to this technical definition.
To most people, however, it doesnít matter what is causing the problem. Basically, from a userís perspective, anything that prevents a program from running the way itís supposed to can be classified as a bug.
Likewise, regardless of cause, anything that causes a program to malfunction needs to be fixed. I spoke with designer Harry Teasley of Valve Software about the issue, and he had some interesting things to say. My first line of questioning revolved around the mechanics of dealing with bugs if and when they appear. Basically, I wanted to hear about the process that developers go through to test for, isolate, and fix bugs. Harry told me in a very clear, concise manner. And now, heíll tell you, too:
Me again. The basic development process works almost like a building construction project. The very early stages involve raw materials that in no way resemble an actual building. Concrete, glass, plastic, and so forth. Then, the fundamentals are put up: the basic structure, without windows, doors, wires, or toilets. Once the "skeleton" is up, the construction workers can actually move about inside the house and work on it from a variety of angles. While it may not be pretty, you can start to see the form of a building taking place. Eventually, after a good deal of poking around, the building is finished.
Software development works in much the same way. A game begins as a collection of parts that are constructed individually. For a while, the "game" remains solely a collection of files that are slowly built up to a point where they can finally be connected and executed in a rudimentary fashion. At this point, the primary program files can be linked and, theoretically, the game "exists" in a basic, rough form. The developers can "play" the game, to some extent, and begin to iron out problems and push it toward completion. From here on in, theyíre poking and prodding, trying to add polish and smooth out the rough edges.
There isnít a magic moment when a software project is "finished." Rather, there is a period of time when the developers consider the program to be "feature complete," and focus their time solely on trying to find problems that they had not anticipated. This process is especially important for console games, which canít be patched. If a Playstation or Dreamcast game slips out the door with some serious problems, there is little a company can do to solve them. Once again, Harry Teasley:
On a final note, Iíd like to cut through the gloom and doom and bring Harry back to comment on one of his "favorite" bugs. Fortunately, not all bugs are evil:
We all know the truth in that.
- Jeff Solomon is a regular contributor to loonygames.
|Credits: Illustration © 1999 Dan Zalkus. Bugs! is © 1999 Jeff Solomon. All other content is © 1999 loonyboi productions. Unauthorized reproduction is strictly prohibited, so don't try it...we've got insecticide, baby.|