Trapdoor In The Sun

Alan Shanahan, Technician & Consultant

Monthly Archives: November 2012


by 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.

Advertisement


by 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.


by Leave a comment

Another Feather In Your Cap

What if, as a consultancy organisation or Systems Integrator (SI), you decide to take on a new partner’s technology? You decide that it will fill a product gap and make your offering that much more complete and attractive to buyers. Is it that simple?

You need to garner the knowledge necessary to promote yourself as an expert in their product. You need the implementation experience and the “battle scars” so many execs and salespeople like to talk about. And, above all, you need to understand the product to such a degree that you know where it “stops”, and where the customising process begins. Then, just to push it all over the edge, you need product knowledge to such a degree that you are in a position to design the optimal solution for the customer’s needs AND to offer best-practice recommendations.

For new products, where you are at the bleeding edge, I would settle for Relevant Experience, coupled with adequate training. Early Adopter clients, or “friendly customers” can make life a lot easier too, especially where everyone is venturing together into the unknown. The brave customer can benefit from a wallet-friendly implementation (knowing full well that everyone is on a steep learning curve) and the implementor can gain the much-needed experience in a safe environment, whilst the product company and SI get a valuable reference site. If you’re in the win-counting business, I make it three.

And then you have a new string to your bow.

Or the SI can invest a huge amount of time and money on education, prototyping, product testing, sales and marketing but all without the benefit of customer feedback, testimonials and real-world use cases. And don’t forget the most important thing – experience.


by 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.


by Leave a comment

Update: New Salesforce.com function to provide 18-char IDs

I blogged in the past on the subject of Salesforce.com IDs: click here to see it.

The wonderful thing is that SFDC were listening! Not just to me, but I was a voice in the crowd. They responded in the Spring ’12 release with a new function to be used in formula fields:

Syntax example: CASESAFEID(Id)

Official documentation link: http://login.salesforce.com/help/doc/en/customize_functions_a_h.htm#CASESAFEID

It’s that simple. Just set up a new custom field with this as the formula and use it in your reports.

 

[Note: SFDC = SalesForceDotCom]


by Leave a comment

Developer Maturity

Thirty-odd years ago, I wrote my first lines of BASIC code on an Apple II computer donated to my secondary school by some local businesses. We were the first of our school and, to some degree, our generation to have access to such a device. I was hooked from the word go. All these years and a few dozen jobs later, I can tell you I’ve seen the full spectrum of good and bad in the world of programming; I may even have contributed to the bad side, but I live in hope that most of what I produced was leaning towards the better side of things.

But I can see definite steps in my progression in those intervening years; let me focus on programming itself, or “development” as the industry likes to call it. Today, I have a very different mindset to that of my teen years. My young naive self revelled in the idea that you could type an arbitrary set of instructions into a machine and it could do the most marvellous things. Coding was an end in itself! It existed just so that beautiful programs could be written and run. I had a lot to learn.

Then I started working in the real world. My programs were now being used by real people, in a real business, every day. There was a huge amount of job satisfaction in that idea. Everything changed. My “hobby” was now something to take seriously and it had to perform to a new standard. But I didn’t fully realise that and I still saw programming as an isolated pursuit with its own intrinsic value; in my mind it was a primary activity with its own purpose rather than an enabler. This illustrated an immaturity in terms of my business viewpoint.

Many years later, I’ve managed programmers and development teams. Still doing that. I’ve designing solutions for customers that are implemented by these teams. I’ve seen and reviewed a lot of code. In that sea of code, the full spectrum of quality exists. Some bad practices can have a subjective slant to them, but other bad practices are just plain bad. I’ll tackle the subject of quality later, it’s just too big to even contemplate here. But one point on quality is worth reiterating here and now: quality is everyone’s responsibility. I won’t explain that further, I believe the words do that for themselves. You own quality. You own problems created by your programs, no matter how trivial. At least to some extent. You owe it to your team to properly ring fence and test scenarios your programs are supposed to handle. You owe it to the customers who are paying for your development efforts.

And what I have seen is a set of behaviour patterns that seem to be repeating.

Firstly, there is an obvious disconnect between some programmers and the end user they are programming for. Think about users. Someone will sit in front of a screen and use your programs. They are real people, no matter how distant they are, or how imaginary they seem.

Another misalignment I’ve seen is that some programmers don’t conceive that data represents real world things. Financial data represents money, real money, not imaginary money. This is important to customers. It’s their money, the life blood of their business, which would simply curl up and die without it.

Polish! Polish your code. Polish the user interface. Try to break your programs. Keep trying until they no longer break.

Open your mind. Let go. Don’t be afraid to rework what you’ve written. The best writers and authors do this regularly; that’s why they’re the best. Coding is not an end in itself, it’s a means to an end: the business aim is the end. Code is just an enabler.

Do these things…

…and you’ll be all grown up.

[Note: I’ve emphasised “some programmers” in this piece. I’ve worked and continue to work with many superb developers. It’s worth mentioning.]


by 1 Comment

TLAs In Technology

This post is something of a gripe.

Question: how many times have you Googled the TLA (three-letter-acronym) the instructor/speaker/salesperson/techie just dropped into the discussion? But also made sure nobody was aware of your “ignorance”?

I think I know the answer to that.

So this post is really a plea to anyone out there with a penchant for acronyms to please consider your audience.

If it’s in writing or on-screen, please provide footnotes or a glossary of terms. If you’re speaking, explain your TLAs when they are first used (but not in a condescending way). And, as a catch-all, encourage your audience to question your use of TLAs at the start of the session, because we all have different viewpoints.

TTFN