The faster you diagnose the problem, the sooner you can fix it. The sooner it is fixed, the sooner your project is completed and the sooner you realize business value. Code Contracts make diagnosis faster and easier because they provide better information than code without them. Faults occur regularly during development because the software is … well … under development. If I can shave 2-4 hours a week off of the time I spend diagnosing problems, I can produce more. But faults also occur in production. In production, the cost of failure is even higher. Several users may be down for hours, which may hinder their service to their customers. This affects your organization’s reputation. If you can turn a 4 hour outage into a 30-minute outage, that is a huge savings in wasted labor and reputational injury.
That is why I love using Code Contracts.
I have had numerous development incidents in the last week, in which the use of Code Contracts shortened my time to diagnosis by 2 hours. Let me explain how.
We are developing custom workflow activities in C# to work with custom workflows in Microsoft CRM. When the CRM platform tries to bind the custom workflow of the platform to our custom workflow activity code, if errors occur, they are often swallowed up. When this happens, we must resort to enabling tracing on the platform, rerunning the the task to reproduce the error, turning off tracing, and examining the text-based trace logs, which are NOT easy reading.
We learn from pain. Now, to improve the speed of diagnosis, we use two techniques:
- wrap all custom workflow activity code in an outer exception-handling backstop, which writes exceptions to the Event Viewer before rethrowing them. I would think this is best practice for ANY application.
- Include Microsoft Code Contracts liberally througout our custom C# code.
I saw the power of this approach on Friday, when I ran a manual test and it failed. Instead of spending time turning on tracking, reproducing, scrutinizing logs, etc…, I just went immediately to the event log, where I saw the application exception thrown by the failing contract. Because of the theory of contracts, it was not JUST an obscure message, but something that immediately explained what was wrong.