1 of 2

Write now Article Tools

There is no shortage of confusion when it comes to "redundancy in software." In everyday life, to be redundant is to say or do things that replicate what has already been said or done, often in the same sentence or action. This is generally recognized as worthlessness or unnecessary. Shifting to the world of software engineering, redundancy is typically used to perform what we might call, "back up," or "fail safe" systems, components and or programming. Therefore, it's a matter of knowing some computer lingo and when and where it's used.

We should emphasize, "built in" redundancy in programs must not be confused with "duplicate" software or processes, or say, software loaded in the start up string of your operating system (OS) that you never use. Those are not "redundant," they're worthless. Nor should, built in redundant software be confused with built in adware and spyware. To say they're redundant is to say you only wanted one virus? One last thing. We also cannot mistake this for written errors in code, intentional or otherwise. Remember it was, "built in?" It was intentional and has a purpose.

So just what is built in redundancy and what does it do for us? Well, I know the computer geniuses would rather see this explained with "1s and Os," but we're here to try and make it make sense to the normal brain. Windows and programs approved for Windows use redundancy in various ways. The most common, that we have no reason to try and explain is the cyclic redundancy check or CRC system. Windows systems are also packed with the "dynamic link library" or, DLL files that are full of redundancy code. Many of these are chained (via code) to each other. If and when a file or operation fails, a DLL or system file is called on to search for another, which might call up another, and so on, until the desired code or an undamaged file is found, allowing the system to basically, correct "itself." This is why there are four copies of many system files within Windows. These checks can happen in nanoseconds, seamlessly allowing the program or OS to continue, without you even knowing anything was wrong. Many patches, updates and "new versions" are nothing more then a redundancy program of daisy chained files and code. They interlink with the original "failed" program and make it function the way it was intended.

More and more we find ourselves needing ambitious, self fixing, auto checking and uninterrupted computer services. The more serious the issue that the software is designed for, the more "redundancy" you'll find within it. Systems for Medical, Aeronautics, environmental, military, etc, are jam-packed with redundancy software. Software redundancy is often layered with, or tied into "hardware redundancy systems." Such is the case with servers. The most reliable servers will have layers of software redundancy, along with two or more back up, (redundant) servers, each one ready to take over, in the event one crashes.

Interestingly, the principles of the built in redundant code used today were brainchild's of people's work before the first DOS programming even existed. Before these redundant processes were called "redundant" they had names like back up, error detecting and correcting, fail safe design, etc. Today, built in redundancy uses those names and others, such as "fault tolerant software," "reliability engineering" and more.

Perhaps the most used methods to build in redundancy code today came from a Richard Hamming in the 1950s. His story can be found all over the net, but as it goes, Hamming worked for Bell labs on weekend shifts. The company had the first giant relay-mechanical computer of sorts, that received its tasks by reading holes in "punch cards." Yes, this bloated mechanical nightmare's biggest problem was "hanging" "pregnant" and miss punched "chads." It was literally the size of an entire building and had all the flashing lights, buzzers, recording reels, and levers you might see on a 1950s Sci-Fi flicker show. On the weekdays, operators would watch for the read errors on the cards, and quickly switch the cards to one that was "hopefully" punched correctly.

When employees were off duty the system would pile up with errors and usually crash. Having the place to himself on weekends, Mr. Hamming, well known for hating things that were inefficient, was nauseated by this machine's faults and constant need of human attention. The read errors were so numerous, all he could do was wait for it to overload, shut it down, insert the backup punch cards and restart the system. He was quoted saying something to the effect of, "if this machine can recognize errors and shut itself down, then we should be able to make it fix those errors." Mr. Hamming's determination and brilliance led him to invent two forms of code for that punch card computer that we still use today on our digital file based computers. The Hamming distance and the Hamming code.

Eventually, what Hamming invented was a set of algorithms for programs in the punch card system. We use these same techniques today in that goofy code you see with all the ones and zeros. You can build or check your own Hamming code here. Not only could this method detect the errors, but it could fix them on the Bell labs machine. Hamming code simply used repetitive commands on the card system. He had three systems checking the same processes, hence, the first "built in redundancy programming." It was "hoped" that between the three cards being checked, at least two would always be right. Through an automated voting system, the two matching ones, would be the final process inputted into the machine and Hamming's nightmares of hanging chads were solved.

Hopefully that archaic method shows you the principal reason behind redundancy in programming. We're still doing the same thing today, except ours has been translated from three punch cards being checked, to three or more digitized texts being crossed checked through the advent of DOS and later systems. Hamming's achievements in automated error correcting continue to be taught and used today. Of course, his methods were not the end to this self checking code writing, but there is a lot of similarity

• 1
• 2
• next page >>

Add your voice

Know something about Built-in redundancy in software?
We want to hear your view. Write now!