Qualities Patterns Share: Avoiding Redundancy

Redundancy can be a good thing if we are referring to a backup for safety, like the systems on a spacecraft. I don't mean that kind of redundancy. I am referring instead to an element of the system that is repeated needlessly in such a way that altering it will require the same change to be performed multiple times.

A good example of making such a mistake is the Y2K bug. Remediating for the Y2K situation was not expensive because changing from a two-digit date to a four-digit date is inherently difficult. It was expensive because we had to make that same change millions of times. We knew it would be easy to miss some, and so we had to proceed very slowly and methodically. Y2K remediation produced little or no business value, but cost billions of dollars.

This bug was created at a time when the expensive part of automating something was the hardware. Memory, disk space, and computing cycles were all very costly and also very limited in terms of what was even possible. The human programmer was seen as a fairly trivial expense.

Today, this equation is reversed. Developers are expensive, but computer hardware is cheap and getting cheaper all the time. Redundancies cost more in developer time.

Any change should be able to be made in a single place. The patterns will help us to enforce this in various ways, as we shall see.