Not too long ago, Jeff Atwood over at codinghorror.com wrote an article on Exception Driven Development. It's an interesting post and well worth the read. As I read it, I had to smile and congratulate Jeff for discussing something that is near and dear to our hearts here at Hericus Software.

I won't comment on trying to create a new methodology for software development, but I will toot our horn a bit for something that we've had in the product for a while now. As I read the article, it was almost a clear recipe for a key feature that we have in Zed Builds and Bugs that really helps to focus our bug tracking and development time. We call it our Exception Log Forwarding system. I know, I know, never let developers name anything. We're just not good at names. :-)

That being said, we are good at writing code, and this is one of the more interesting pieces of code in Zed. From the very first day in the life of the Zed code base, the internal logging system has been at the heart of the product. We've spent a good amount of time capturing log messages, and the system we have in place works really well. It performs well, doesn't get in the way of everything else going on in the system, and allows us to be as verbose as we like with the log messages.

It wasn't too long after we had the system "out in the wild" when we realized, though, that we had a gold-mine of information that could help us to make the product better. It just wasn't flowing back to our main system quickly enough. We had to rely on customer reports of strange behavior or error messages that they would see, and then, we could try to chase the problem down. Usually, though, we were without quite enough information at our disposal, unless we could share the desktop session with our customer to watch what they were doing.

Enter the Exception Log Forwarding system. We realized that if we added the (optional) feature of allowing the Zed system to automatically forward any error message dumps that were triggered by an ERROR or PANIC level log message, we would immediately know about the problem, and we would have all of the diagnostic information we would need in order to proactively fix the problem. The message forwarding is optional, and it is easily turned off in the system properties. With even a small percentage of our customers leaving it turned on, though, we get a wealth of information about things that we need to fix in the system.

Don't take this the wrong way, though. We're not being flooded with these messages. Zed is a very stable product, and at the moment, there are 14 messages in our Exception Log queue. Those messages have come in over the past 2 weeks. Some of these actually point out places where we have been a bit overzealous in terms of marking log messages as ERROR level. Some of them really qualify as a simple WARN message that can be safely ignored.

The benefit, though, is the way that we can be proactive in fixing any issues that we see coming in from the field. Combine this with our automated updating system, and we have a way to find and fix errors often before most customers realize that there is a problem.

Zed should always work for you and be something that you can rely on. We're doing our best to ensure that this is always the case.

So thanks, Jeff for the great article on Exception Driven Development. We're right there with you and have been for some time now.

Add a comment

Posted by Hericus Software on May 22, 2009 9:31:00 AM CDT #