Developers use debugging tools to look at the internal workings of their creations every day. One of the most useful debugging function is the ability to peer inside the contents of variables at strategic points in a program’s execution to see whether it’s behaving as expected. This is the use of a technical tool for a technical purpose. But why couldn’t we use that same concept to build better software; to give end users a peek inside the internals of the programs we write?

In the case of a complex set of calculations or decisions, this can really reap benefits. Let’s take the example of a custom discount calculation, and assume the following:

• There are 5 different discounts that can apply to a customer order
• Some discounts are mutually-exclusive
• All discounts have limits that will be applied if appropriate
• All conditions have a specific set of conditions that determine whether they are applicable
• Some discounts require approval from a senior manager
• Discounts above predefined threshold amounts and order percentages require approval
• Some products do not qualify for discounts
• Discounts can arise from a customer account, at order level or at product level

Looking at this list of preconditions, or business rules, it’s not hard to see that the internal workings of a discount calculation program can be quite complex. Consider also that you, as a developer, will need to write the code to implement these rules. You will have to debug the code and test it thoroughly. You will also have to gain customer acceptance that he is satisfied that everything works.

How can you make that last thing easier to achieve? By letting the end user peer inside the process through all stages. Let’s break this down further.

All programmed components have three simple components: input, process and output. The input to a process might be the customer record, with its associated 12.5% discount field. Another input would be a product line on an order, and its associated total amount field. The processing would be a multiplication of the line total by the discount percentage, but there might also be a decision point whereby the program checks that the product allows discount; the “Allow Discount” flag on the product would, therefore, be another input. And the output would simply be the amount of discount.

Now, let’s say we created a large text field on the order that we would use to accumulate text output to give the end user the visibility I mentioned earlier, for example:

Customer Information:
---------------------
Account "Smith And Sons" qualifies for a 12.5% on all applicable products.
Sales Discount of EUR 100.00 has been applied to this order by User: John Smith

------------
Order Lines:
------------
Processing line 1 of the order:
Product Code "ABC123", Description "Widget 123", discount IS applicable.
Order Line Total is EUR 2,500.00, Discount is EUR 312.50, Discounted Line Total is EUR 2,187.50

Processing line 2 of the order:
Product Code "XYZ001", Description "Widget 001", discount IS NOT applicable.
Order Line Total is EUR 5,000.00

--------------
Order Summary:
--------------
Order List Price Total is EUR 7,500.00
Total Order Discount Amount is EUR 412.50

----------
Approvals:
----------
Sales Discount is below the threshold level of 10% of the Order List Price Total. No approval is required.
Total Order Discount is 18.18% of Order List Price Total. Approval required because this exceeds the threshold value of 16%.

The key point to take from this is the enormous value that this text brings to the application, especially to the end user. It is valuable to anyone testing the application too, because it really is a debugging log; but it is presented in a plain-English manner.

This strategy will not hurt you when it comes to quality. Bottom line, it’s about programming for the user, not for the programmer.