Last week was the start of the Big Test of our system by the Customer. Our project group had been preparing for it for months. It was a difficult system to build, with many technical challenges. In some areas, I believe that we can claim that we moved the state of the art forward. We worked long hours, turning ideas into a working artifact.
The Big Test was scheduled to last for ten days. The Customer had asked for something ambitious, and we believe that they expected our system to fail some or perhaps many of the tests. If it failed a test, they’d tell us, and then they’d give us an opportunity to try to fix it, and then they’d try the test again, and perhaps it would fail again, and we’d tweak it again, and then finally it would get through that test, and this would continue through ten long and potentially sleepless days. At the end, they’d count up the number of tests we passed and the number of tests that we’d failed, and give us a little time to write a report about what we thought we might be able to do about the failures if they gave us more time.
I wondered whether I’d spend Thanksgiving doing a postmortem on the parts of the system that were my responsibility.
That’s not what happened.
The Big Test was over in three days. The Customer tried their tests, and they all worked on the first attempt, except for two that had a small problem. The team in charge of that area quickly found the problem and addressed it; the Customer has promised to look at the changes, but they do not seem to be in any particular hurry. The Customer has told us that they believe that the system is fundamentally sound and that the problems they uncovered are of only minor significance.
The rest of the week was relaxed. We spent it addressing some issues that we think the Customer will want to see soon, or that we were surprised that they didn’t test–they might change their mind. Technically, the test period is not over, and the Customer is within their rights to invent and run new tests, although nobody really believes that will happen.
This morning–Saturday morning–I awoke early. My mind was filled with ideas for new tests, new improvements, enhancements to the existing system. The documentation is not good; I could rewrite it. One of the control dialogs has a different dialog model than the others; I could fix that so that users wouldn’t see that rough edge.
The Customer is happy with the system, but I know that it’s not perfect. And so I wake up early on a Saturday and consider going into work. Not because I think I can make the system perfect–I know better than that–but because I believe that I can make it better.
But this story isn’t about me. I am only one member of the team that built this system, and I’m not the smartest, nor the hardest-working, nor the most important. I don’t have any irreplaceable skills. My main qualification for being on the team is that I want the system to be something worthy of pride, but the team isn’t successful simply because I have a mild obsession for working past Good Enough.
It’s successful because we all do.
I quite jealous. To work on a system that is at its worst, “not perfect”, would be a delight. Currently I fight long and hard on a product that was poorly conceived and overly funded. It is proof that money can’t buy quality if its a bad idea to begin with. I watch it veer in slow motion towards its inevitable doom, another unused and abandoned system.
If you give thanks this holiday, definitely remember how good it is to have a satisfied customer. I haven’t had one in two years.
Comment by alendar — November 20, 2010 @ 1:13 pm