Divide and botch

A well known software design principle is "Divide and conquer"--the notion that by dividing a large problem into smaller problems will yield a solution where the overall problem might be too hard to solve. This strategy is often combined with recursion. For example, one widely used sorting algorithm is to divide the data to be sorted into two approximately equal pieces, sort each piece, and finally merge the two sorted pieces.

However, sometimes the division doesn't have quite the intended effect. Each individual piece of the problem might be solved correctly, but combining the solutions yields a surprise.

For example, once upon a time my checkbook was stolen. I asked my bank what I should do, and they advised me to close the account and open a new one. If I told them the numbers of the checks that I had written, they would ensure that only those checks would clear; any other checks written on the old account would go to the police.

So I closed my account and opened a new one, and never encountered any attempts at fradulent check-writing. I did, however, get a nasty surprise when my next payday rolled around: The automatic deposits that had been reaching my old checking acccount were now vanishing into thin air.

The reason was obvious in retrospect: Whoever designed the banking system realized that it was important to deal with withdrawals from closed accounts, but forgot to do anything about deposits into closed accounts. Fortunately, I was able to tell the people at the bank the exact date and amount of the missing deposit, because they had to go through the deposit information by hand to find the transaction to move.

I haven't seen a good term for such design mishaps, so I've taken to calling them "divide and botch." Perhaps some readers can suggest a better term.

Posted by Andrew Koenig at 10:00 AM  Permalink