Bad system design -- Overspecification of Data.

The key principles behind Architecture and technical drawing rules can and do apply to computer science and programing. One key item is "Over-specification". It is one of the main items that I find in;

• Poorly written or adhoc designed software
• In software that has been in long term maintenance without purging rewrites
• or in software produced by coders under constant(and often pointless) deadlines.

Here is what it is and why its evil.

Consider a Line with a point on it. Here are 2 classes defining it.

struct Good
{
  int length;
  int pointFromLeft;
};

struct Bad
{
  int length;
  int pointFromLeft;
  int pointFromRight;
};

So why is the Bad struct a no-no. Simple!. There is an implicate relationship between the data entries. "length = pointFromLeft + pointFromRight". If something updates the length and forgets to update one of the pointForm entries, then you end up with the data in an invalid state. This will later cause computation errors and finding the cause of the incorrect data is often quite difficult, because the code with will often look legitimate..

Furthermore the problem often isn't so simple to see/fix either. Consider this set of classes defining the same thing.

class GoodLineWithPoint
{
private:
  GoodPoint* point;
  int length;
};

class GoodPoint
}
private:
  int pointFromLeft;
}

class BadLineWithPoint
{
private:
  BadPoint* point;
  int length;
};

class BadPoint
}
private:
  int pointFromLeft;
  int pointFromRight;
}

In this case someone may have added the pointFromRight member so that they can "cache" the result. In reality the parent class GoodLineWithPoint should be the one that is dealt with however a function call might be passing GoodPoint to save the additional pointer deference. And once this is established in an API or lib it becomes quite difficult to fix cleanly.