What About Sub-standard Software Systems

Like any incurable disease it (software) attracts more quarks, magicians and fortune tellers – -E.W. Dijkstra

In the past five years, I have come to think that it is valuable for the general public to know the distinction between a good computer system and a bad one, especially that the consequences affect even the innocent. Perhaps you have been to the bank and a teller casually announces that you can not withdraw or deposit money because the system is ‘down’, or you can not access your academic transcript because the system is ‘unavailable’. Maybe you have ever missed salary because of the computer system! Failure to withdraw your money may mean the landlord evicts you from the house or your son misses school. Failure to get the transcript may mean a missed life-time opportunity.

Such systems lead to wastage of millions of money, put lives at stake and businesses on the mercy of quarks. For government, the security of nation can be put at stake. The more computer systems fail, the more it becomes incurable because the general public has come to believe that it normal for systems to usually fail

A comparison with civil works

A comparison between the engineering of computer systems and civil engineering is informative. Unlike civil works, where the effects of a rudimentary engineering or lack of it are there to see through collapsing buildings, eroded fences and roadworks that are often fatal and lead to deaths, the effects of a rudimentary computer system are not readily visible. Mechanical engineers can get away with approximations for unknown or incalculable effects, substandard materials, and other surprises by building in safety margins. However, in software systems a single bit error can have disastrous consequences. Despite the the invisible nature of immeidate impacts of ill designed computer systems, the consequences  go beyond what most can predict and can be as fatal as a collapsing building with occupants.

Unlike civil works that may be faced with fake construction materials (such as cemment in Uganda), the key players in the construction of software systems are the programmers and those that buy the software. So the quality of the software is enitely in the hands of programmers.

Now warrant not guarantee -“as is”

 Interestingly, computer scientists mastered in advance, the art of hiding their incompetencies. They use fancy terms such as bugs to describe what ordinary means a malfunction. That is, a system that can not correctly do what it was intended to do. They do not even want to take responsibility of their own actions. Most software systems provide no guarantee or warrant for even the very mission the system is supposed to achieve.

The public has also accepted this situation and with not regret, it is not is common to hear  with a smile  that the computer system is not working, or the computer system is unavailable. Such lame explanations that have made system failure synonymous with the computing discipline are hurting. Such systems should not be casually accepted and need to be questioned for evidence of rigorous software engineering in the design and construction.

Good software is supposed to be reliable

Like any tool, a good software system is supposed to be reliable, that is safe to use by virtue of the fact that, when used, it acts as intended, or, more precisely, it reacts upon our inputs as intended. Even before subjecting a software system to a rigorous check for suitability of purpose, some indicator of incomplete and poor workmanship are usually there for even the computer illiterate to see. The first systems to be dismissed with contempt are those that fail due to any user inputs or limit existing good manual practices. That is, start by entering any data and good system should continue to behave normally. Bad systems will fail. Such systems are a clear manifestation of inept software engineering where the system is erected prematurely.

The buyer  at fault 

Executives, procurement officers should be aware that any programmer of some intelligence can cook up a computer system, the properties of which are utterly unattractive and unrelated to anything else. They need to be aware that the construction of computer systems is not a chaotic process with out systematic means to evaluate and sort them.

The executive managers with no formal training in software engineering approve these systems on the basis of their computer literacy normally in typing skills and email forwarding. Simple clicks and intelligent animations are usually enough to   append their signatures on products that are an art of ingenious and intelligent computer quarks.

Software production is a systematic process and quality can be assured

The most important aspect of a software-based system lie in the modeling and analysis of its interactions with external factors and overall mission assurance. Before purchasing or accepting to use a software system, it must be checked for for system-level information assurance issues. It must be checked for Possible fail-stop mechanisms and procedures, fallback, contingency solutions for both direct and secondary effects of failure modes. And Usage scenarios are frequently not a priori limited.

The regular failure and unavailability of computer systems has convinced the general public that it is normal for computer systems to fail. The proliferation of poor systems is a making of buyers who are easilty decieved by self made computer experts. As Edgar Dijkstra put it, Like any incurable disease it (software) attracts more quarks, magicians and fortune tellers

2,443 total views, 1 views today

One thought on “What About Sub-standard Software Systems

  1. The standard provides a framework for organizations to define a quality model for a software product. On doing so, however, it leaves up to each organization the task of specifying precisely its own model. This may be done, for example, by specifying target values for quality metrics which evaluates the degree of presence of quality attributes.

Leave a Reply

Your email address will not be published. Required fields are marked *