C++, concepts, ADL and philosophy

A conical shaped article (approximately 40 cm high), made by sewing 2 nonwoven triangle shaped panels of red textile material together, with an applied trim of white colour at the base, and a white bobble at the top. The object in question was to be classified under CN code 6505 00 90 as 'headgear', and not under subheading 9505 10 90 as 'other articles for Christmas festivities', because textile articles that have a utilitarian function are excluded from Chapter 95, even when they have a festive design.

-- Santa Clause hat as described in an official EU document

While reading a philosophy book I suddenly realised that C++ ADL (Argument Dependent Lookup also called Koenig's lookup principle) is, surprisingly, aligned with Aristotle's way of viewing the world.

Concepts have been analysed ever since Plato and Aristotle. Plato believed that everything on this earth was a copy, even though imperfect, of a perfect exemplar in the world of ideas.

Aristotle came along and stated that everything had essential properties as well as accidental properties. Essential properties were, well, essential for the thing to be classified as just that thing. Accidental properties on the other hand could vary within a group of things having the same essential properties.

Now I'll stretch the terminology a little. By properties I don’t simply mean structural properties but also behavioural properties. So when viewing classes as models of concepts C++ supports the idea of accidental properties through ADL. Functions deemed not to be part of the class proper, but still considered part of the class interface, can be defined outside the class but within the same namespace in which the class lives. Modelling accidental properties through ADL is a good thing since it promotes loose coupling between classes and accidental properties.

Not bad for C++ to align with old Greek philosophy!

Doing the right job right

Logic is indifferent to truth. The goal of logic is to root out inconsistent beliefs and generate new beliefs consistent with the original set. Logic does not consider whether our beliefs are true. A logical person can be wrong in everything she or he believes and still be consistent

-- Gary Klein, Sources of Power

In June 1996 the Ariane rocket exploded when a piece of software was doing the job right for which it was designed but it was not doing the right job.

For many years I viewed this as an interesting theoretical anomaly. My reasoning was that software bugs were, well, just software bugs. No one in their right mind I thought would install a piece of software which was designed to do task A in a context where it would have to do task B for which it was not designed.

Well, over the years I have realized that the scenario is not too uncommon. I got my fair share of it some time ago. Functional requirements were formulated by the business side and given to the IT department. I designed, implemented and tested the requirements and the software was deployed in production.

The software did exactly what the requirements stated except for a few minor bugs which were quickly taken care of. There was one slight problem though. The users of the software started to complain about the results produced by the software. In fact, it was clear that the results produced by the software were way off from results that had previously been calculated manually.

After management got knowledge of the botched project emails blaming the software department started flying around. After investigating it has been determined that the implementation is at fault was just one out of many blatant lies where the business side of the operation tried to cover their asses.

Even though it was unpleasant to be blamed for something that had its roots in functional requirements and over which I had no control it was interesting when seen from the perspective of analysing problems in software systems. It was also rather comical to read emails where the business side blatantly contradicted themselves by stating that a new set of functional requirements will correct the problem. But hey, wasn't it the implementation that was bad :-)

Here, I had built a piece of software designed and implemented to do a specific job. In some context in a different Universe maybe the functional requirements on which the software was based would have made sense. However, unfortunately, the requirements were completely wrong for the context in which the software was used. In other words, the software was doing the job right but was not doing the right job.

Two terms come to my mind here. The first is validation and the second is verification.

Validation is the term used when checking that something is doing the right job. Validation should, and must be applied at the business level when writing functional requirements. Unfortunately the idea of validating functional requirements is more than often unheard of when talking to business persons and functional analysts. It is critical, as is clear from the project I mentioned, that functional requirements are validated before dropping them into the IT department.

Verification is the term used when checking that the software is doing the job right. As an IT developer verification of software is manifested in various testing procedures against functional requirements. As is common in large IT environments, IT developers such as me don’t have much sway over functional requirements which is just as it should be.

As a side note, after implementing the new functional requirements I was asked to provide the functional people with procedures for how they should test their own requirements! This confirmed my suspicion that the original – and maybe also the new – requirements were not understood even by a long shot by the functional analysts.

When time allows I'll write a short entry touching on how to handle both technical and functional errors in mission critical system.