Around three weeks ago I delivered a project to a client. They did some user testing and found a few issues. There were a couple of new features that they wanted added. And if the database timed out, which it did rarely when there was a lot of traffic, then my app crashed very inelegantly.

The crash wasn’t hard. I caught the exception and showed a message box saying something like “There is a database error. Try again and if the problem persists then contact your system administrator.” They were happy with that.

The additonal features were fairly straightforward. They were all to do with searching through a collection. In days gone by this probably would have meant using regular expressions. But not any more. Throw in a bit of LINQ and voila, feature done, more or less.

I loaded the changes onto my laptop and took it out to the client. They agreed that it was all good and I left the files with their systems guys to load up. A little later in the day I received an email saying that it didn’t work. Nothing worked. Every screen, including the ones which previously worked fine and were all approved, now crashed. This was impossible.

The application worked on my laptop, they had seen it work. It worked on my development machine. My unit tests passed. Everything worked. Except where it mattered; it didn’t work on the client’s system.

The one response to bugs that every developer hates to give is – but it works on my machine. The client doesn’t care about your machine. If you turn it on and it catches fire and burns your house down, the client doesn’t care. The client only cares that your application doesn’t work on his machine.

So we developers don’t say that it works on my machine. Instead we say that we cannot reproduce the bug. That sounds much better. And if we have bug tracking software we probably even have a category – Cannot Reproduce. But it means the same thing.

Now, we all have clients who will ring up after you have spent three days chasing down an elusive bug and say, “I forgot to mention, we have had a blackout for the past three days. Will that stop your program from working?” Or something equally inane. But my client wasn’t like that. They had technical people there who are pretty smart and they also tried to find the cause of the bug.

After a few days we found the problem. Naturally it was my fault. The details aren’t important but it boils down to the fact that my development machine is not the same as their production machine. I have dlls installed that they don’t. It is easy to forget to copy them all across. It is easy to leave the database connection string unchanged. It is easy to forget to change the configuration from debug to release.

In other words it is easy to forget to do a whole heap of things. That’s why we use computers, they can remember stuff that we don’t.

Next time we will look at what we need to ensure that we are set up properly so that we don’t look like an idiot in front of the client.