Why are there Bugs in Software?

Part:   1  2  3  4  5   6  7  8  9  10  11  12  13  14  15  16  17  18 

(Continued from previous part...)

Believe Defect-Free Software is Possible

The average engineer acts as though defects are inevitable. Sure, they try to write good code, but when a defect is found, it's not a surprise. No big deal, just add it to the list of bugs to fix. Bugs in other people's code are no surprise either. Because typical engineers view bugs as normal, they aren't focused on preventing them.

The defect-free engineers, on the other hand, expect their code to have no defects. When a (rare) bug is found, they are very embarrassed and horrified. When they encounter bugs in other people's code, they are disgusted. Because the defect-free engineers view a bug as a public disgrace, they are very motived to do whatever it takes to prevent all bugs.

In short, the defect-free engineers, who believe defect-free software is possible, have vastly lower defect rates than the typical engineer, who believes bugs are a natural part of programming. The defect-free engineers have a markedly higher productivity.

In software quality, you get what you believe in!

Think Defect-Free Software is Important

Why is defect-free software important?
Delivering defect-free software reduces support costs.
Delivering defect-free software reduces programming costs.
Delivering defect-free software reduces development time.
Delivering defect-free software can provide a competitive advantage.

Commit to Delivering Defect-Free Software

Making a firm commitment to defect-free code and holding to that commitment, in spite of schedule and other pressures, is absolutely necessary to producing defect-free code. As a nice side benefit, you will see improved schedules and reduced costs!

Design Your Code for Simplicity and Reliability

After attitude and commitment, program design and structure have the biggest impact on defect-free code. A clean, well structured design simplifies producing reliable code. A poor design cripples the engineer, and will make it impossible to achieve defect-free code.

Each function should be precise -- it should have only one purpose. Each action or activity should be implemented in exactly one place. When programs are structured this way, the engineer can easily find the right place to make a change. In the unlikely event that a bug is discovered in testing, the engineer can go directly to the code with the defect and promptly correct it. This saves time and is the major cause of the faster schedules experienced with Defect-Free Software.

In addition to designing for clarity, it's important to keep the defect-free goal in mind. You want to choose designs that will be least likely to have bugs. In other words, avoid tricky code. Don't start to optimize code unless you are sure there is a performance problem.

Trace Every Line of Code When Written
As each line of code is about to be executed, you should try to predict what the effect will be -- what data will be changed, which path a conditional will follow, etc. If you can't predict what the effect will be, then you don't understand the program you are working on -- a very dangerous situation. If you don't predict correctly, you have probably discovered a problem that should be addressed.

Tracing all new code shows: Code that hasn't been tested. By stepping through each line of code, you ensure that the new code is fully tested.

(Continued on next part...)

Part:   1  2  3  4  5   6  7  8  9  10  11  12  13  14  15  16  17  18