I can't wait to get to work today. When I first got in the door yesterday, there was general panic... a program I had written had been shipped to a client and had died immediately, even though that program had worked perfectly in our laboratory. Unfortunately, real life is never as simple as the controlled environment we face in the development lab. After a half hour of evaluation, we discovered the cause of the problem, and minutes later, the problem was history.

The client was happy, my boss was happy, I was happy. Then, the client started actually using the software and discovered that it didn't do what he wanted! Oh, it worked exactly as it had been designed (perfectly conforming to the design specification). Thing is, the specification was wrong. And the client was unhappy.

I spent most of the rest of the day on the phone, or in meetings. We wanted to ensure that we understood exactly what the client wanted before we tried to fix the problem. Since I was going to be implementing the solution, I was invited to join in the discussions. By 3:30 pm, I was pretty sure I understood what was required. By 4:00 pm, I had filed a plan of action, and by 5:00 pm, a completely revised solution was finished, tested, and ready for distribution.

Not every problem I encounter is fixed as quickly, but in this case, I had anticipated some level of problems from the beginning. Not having been involved in the original discussions with the client, I used a defensive programming strategy - one that minimizes "hard coding", and relies instead on "rules" that are built independently of the code. So, when the "rules" changed, I merely had to tweak them a little... no muss, no fuss. It's a method I've employed through most of my 30 years as a programmer, and it works most of the time.

There is a down side to this strategy. It doesn't lend itself well to "dog and pony show" presentations. Until the very end, this strategy does not yield visible results. There have been times when my boss will wander over to my desk and ask how things are going. After responding that things are going well, he'll ask to see a program in operation. It's hard to explain that the program will not function - that there's absolutely nothing to see. He has to take on faith that, behind the scenes, individual components are being built and tested, and that, when all the components are complete, the finished product can be assembled and configured in a matter of minutes. I think today's response to the crises is the first real proof he's had of the validity of my approach.

I've got to give him credit, though. He's quick to see the benefits and potential of this strategy. No longer a skeptic, he discussed this methodology with me, and asked how it could be used to design a new module that was requested yesterday by the client. It turns out that much of the work I've been doing for the past couple of weeks can be directly applied to this new request, and I believe I should be able to deliver a working solution by Wednesday. So like I said, I'm really looking forward to work today.