API Network Corp

Software reliability

The non-IT person's conception of a software product (Joomla or any other CMS) is very simple: once the software can run correctly, it will do it forever.  The initial logic the system was built upon, if determined to be correct today, it will invariably be correct tomorrow. Even if a physical presence that powers your system, software never ages or erodes.

Here are some details that one should consider before adopting such an optimistic view:

The logic of the system may be unmistakable, but the hardware on which it runs may encounter real problems. These will draw the necessity to intimately master the functionality and requirements of the software too.  Systems can and will become obsolete. The need for additions or improvements turns into periodic concerns. Some simple changes in some lines of codes can bring about disasters if the system internal relationships are not clearly documented and known.

Software is built on human logic.   Human logic is prone to errors, so is your system.

Bugs are the flu of software - nothing to alter the general functionality of the system, but, due to their cumulative consequences, dangerous if not treated in time.  Some of them are visible only after the system has been long into production, but they will invariably be there. Remember that NO complex system is safe from bugs.

Joomla-based systems can be very complex. The final product is always the culmination of many different solutions provided by many different people.  It is to be remembered that, like all products of human creation, a software system can take an infinite number of paths. The decisions that are made every day by the developers are based on reasons that, if undocumented, will be lost, and not even remembered by the ones that created the system.

Such a situation is perfect for costly repetitions of the same mistakes.

Joomla and all source code is essentially the written form of this logic - nothing more, nothing less.   Ignoring the documenting of the rationale behind it is as dangerous as your software developers leaving after the system was built.

Proper documentation is your back up in case of need for little improvements or in the case of altered system functionality. Most people would never think of going on without a medical insurance, but they may be comfortable with creating software without proper documentation. Chances are the system will break ten times before their creators will ever have to deal with their kidney stones.

A look to a series of tragedies caused by software should give you an idea about how wise it is to rethink the idea of the software 100% reliability:

• Tragedies in Therac 25, a computer-controlled radiation-therapy machine in the year 1986, caused by the software not being able to detect a race condition, and that killed six people, alerts us that software bugs can have serious ramifications.

• Software can make decisions, but can just as unreliably as human beings. The British destroyer Sheffield was sunk because the radar system identified an incoming missile as "friendly".

• Software can also have small unnoticeable errors or drifts that can culminate into a disaster. On February 25, 1991, during the Gulf War, a chopping error that missed 0.000000095 second in precision in every 10th of a second, accumulating for 100 hours, made the Patriot missile fail to intercept a scud resulting in the loss of 28 lives.

So what does documentation have to do with software reliability?

Everything. No part of a logically built system can be altered without a clear knowledge of how the system works as a whole and the relationships at work within it.   It is simply impossible to effectively manage debugging or converting/upgradding a complex system without such very specific knowledge.

It is a lonely and unpleasant experience to maintain systems written by others in the absence of such documents, and few are the ones that are both willing and able to do it.