How Software Development Really Works
Most books on programming present the software development process as a linear progression from the beginning to the end of a project with no detours on the way. However, this is a very misleading picture of what is actually an iterative process: every actual project requires a lot of feedback from users. It also requires considerable time spent correcting errors that may have been overlooked in previous revisions or introduced while adding new features (or even fixing old bugs). The whole process often involves one step back (or sideways) for each several steps forward.
In fact, even the picture I just presented of the incremental implementation of the home inventory program up to this point is over-simplified. I left out a number of occasions on which designing and implementing a new feature took several attempts, including adding further infrastructure support (e.g., the less_nocase function in the xstring class).
This whole process may seem odd. After all, programming is not a “soft” subject; for any given program, it should be fairly easy to decide whether it works or it doesn't.[10] The error in this analysis is that even relatively simple programs (such as the one we've spent so much time on) are complex constructs that display a wide range of behavior. Given this complexity, determining whether a given program “works” is anything but trivial; otherwise, I wouldn't have needed Susan to test the program after I finished my own testing. In fact, on virtually every occasion when I had her test a new version of the program in which I had made significant changes, she found some anomaly that necessitated further work. This is anything but unusual; in fact, some large software companies, in a process known as beta testing, send out thousands of copies of each of their major programs to be tested before they release them, in the hope of finding most of the bugs before the paying customers find them (and get upset). Of course, those programs are much more complicated than the little one we've been developing, but the principle is the same: if a program hasn't been tested, it will have bugs.[11]
[10] Actually, this is not true in theory. It was proven many years ago that it is impossible in the general case even to determine whether a particular program will run forever or stop, given a particular set of input, by any mechanical means. This is the famous “halting problem” of Alan Turing. In practice, however, it is usually possible to determine whether a meaningful program works correctly, although this may be quite difficult to do.
[11] According to a very well known principle called “Murphy's Law”, even if a program has been tested, it will still have bugs.
Luckily, by using the techniques I've illustrated, it's possible to produce programs that should have fewer bugs, and bugs that are less difficult to find. Hopefully, the program that we've just finished working on doesn't have very many bugs left in it by this time, but I can't guarantee that it is bug-free.[12]
[12] By the way, if you find any bugs in this or any of the other sample programs, which is certainly possible despite my (and Susan's) testing, please let me know so I can fix them for the next printing of this book.
Now it's time for some review of what we've done in this chapter.