MY FAVORITE retired computer programmer, Danny Hancock — known to one and all as the good brother — saw the failure of the Obamacare Web site coming. His words of wisdom:
I predicted this. I was involved in so many startups that . . .
. . . I developed a nose for trouble.
I preferred to work with managers who had been burned before. President Obama didn’t have the business experience to have been burned before. I can see the weekly meetings in my mind’s eye: “No, everything is fine. We’re on schedule.”
Here are some good rules of thumb for rolling out a new system, developed from hard experience:
If you give the new product to someone to test and he or she tells you the next day that everything is fine, the test was worthless.
The first iteration of a new product entered for testing never works. The is really strange, but almost always true. Even after I got good at asking improbable questions in requirements planning sessions, it stayed true.
Just run the thing through one time and 80 percent of the problems will surface.
Don’t trust any programmer who says, “This thing is so simple it doesn’t need to be tested.”
If the person assigned to run the test says, “The screen’s too green,” stop immediately and get someone else to run the test.
If the programmer says, “Everything is fine; we’re on time,” and doesn’t look you in the eye, he or she is hiding something. Something important.
The proper mindset for running a test is: “I want to find an error. I would be happy to find an error. No, I would be delighted to find an error.”
Make a list for the manager, up front, about what the system to supposed to do. Pull the list out every week, until the manager is sick of seeing it. At least the manager can’t deny he or she knew what was coming. This will save your bacon on start-up day.
The programmer should not serve as final tester. He or she knows what the program expects. He or she enters it. The program works. Surprise!
The real drop-dead deadline is at least two weeks — better, a month — before the scheduled start date.
Finally, always leave yourself an out.
The first iteration of a new product entered for testing never works. The is really strange, but almost always true. Even after I got good at asking improbable questions in requirements planning sessions, it stayed true.
Just run the thing through one time and 80 percent of the problems will surface.
Don’t trust any programmer who says, “This thing is so simple it doesn’t need to be tested.”
If the person assigned to run the test says, “The screen’s too green,” stop immediately and get someone else to run the test.
If the programmer says, “Everything is fine; we’re on time,” and doesn’t look you in the eye, he or she is hiding something. Something important.
The proper mindset for running a test is: “I want to find an error. I would be happy to find an error. No, I would be delighted to find an error.”
Make a list for the manager, up front, about what the system to supposed to do. Pull the list out every week, until the manager is sick of seeing it. At least the manager can’t deny he or she knew what was coming. This will save your bacon on start-up day.
The programmer should not serve as final tester. He or she knows what the program expects. He or she enters it. The program works. Surprise!
The real drop-dead deadline is at least two weeks — better, a month — before the scheduled start date.
Finally, always leave yourself an out.
The only way to stress-test a large, complex system like Obamacare is to hire a hacker to write a program to simulate a denial-of-service state. Even with a more robust and well-tested system, however, the managers — if they had had any sense — would have staggered the start by day-of-birth to avoid having a ton of rocks fall on the system on day one.
One of my bosses passed around an article with this question: “If your software were an airplane, would you fly across the ocean on its maiden flight?”
“Hell, no,” I answered. “I know the programmer who wrote it all too well.”
Comments