Quality Control - Part 2

The trick to quality software development is knowing when to use each method as described in my last entry titled Quality Control Part 1.

The “excessive traffic light” method should be used in places where performance is not an issue. For example, when the user tries to store a preset, we want to communicate well with the operating system, making sure the preset was properly saved. If it wasn’t, we want to notify the user in a meaning manner. Accomplishing this in 10 milliseconds is not our goal!

The “black box method” is great during development, but is not much use after the software has been released to users (unless they are friendly enough to send the error reports back to the developers). During development, this method is sometimes the best way to understand complex interactions between separate yet coordinated operating system processes, because you can “observe” the system without really affecting too much. Though Heisenberg’s principal definitely comes into play (see today’s link). The more data you try to observe the worse it gets, and searching for meaning in a report with sometimes tens of thousands of entries can be very difficult.

One of my favorite development methods is the “driver training” method. Whenever I identify an especially complicated or error prone part of a system, I employ what are sometimes called “asserts” in programming lingo. An “assert” is like a resident driving instructor, who if observing something unexpected, will immediately yell at me during execution. The instructor stays around during development cycles, but once the system has been adequately trained, the instructor vanishes, unburdening the system for ultimate performance.

Today’s link: http://en.wikipedia.org/wiki/Uncertainty_principle

Stephen Evans
Developer