FAQ 10.04 What will happen if techniques like those presented here are not used?

The maintenance programmers are doomed to crawl for miles over broken glass.

Here are some facts. First, in large systems the "distance," as measured in statements executed, from where an error occurs to where it is detected by the program crashing or producing incorrect results is usually very large, sometimes millions of instructions. Second, one of the most effective techniques for reducing the time and pain associated with debugging is to minimize this distance, that is, discover the error as soon as possible after it has occurred. Third, there are usually thousands of small invariants that programs must maintain to be correct. Fourth, when programs are built using classes and objects, most of these little invariants are associated with the classes and objects.

Therefore, by collecting all these small and seemingly inconsequential invariants and attaching them to the right objects in a systematic fashion, it is possible to build a very robust system that tests itself. This, in turn, minimizes the amount of broken glass that has to be crawled through in trying to find that one fault that occurred a few million instructions ago and just caused the system to crash.

Some programmers build self-testing objects for the good of the team, others out of enlightened self-interest. Either way, self-testing objects should be built. After all, no one should have to crawl over broken glass when such a simple and obvious technique is available.

By the way, if you happen to be the developer who finds everyone else's bugs because you are methodical and they are cowboys, then you should be lobbying hard for your team to use these techniques. Either that or maybe you should just institute a policy that the cowboys on the team eat the glass you have to crawl through because they refuse to build self-testing objects.