It has been over a year since the last time that I actually shipped software for production. As the NH Prof beta shipping has reminded me, this is not a trivial task. Actually, we had relatively few problems with NH Prof itself, it was with the web site that I run into a few teething issues. I am afraid that I treated the site as an afterthought at first.

Anyway, that made me reflect a bit over the last year. I discovered a very surprising truth. Most of what I do recently is not strictly technical. Oh, there is a heavy technical side for everything that I am doing, but a lot of that is simply social engineering within that context. Even my approach for API design or building a particular user experience are affected by this.

On my business card, I have a big sign saying: "Zero Friction Maintenance". That isn't something that require a technical skill, this is something that require social manipulation skills. Friction is a people problem, not a technical problem.

I am going to start a new series of post about social engineering in software development. Here is the initial topic list:

• Initiating Actions
• Delivering Confidence
• Gliding on the path of least resistance
• Walking on the Path of Success
• Failure Motivation

I probably should point out that what I consider social engineering might be considered by others as PR, politicking or playing with team dynamics.

The NH Prof website is running on Rhino Service Bus. I decided that this is a great time to test Rhino Service Bus for real, and I built the website on top of it. Even the order processing is done on top of RSB.

But that isn't what I wanted to talk about today. I wanted to talk about errors, and how important they are. In this case, I screwed up when I build the error reporting capability for NH Prof, which means that if you tried to report an error back, you would get a nasty 404 and I would get nada as feedback.

The actual fault is not relevant, and it is fixed already, so hopefully you'll forgive me for having bugs in a beta product.

What I really wanted to talk about was how I fixed the issue. Remember, this is the production machine, and I have no debugger there. What I did was go to the MSMQ interface, go to the back end queue and take a peek in the errors sub queue, where I got to see the following:

The first message is the original one, the second is the error description for it. When I opened it, I could see that the error was "AyendeIsStupidException", which explained exactly what went wrong, and I was able to quickly resolve the issue by buying more IQ on eBay. I then moved the message back to the main queue, and got the email that I expected about the problem with NH Prof.

A few important points about this:

• No debugging
• No hunting through the logs
• No custom tools. Rhino Service Bus Profiler doesn't exist (yet).
• In your face, explicit and very quick troubleshooting experience.

Error handling was an explicit design goal when I set to build Rhino Service Bus, and I am happy to be able to say that so far, it is proving that it is working, and is definitely worth the time I spent in it.

There is just one thing in the Msmq API that I hate.

If you try to send to a queue using the wrong transaction, it will silently not send you message, but give absolutely no error.

This is incredibly error prone, and has caused me quite a number of bugs.

If at all possible, API should never silently fail. In this case, the API should throw an explicit argument exception, saying that this transaction is not valid for this queue.

That would make things much simpler all around.