[TMMM] Ch 13 – The Whole and the Parts

<< Chapter 12 Sharp Tools

Designing the Bug Out

Bug-Proofing the Definition

Bugs arise from mismatched assumptions made by the authors of various components.  It is essential, therefore, to maintain conceptual integrity.

Careful function definition, careful specification, and disciplined exorcism of frills of function & flights of technique all reduce the number of system bugs that have to be found

Testing the Specification

An outside group should always be brought in to scrutinize the specification for completeness and clarity.  Developers cannot, and should not, review their own spec:

They won’t tell you they don’t understand it; they will happily invent their way through the gaps and obscurities

Top-Down Design

Niklaus Writh’s formalized design procedure outlines the design process as a series of refinement steps.  You start at the highest, most abstract, level and you move in.  You use high-level notation to expose the concept while concealing the details until more refinement is necessary

1. Clarity of the structure and representation makes the statement of requirements and functions of modules easier
2. Partitioning and independence of modules avoids system bugs
3. Suppression of details makes flaws in the structure more apparent

Component Debugging

You can use some of the following techniques for component debugging  (that is, debugging a single portion or feature of the system)

• On-machine debugging
• memory dumps
• snapshots
• interactive debugging
• test cases
• etc.

System Debugging

System debugging will take longer than one expects, and it is because of this that it needs to be thoroughly planned and systematically executed.

Use Debugged Components

Don’t debug the system until the parts/components work!

You could take a “bolt-it-together and try it” approach.  This assumes that there will be system bugs on top of the fixed component bugs.

There is also the “documented bug” approach.  Components are allowed to enter system test as soon as all flaws are found, but before they are all fixed.  This ignores the bug of the component and focuses on new phenomena in the integrated system environment.  This is approach is dangerous because the fixing of a component bug is bound to introduce more bugs.

Build Plenty of Scaffolding

Build hooks into your program for debugging purposes.  These hooks should never be intended for the final product though.  There may be as much as 1/2 as much scaffolding as there is product.

• Dummy component: make a dummy object that fakes expected output and behavior if that component isn’t finished yet
• Miniature File: create mini test files to operate on
• Dummy File: same idea, but “the file really isn’t there”???
• Auxiliary Programs: helper programs that do various tasks, generate test data, output verifiers, etc.

Control Changes

Someone must be in charge.  He, and he alone, must authorize component changes or substitution of one version for another.  When changes happen, they must be logged, thought-through and tested (Purple-wire technique).

Add One Component At A Time

Resist the temptation to do more than one component at a time.  Always assume the worst, that the new component has lots of bugs and will require extensive testing.

Quantize Updates

Don’t update the product as fixes are being implemented, quantize them into chunks/bursts.

Each team working on the system will be working on the most updated copy of the software.  The software will change, but don’t change it every time a fix is committed.  Update in batches.

Make a quick patch that holds until the next regular release of the component, which should incorporate the fix in a tested and documented form (purple-wire method)