DevDisasters
The Daily Fix
Software development gone wrong.
"We're in a bit of a jam," read an e-mail to the support desk. "We accidentally ran an entire day's worth of transactions for Oct. 11, 2009, instead of Oct. 11, 2006. Can you fix this?"
In the world of retail, it's not an uncommon practice to "open" for a business date that is not the current date. Think of 24-hour stores that want to "close" the day at 11:00 p.m. instead of midnight, or the cases when the registers are out of commission. Whatever the reason, it's a feature that retail vendors want and a feature that T. Ferguson's company provided in their point-of-sale (POS) systems.
Obviously, there's no way for software to know if a different date is purposeful or accidental; all it can do is default the "open" date to the current date and hope that someone will notice a mistake on the registers, receipts and so forth before the day is closed out. The e-mail to the support desk was the first problem that Ferguson's company had with this feature since first offering it 15 years ago.
Despite having a nationwide chain of stores-with each bringing in nearly $500,000 a day in sales-this retailer decided not to go for the extended-hours support contract. With no one to call at 9:30 p.m. for support, the shift manager ignored the incorrect date and closed out the store's POS system. He left a note for the general manager, who promptly e-mailed support the next morning.
The general manager also called the support line at 9:01 a.m. -- just after it opened -- to make sure the support desk received the e-mail. He was extremely concerned that the error would gravely impact their October reports, forecasting reports, inventory and just about anything else that relied on that day's transactional data. The support rep assured the general manager that the dev team was working on a way to fix the issue.
UPDATE Script
From a programming perspective, this was actually an easy issue to fix. All of the daily transactions were stored in a single database table, so a simple UPDATE script and a "re-close" would do the trick. They reproduced the "problem" on a test machine, ran the fix script and watched it work like a charm. Ferguson called up the store to let the manager know how they planned to resolve the issue.
"But," the manager asked, "what about when someone makes a return? Their printed receipt will have a different transaction date. Won't the register refuse the return?"
"Nope," Ferguson replied, "we only use the store number, register number and transaction number when we validate the receipts for returns."
"Sounds great," the manager said in a much less stressed tone. "What a relief! I was really worried about how bad this would be."
Erasing History
Tell Us Your Tale
Each issue Alex Papadimoulis, publisher of the popular Web site The Daily WTF, recounts first-person tales of software development gone terribly wrong. Have you experienced the darker side of development? We want to publish your story. Send us your 300- to 600-word tale -- if we print it, you'll win $100 and an RDN T-shirt! E-mail your story to Senior Editor Kathleen Richards at krichards@1105media.com and use "DevDisasters" as the subject line. |
The UPDATE script was sent to a technician to fix the problem on-site. Before running the script, he noticed one thing that the development team missed: not only was there just one day of faulty data in the database, there was just one day-period. All the transactional history was gone!
That, of course, would be a problem when the retailer was trying to process a return, or receiving merchandise that was ordered in the past, or verifying an employee's time clock punches, or tracking special-order items, or knowing whether the store was on pace to meet its weekly sales goal or attempting just about any activity of any consequence in retail that wasn't selling merchandise.
The technician reported this back to the dev team. After a bit of digging, they figured out why only the one day of data was left: part of the register-closing code purged data that was more than three years old. And how did one find 3-year-old data when the system clock was not a reliable indicator? Why, by taking the business date of the newest transaction and subtracting three years, of course!
Needless to say, the manager's day would get much, much worse ...
About the Author
Alex Papadimoulis is a managing partner at Inedo LLC and publisher of the Web site "Worse Than Failure" (WorseThanFailure.com). He writes the DevDisasters page in every issue of Redmond Developer News.