Trapdoor In The Sun

Alan Shanahan, Technician & Consultant


1 Comment

Auditable Programming

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.


Leave a comment

Techie Poll: Code Comments Misspellings & Bad Grammar

As a picky, petty pedant, this is a topic near and dear to me. The question also applies to field names, method and class names and any other symbolic placeholder names in program code.

Question: “What do you think of misspellings and bad grammar in code comments, field names, method and class names?

Your comments are welcome, as always. It doesn’t have to stop at a poll, it’s worthy of discussion.


Leave a comment

Wild Goose Chase

This is an argument in favour of refactoring code to prevent duplication. It’s a real example that happened in the last couple of years and demonstrates an important point.

In our example, one code function existed in four separate places in the same code suite.

At some point later, a business functional change meant that a code change was required. The change was made, but only in one of those four places. The testing that followed was significant because the change was made to code that formed part of some core business functions. Errors were found in testing, it’s fairly obvious why. [For those not paying attention, the change needed to be made in three other places.]

Now, because we didn’t know the code too well, it was a reasonable assumption that one possible cause for the errors was code version regression. Something was askew in the version control department, or so we assumed. Much time was spent investigating this as the root cause. It was a wild goose chase.

It’s a classic example of why quality belongs to developers. Amongst others.