Remember the programmer who checked a stubbed function into the source management system?

void NewClass::get(std::istream & get_from) {
    // TODO
}

In a test-first environment, the TODO is superfluous. The accompanying unit tests show exactly what needs doing. In a console window, we see something like:

Test    : testNewClassGet
   testNewClass.cpp(57): Expected "foo" but got "bar"
   ————————————————————
   Ran 13 tests, 12 Passed, 1 Failed.

Here, the feedback is swift and accurate, and continues to be so even once the class is complete (that is to say, once it passes its tests). Should something cause NewClass to regress, a good set of tests will isolate the error even before the offending code gets checked in.

In other words, the TODO list and the FIXME list have been replaced by test results. We have done the best we can to ensure our NewClass does not end up being yet another LegacyClass.

Now remember the HACK which covered up a broken threading model. We will need to work much harder to stop the rot advancing any further (in both the code-base and the organisation), but again, my main recommendation would be to invest in a test framework—a system test framework in this case.

If we can create a suite of tests which exercise the code to systematically expose the threading problems, we may have a chance of understanding them. If we can automate these tests and publish results in a user-friendly form -- bearing in mind that users are not just engineers, but everyone with an interest in the code-base—then we may yet fix them.