other times the programmer might change some correct behavior to a different correct behavior without realizing that some other code depended on the original correct behavior. (Imagine if someone switched the arrangement of your hot and cold water faucets. Either arrangement would work just fine, but you may get a nasty surprise the next time you take a shower.)
Any time you change the code, whether by adding new code or fixing old code, you need to test it to make sure everything works as it should.
Unfortunately, you can never be certain that you’ve caught every bug. If you run your tests and don’t find anything wrong, that doesn’t mean there are no bugs, just that you haven’t found them. As programming pioneer Edsger W. Dijkstra said, “Testing shows the presence, not the absence of bugs.” (This issue can become philosophical. If a bug is undetected, is it still a bug?)
The best you can do is test and fix bugs until they occur at an acceptably low rate. If bugs don’t bother users too frequently or too severely when they do occur, then you’re ready to move on to deployment.
EXAMPLE Counting Bugs
Suppose requirements gathering, high-level design, low-level design, and development works like this: Every time you make a decision, the next task in the sequence includes two more decisions that depend on the first one. For example, when you make a requirements decision, the high-level design includes two decisions that depend on it. (This isn’t exactly the way it works, but it’s not as ridiculous as you might wish.)
Now suppose you made a mistake during requirements gathering. (The customer said the application had to support 30 users with a 5-second response time, but you heard 5 users with a 30-second response time.)
If you detect the error during the requirements gathering phase, you need to fix only that one error. But how many incorrect decisions could depend on that one mistake if you don’t discover the problem until after development is complete?
The one mistake in requirements gathering leads to two decisions in high-level design that could be incorrect.
Each of the two possible mistakes in high-level design leads to two new decisions in low-level design that could also be wrong, giving a total of 2 × 2 = 4 possible mistakes in low-level design.
Each of the four suspicious low-level design decisions lead to two more decisions during development, giving a total of 4 × 2 = 8 possible mistakes during development.
Adding up all the mistakes in requirements gathering, high-level design, low-level design, and development gives a total of 1 + 2 + 4 + 8 = 15 possible mistakes. Figure 1.1 shows how the potential mistakes propagate.
Figure 1.1 The circles represent possible mistakes at different stages of development. One early mistake can lead to lots of later mistakes.
In this example, you have 15 times as many decisions to track down, examine, and possibly fix than you would have if you had discovered the mistake right away during requirements gathering. That leads to one of the most important rules of software engineering. A rule that is so important, I’ll repeat it later in the book:
The longer a bug remains undetected, the harder it is to fi x.
Some people think of testing as something you do after the fact to verify that the code you wrote is correct. Actually, testing is critical at every stage of development to ensure the resulting application is usable.
DEPLOYMENT
Ideally, you roll out your software, the users are overjoyed, and everyone lives happily ever after. If you’ve built a new variant of Tetris and you release it on the Internet, your deployment may actually be that simple.
Often, however, things don’t go so smoothly. Deployment can be difficult, time-consuming, and expensive. For example, suppose you’ve written a new billing system to track payments from your company’s millions of customers. Deployment might involve any or all of the following:
● New computers for the back-end database
● A new network
● New computers for the users
● User training
● On-site support while the users get to know the new system
● Parallel operations while some users get to know the new system and other users keep using the old system
● Special data maintenance chores to keep the old and new databases synchronized
● Massive bug fixing when the 250 users discover dozens or hundreds of bugs that testing didn’t uncover
● Other nonsense that no one could possibly predict
WHO COULD HAVE PREDICTED?
I worked on one project that assigned repair people to fix customer problems for a phone company. Twice during live testing the system assigned someone to work at his ex-wife’s house. Fortunately, the repair people involved recognized the address and asked their supervisors to override the assignments.
If psychics were more consistent, it would be worth adding one to every software project to anticipate these sorts of bizarre problems. Failing that or a working crystal ball, you should allow some extra time in the project schedule to handle these sorts of completely unexpected complications.
MAINTENANCE
As soon as the users start pounding away on your software, they’ll find bugs. (This is another software axiom. Bugs that were completely hidden from testers appear the instant users touch the application.)
Of course, when the users find bugs, you need to fix them. As mentioned earlier, fixing a bug sometimes leads to another bug, so now you get to fix that one as well.
If your application is successful, users will use it a lot, and they’ll be even more likely to find bugs. They also think up a slew of enhancements, improvements, and new features that they want added immediately.
This is the kind of problem every software developer wants to have: customers that like an application so much, they’re clamoring for more. It’s the goal of every software engineering project, but it does mean more work.
WRAP-UP
At this point in the process, you’re probably ready for a break. You’ve put in long hours of planning, design, development, and testing. You’ve found bugs you didn’t expect, and the users are keeping you busy with bug reports and change requests. You want nothing more than a nice, long vacation.
There’s one more important thing you should do before you jet off to Cancún: You need to perform a post-mortem. You need to evaluate the project and decide what went right and what went wrong. You need to figure out how to make the things that went well occur more often in the future. Conversely, you need to determine how to prevent the things that went badly in the future.
Right after the project’s completion, many developers don’t feel like going through this exercise, but it’s important to do right away before everyone forgets any lessons that you can learn from the project.
EVERYTHING ALL AT ONCE
Several
