Poor Design Can Make Good Software Bad

The worst kind of bug is one that was developed into a software application by design.  To better illustrate what I am talking about, take this example from worsethanfailure.com:

As the recent father of twin babies, Philip B. was relieved to learn that his employer’s benefit provider, Sun Life Canada, made the insurance process really simple. Adding the little ones on the plan required no more than a phone call to provide birth dates, names, and that sort of thing. All seemed so easy, until the customer service rep realized what Philip was trying to do: “I’m sorry sir, but we need a different birth date for each of your kids.”

“Uhh, er,” Philip stuttered, rather puzzled, “they’re twins? They were both born on the seventh of May, so they actually do have the same birth date.”

“Oh yes, I understand,” she said, “but our system cannot handle two people with the same last name born in the same month of the same year on the same plan.”

Wow.  I have seen a lot of bad design decisions in my career, but this is probably one of the worst.  Not just because it is an obviously huge oversight of a fairly common occurrence (the natural twin rate is around 1 in 80 births), but also, and possibly more importantly, because this error was introduced in the design or architecture phase of the application.  As worsethanfailure.com goes on to report, a new version of the insurance software was installed that tracked each person’s budget based on their last name, plan number, and month/year of birth. Hence, having two people born in the same month and year on one plan would cause all claims to be booked against one of the two’s budget, risking a premature budget exhaustion.

I don’t know what circumstances played a part in the design of the software, but I do know that it was absolutely doomed from the very beginning.  It doesn’t matter how eloquently or efficiently the actual code was developed.  This application was simply going to fail.  And because the error was made at a level that was likely ingrained across every layer of the application, the entire application will probably have to be scrapped and redone.  In this case, bad design has proven itself to be much more costly than bad code.