Saturday, May 22, 2004

Instrumentation - My Constant Saviour

When I'm doing a development project, it is typically a 3 - 6 month engagement doing a custom application for some specialized task. The last one of these I did (which I finished last week) was a tool that converted vector images to raster images and also processed and extracted some specific data out of the vector images. After trialling a number of components, including Lead Tools (which performed quite badly), CorelDRAW 12 was settled upon. CorelDRAW has a rich automation interface, handled all the vector formats required (SVG and CGM up to v5), had great raster image production quality, and was pretty cheap (~AUS750).

As anyone who has done any automation will tell you, lots of things can go wrong when you are talking to another process. Anticipating this, I sprinkled my code with a plethora of Trace.WriteLine statements, about one for every 5 lines of code, and at least one per exception handler. On my last day on the project, the inevitable failure-that-only-occurs-in-production error occurred during a final test run, and the image conversion process stopped working. Everything appeared fine, but images where never being moved into the completed folder. Instead of panicking, or trying to get a debugger attached or installed on the production machine, I simply got the client to fire up DebugView off a USB memory stick, and we could immediately see that the line that wrote a log record to the database was failing due to some SQL Server log file issue. We changed the connection string in the configuration file, and did the test run with logging to a separate database.

End result: I got out of there on time, and the client was happy.

The morale of the story is use the best instrumentation strategy you can, and never trust a client or manager who says instrumentation isn't need. Microsoft's Enterprise Instrumentation Framework is great for server-side apps, but has a very weak deployment story that makes it unsuitable for client side applications. Log4NET looks good, but I haven't used it in a production app. More and more, I've grown tired of managers scratching themselves trying to decide between the various options, and I've stuck with the reliable, always-available Trace.WriteLine. With TraceListener-derived types, Trace.WriteLine scales from in-debugger output right up to enterprise solutions like Microsoft Operations Manager (MOM).

I owe many finish-the-project-on-time moments to this one method.


Post a Comment

<< Home