A good debugger and techniques that make code easier to understand were essential for project success.

Better debugging capability (than was provided with the previously used CodeView command line compiler/debugger) was achieved through use of a Borland Turbo C IDE (integrated development environment) compiler/debugger.

Code was cleaned up by reducing the number of global variables (i.e., better variable localization). By passing (formerly global) variables as arguments, it became more apparent which subroutines were doing what to the state of the tool, making the code less brittle (or less likely to break at the lower levels from higher level changes).

Implementing more descriptive naming conventions (replacing obscure abbreviations in variable names with slightly longer English verbs), as the higher level purposes of various pieces of code were decyphered, and using an abbreviated level of (what programmers refer to as) Hungarian Notation (to indicate variable scoping and type, see: Making Wrong Code Look Wrong) resulted in a well understood software package that completed Waterfall development phases on time and made the transition into a 24x7 manufacturing environment smooth and error free.
Reverse Engineering Legacy Code
Versatest had previously implemented the ability to detect questionable failing die in their VT3300 testers. Our site however, needed this functionality on the older VT2100s.

While the VT3300s ran under Windows, the VT2100s (described here) ran under Dos, and used an old product called Deqview (to achieve a level of multitasking).

Because no one was left who understood the original code, Versatest turned down the project (to implement similar functionality for their legacy VT2100 testers).

Upon deciding to take on this project inhouse, the first step was to reconstruct and qualify a functional system from the existing code base. To enable the project to be further estimated and scheduled, a three month up front software feasibility (or learning/investigation) stage was setup (as the first stage in a Waterfall software process) and approved, prior to starting (what became) a nine month software effort.