Corporate Responsibility is the Key
Reader response to Those Damned Bugs! by Gene Callahan
Dear Dr. Dobb's,
Just my .02. As with any subject as complex as that of bugs in computer software development, there are lots of right and wrong assertions. Every software engineer I know strives to deliver code that is as bug-free as humanly possible. It is a source of pride and accomplishment that we do so, and yet we inevitably fail. We fail because forces beyond our control conspire to make every piece of commerically produced software on the market rife with bugs. There are 3 major forces involved.
1. Corporate marketing/management. When a product idea is developed, the timelines for producing the product are never set by the engineers, or even the designers. The features to be included are never set by the engineers, and rarely by the designers. They are set by marketing and/or management, driven by how much the company wants to spend producing the product, and by when marketing wants to start receiving revenue from the product. This means that if the timelines for getting all those features implemented are too short, frantic development teams start cutting corners. Cutting features is rarely an option, lengthing the timelines is never an option, but shrinking the testing schedule seems to be ok, as long as the thing ships in time. This is the most important force that produces buggy software.
2. The Gordian Knot that is testing. Any software produced for the PC, be it business software, or especially in game software, is written to run to certain hardware/operating system requirements. Unfortunately, the systems that 99% of the users of the software have in some way deviate from this "ideal" system. Testing staffs attempt to test the company's software on as many machine configurations as possible. Hundreds of graphic card/motherboard/memory/sound card/printer/modem/operating system combinations are tried, and most software when it ships has few bugs from those combinations that were tested for. Unfortunately, even with all that testing, only about 1% of the possible hardware/software combinations were tested. Most major bugs that happen to users happen because of this factor. Its impossible to test for every individual user's system.
3. Poor training/programming practices by engineers. This is the factor which is most talked about in discussions of software bugs, and is the one that has the least impact on bugs in software. While this factor does contribute, it is by far the least troublesome of the problems. It is also a factor which is beyond the control of most development projects. With the screaming need for engineers by companies these days, most projects are understaffed. This means no extra time for training, no time to help bring someone up to speed on latest technologies and practices. Just type as fast as you can and hopefully the smarter people in the group will help fit it all together in the end. Sounds scary? You bet, and it's only going to get worse, as more and more demands are placed on the current engineering pool.
So let's get the discussion where it belongs, corporate responsibility, better hardware/software standards, making testing a realistic goal, and allowing engineers to train, and do their jobs properly.
If you have comments, questions, or would like to contribute your own opinions, please contact us at [email protected]
