Two Corinthians and Trump

Some online commentators are sniggering at Trump for reading “2 Corinthians 3:17” as “Two Corinthians three seventeen”, instead of the more formal and conventional way of saying it as “Second Corinthians three seventeen”.

https://www.youtube.com/watch?v=8EIgHsGZAmk

Krauthammer says of Trump: “ …thereby betraying a risible lack of familiarity with biblical language and usage.”

Except that “2 Corinthians”, whether you read it as “Two” or “Second” is not biblical language. Not one person in the Bible refers to this book by the name it’s now known. The title “2 Corinthians” was given outside of the Bible; we probably don’t even know who first coined it and when. 

It’s genuinely easy for people to refer to it as “Two Corinthians” because it is written as “2 Corinthians” rather than “2nd Corinthians”  But it’s such a minor gaffe, I don’t even think it merits criticism. Certainly it’s not ‘wrong’. (Although it’s very clear from the video Trump was not at all, or no longer is, familiar with reading scripture)

I bet many people refer to those books that have numbers in front of their names as “Two Chronicles”, or “Two Kings”, especially in informal settings.  I know I do, even though I am familiar enough and interested enough to have learned to read Koine Greek at some point.

Two Lions (Humour)

Two aging, hungry lions spot a zebra.  One of them starts putting on his Nikes.  The other asked, “What are you doing?  Even with running shoes on, you can’t outrun that zebra!”  The other replied, “I don’t have to outrun the zebra, I just have to outrun you!”

Creative CV

Came across this very creative CV on LinkedIn.  It’s a great reminder that a CV is a marketing tool. It’s not an epitaph, or a chronicle.

Here’s a link to the original higher resolution image: Link.

Verification (and Validation) is a Waste of Time

Verification adds no value and should be eliminated from the system life-cycle.

From the point of view of quality control, verification (and to a lesser extent, validation), is no different to inspection.  Anyone who has taken to heart Deming’s teachings on the quality understand that inspection does not produce quality; it can only detect problems (and only some of the problems), but can neither prevent them nor fix them.

Deming on Inspection

“Inspection does not improve the quality, nor guarantee quality. Inspection is too late. The quality, good or bad, is already in the product. As Harold F. Dodge said, “You can not inspect quality into a product.”

What is Verification?

Verification is the act of inspecting an artefact to confirm that it meets the conditions it is subject to.  For a manufactured products, this means it meets dimensional specifications, for example. In the case of a set of requirements, verification is about confirming that the requirements faithfully and completely address the agreed needs from which they were derived.  That is, if the requirements are fully implemented, they would resolve the problems stated in the needs.

(Lou Wheatcraft extends the definition of verification to include assessing the requirements against policies on how to write requirements, but the distinction is not relevant for this post).

Why is Verification a Waste of Time?

Whatever the scope of verification is, it’s about taking the artefact that is the set of requirements, and comparing it against the source from which they were transformed, in this case, the stakeholder needs.  If a discrepancy is found, then a different set of activities (not verification) is taken to fix the problem.  Verification DOES NOT transform the set of requirements.  According to the principles of lean, any activity that does not transform the product can be considered a waste that should be removed if possible.

Why do we need to perform Verification?

If it’s a waste of time, why do it?  The primary reason is because the methods and procedures we use to transform the set of needs into the set of requirements is imperfect; it provides us no guarantee that the transformation is complete. 

Think of that transformation as the function F(). We can model F() as:

F(N1, N2, N3, … Nn) = Ra, Rb, Rc, … Rz

where the set of R’s is the perfect set of requirements required to satisfy the set of needs (the N’s). If F() was perfect, and could be executed perfectly, we would not need to perform verification of this transformation.  The R’s we get perfectly deliver the set of needs N.

However, the resulting set of R’s is seldom perfect, because of two reasons:

1. We do not have a function F() that can produce it perfectly

2. Whatever imperfect versions of F() we have, we do  not execute it perfectly.

Therefore, we need to inspect the result (but what is that method we use to inspect and find the gaps? Could we not have used that in the transformation? No, because it’s not perfect either)

To further illustrate, when were taught how to do long division, we were also taught how to verify the results.  To divide 27 by 3, we execute the long division process to get the result:

F_division (27 / 3) = 9

To verify that the resulting output (‘9’) is a correct transformation, we use another function F_multiplication():

F_multiplication(9 * 3) = 27

If F_multiplication() results in a number that do not confirm the results of F_division(), we review the execution of the function, not the function itself.

Until we have a similar function or process or algorithm to transform needs into requirements, we are forced to do verification.  We can continue to look for ways to become more and more efficient in this waste activity, but we should attempt to keep improving the transformation function so we do less and less verification

Why do we need a WBS?

What is the use of a Work Breakdown Structure? There are several uses, but the main one is to let you break up and structure the project into smaller, ‘bite-size’ pieces.

Each of those pieces is a mini-project. You can apply project management principles to each of them.  Apply cost management, scope management, schedule management to each one. And because they are smaller projects, they will be easier to manage.

You can even delegate the management of each mini-project to a mini-project manager. Just remember that each little project is subject to its own constraints of scope, cost, and time, and therefore will focus on its own constraints, not on the constraints of the whole project. This is where integration management (the science of herding cats) is important.

Q: What’s the difference between a sceptic and a cynic?

A: I doubt there's any difference. Even if there is, I'm not gonna tell you what I think; you'll just make fun of me.

Should non-function requirements testing be done only for peak load?

There are some who argue that testing of non-function requirements (NFRs)  should only be performed at peak loads; positing that testing them at less than peak loads is a waste of time.  The argument goes that if the solution cannot meet the peak load requirements, then it is unsuitable anyway, so what’s the point of testing at less than peak loads? Implicit in the argument is that if it performs as required at peak load, then it will perform as required at normal load.

First, let’s investigate the assertion that if the NFRs do not meet their peak load specifications, then the solution is not of use to the organisation.

What does peak load mean?

In order to do this, we need to define what we mean by ‘peak load’. A peak, by definition, is the summit, the highest point, a singularity.  In the stock market, the price of a share fluctuates. One of those prices is the highest for that day. That is the peak (the ‘high’ for that day).  There are also highs for the current year, high on a year-on-year basis, and an all-time high. 

Do we mean that testing should be performed only for the very highest possible transaction? If so, what is that very highest possible transaction?  Is it the maximum that the solution is rated for?  This could well be something that occurs as a 1 in 25 year event.

In addition, does peak load refer to the peak volume that the environment is expected to provide or the peak volume that the solution is specified to handle. Suppose we are talking about concurrent users of a website. If the organisation has 20 million customers, a theoretical peak load might be all those customers simulatenously accessing the website.  Another theoretical peak might be the website being subjected to a denial of service attack.

The other peak load is the volume that the system is rated to meet. Suppose we decide that the maximum is 3 million concurrent users.  Do we then test the system for 3 million concurrent users or 20 million concurrent users?

Peak loads can occur once every 10 years

Depending on what definition of peak load was used, its occurence may happen so rarely and only for such a short time that it doesn’t matter.  Suppose the peak load happens only for half an hour on the 1st of January each year. If we tested only for that, then we are not testing the behaviour of the system 99.99% of the its time.

Perhaps by peak load, rather than a single point we want to use a percentile.  Say, the top 5% of the expected load.

What about the specifications for average loads?

Most requirements specifications dictate the performance required from the system at average loads, and also at heavier loads. Without testing for average loads, how would we verify that the solution has met the specification?  If we will not test at average loads, what’s the point of specifying performance for that? The solution may be performing as sluggishly at average loads as with peak loads – we wouldn’t know.

NFRs is not just about volume

Many  NFRs have nothing to do with volume transaction but will also have their analog to a peak concept.  Consider usability. Usability might cater to extremes, like being usable to a colour-blind person, or someone who cannot use a mouse.  Shall we test only those extremes with the argument that if it works well there, it works well for the average case? Of course not.  Think also about the extremes for maintainability, accessibility, availability, security, portability, and so on.

Conclusion

NFRs should be tested against all specification. If we specified performance at average levels, the requirements should be verified at average levels.