Some business rules are complex to capture, and codify into an application. Some examples are when there is company policy that is interpreted (hopefully minimally) slightly differently by different parties, or requires complex analysis when the new system "gets it wrong!".

One example I came across was the logic surrounding whether or not a banking loan application falls within an automated decision process or whether it has to be manually assessed. We took three releases to satisfy all the different business stakeholders. Our issue wasn't so much the actual rule coding, but the actual individual circumstance that swayed the rules engine one way or the other given individual interpretation. Our output of true or false didn't give us any understanding (or the end-user) as to why a certain decision was made.

In the second release, I added a right-click menu item to the "Calculate…" button. This menu allows the user (normally under the direction of the help-desk) to perform the calculation AND populate the Windows Clipboard with a small text based diagnostic report detailing the following aspects –

1.   The data it is ACTUALLY using for the decision – in many cases we were incorrectly gathering this data, making our result difficult to predict
2.   A step-by-step progress – Step 1 (Parties over 18 years old) : PASSED, Step 2 … etc…
3.   The date, time and user logged-in
4.   The version numbers of all assemblies and rules loaded

The end-user would then email this to our team as part of an "In My Opinion – You Got it Wrong" bug report. These reports allowed our Business Analysts to quickly isolate an issue, or more commonly a mis-understanding by the end-user as to actual bank policy! We quickly took a major unstable area and by the next version reports were almost zero (at least a 95% decrease in one release).

The key takeaways for me were –

1.   When a feature has many stakeholders, or the feature might be complex to remotely diagnose – consider adding some features to support the help-desk gathering the information you need to improve that feature over time
2.   Building diagnostic reports into the Clipboard was a very low impact way of getting data from end-users, and was easy for the helpdesk to explain
3.   Make the features obscure (although easy for the help-desk staff to tutor end-users). You don't want these features negatively impacting the user experience for normal cases
4.   Consider privacy issues. Only expose underlying data that you actually need. No personally identifiable medical results :-)

Troy.