I guess it could be worse . . .

In the glamorous, high-tech, fast-paced world of technical writing, we sometimes run into situations where we have to document around software or hardware problems. It's the sort of thing that marketing might try, in the sense of redefining a bug as a "feature". But it could be much worse, if you're developing custom software for a client:

[The client] would buy new hardware and software, but it had to look and function exactly like the old systems. No touch-screens, no graphics and no cashier-friendly reminders; just a plain old text-based interface with obscure keyboard commands for navigation. After all, they had spent a lot of money developing training programs for these registers and had no intention of simply throwing them out.

The retailer had also invested in a whole host of back-office management and reporting applications. Some were PC-based and some relied on proprietary hardware, but they all interfaced with the old cash registers' proprietary database. And though many of those applications were antiquated as well, the retailer had no desire to retire them. The new software would just have to interface with them. On top of that, the retailer didn't want a "flash cutover" deployment. They wanted a seamless, phased deployment that would allow them to switch over one register at a time, and have it all look the same on the back-end. So, with the latest and greatest technology at their disposal, Dave's team built outdated and mediocre software that functioned and communicated exactly like the old software. It did everything it was supposed to do and it did it right. And therein lay the problem.

Shortly after they delivered the software, the retailer rejected the QA testers' build and sent David's company a list of bugs. But it wasn't a list of bugs that their software had — it was a list of bugs that it didn't have. When the retailer said they wanted the same functions, they apparently meant the same bugs as well.