The sales disconnect

so today I had a longish conversation with our 'sales' guy. He's in France at the moment. The reason we had the conversation is that I need to spend a week in Dallas testing some significant changes I've made over the last two or three weeks to our software. I've been playing this game for a very long time and one thing I know is that no matter how confident I am that my changes are correct they're not correct until I've tested them. In this case the only way I can do the tests and feel confident of a good release is to go to Dallas again, where there's some hardware available upon which I can run my tests. This much my regular readers already know.

I'd imagine that most of my readers, even those who are not developers, also understand that it's a BAD thing to do a buggy release. Customers will forgive a missing feature much more easily than they'll forgive a bug that destroys a document in progress. Now understand that the software I'm testing is used to give the go/no go for shipping maybe US$80,000 worth of semiconductors per run, 3 runs per day. If my changes to the software cause good devices to be classified bad then each passing day that the software has a bug could cost our customer a quarter of a million dollars. (Hmmm, now THERE's an argument for a pay rise ).

I'm not able to go into exact details of what my changes are so bear with me. At the end of last year I went to France to discuss some changes needed by our customer. I had the bulk of those changes done by early January and I went back to France to install the software. You should already be scratching your head; he needs to travel from the USA to France to install some new software? Uh huh. I've posted in the past about the way our software abuses the registry. In this case there were some software changes needed; and some registry changes. One could document the registry changes and ship new binaries but experience tells me that doesn't work. The problem is that the registry dictates the software configuration but we can't predict exactly how the customer wants the software configured (and they want to be able to change configurations at will).

The solution is obvious; add some configuration tools with a nice GUI interface (might I add that this is a new concept where I work ). Which not so terribly obscure insight lead to the large scale changes in our runtime that I need to test. Suddenly we have a user interface that can change the configuration; the runtime has to be notified of the changes and reconfigure itself. This is something it's never before had to do. Before, we'd change something, kill the runtime and the GUI, and restart it all. There are two people in the world who know how to manually edit the registry for our product; myself and my predecessor, and I only know how because I have the source code and can work backwards from what's not working to what registry key controls it.

If this sounds like a maintenance nightmare you'd be right. It seems ridiculous to me that if our customer wants to do X I have to spend 46 hours travelling to Baguio City in the Philippines to make a 10 minute change (I did exactly that in January this year - but on the upside I did get to visit Korea and Japan as part of the trip). And, as much as I like visiting Nice, France, it's equally ridiculous to travel there to spend 4 minutes editing another registry key. Yet, documenting our part of the registry isn't a lot better. Our customer asks us how to do X - we respond; change key Y to this and restart. The customer responds that it doesn't work. If we assume they did the registry change right then we have to assume we have a bug. So we try to duplicate and, lo and behold, it works here. The tooing and froing can take weeks! Meanwhile we have a pissed off customer. I hope the alternative is obvious. It might take me three days to write a dialog that will cover all possible cases but that's three days spent at home and three days of work to depiss the customer .

So back to todays conversation with Kevin. Having been willing to send me to France to spend 10 days waiting for our hardware to become available; having been willing to send me to Dallas to spend 2 weeks doing nothing that I couldn't have done at home; having been willing to send me to Baguio City for 6 weeks to do things that could just as easily have been done at home; suddenly he's all concerned that I want to spend a week in Dallas. 'What changes have I made that need to be tested?' I explained that I'd added a user interface to allow our customer to make the changes that would otherwise require me or my predecessor to travel half way around the globe.

'So did you HAVE to do that?' he asks.

What could I say? It wasn't on the list of things the customer demands. Well, not in so many words!

I'm not in sales but I do have eyes and ears and I've had at least as many years in this biz as Kevin has (more actually). As far as I can tell Kevin (and my boss for that matter) believes that if you throw enough people at a problem (whether they're able to solve it or not) you'll impress the customer enough that the problem goes away. Hence the willingness to send me halfway across the world.

Now here's a radical idea guys. Why not solve the root cause? Why not actually spend a quarter of the dollars to actually test the software BEFORE you ship it? A bug the customer never sees costs a lot less.