An Example of Accidents of Implementation
As I have mentioned before, I recently read The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt and David Thomas. In the section on “Programming by Coincidence” I was reminded of a bug I found, it was fixed and it broke a customer’s implementation.
The product was a set of tools, services and application servers that a client could use to automate some processes in a particular vertical industry. As part of the product, there was a full programming language. I came on board to build the test team. As we moved forward with new functionality, we slowly worked through the functionality which had never been formally tested before. When we started testing the date arithmetic functionality, we found quite a few errors.
One of these errors was the “add” function would accept blatantly invalid dates. When this error was fixed, we verified and moved on. It ends up that the biggest customer used the “accident of implementation” of the add function to determine whether the current year was a leap year or not. They would add the date “February 30” for the current year with the value 0. The system before the fix would return the last day of February (28 or 29 depending if it was a leap year or not) for the year in question. After the fix, the system would return an error. (Sometime before this bug was fixed, an isLeapYear function had been added to the system but that was after the customer implemented this code.) The customer’s developers had used this accident of implementation for some crucial logic in their application. This behavior was not documented – someone had “discovered” it.
1 Comment