Vegas, baby! A Register reader gambles his software will beat the manual system

The house always wins. Even in the Casino back office

Who, Me? The weekend has waddled into the distance and Monday is with us once more. Join us for another episode in our Who, Me? series where a reader finds himself with a plum contract and no other bidders. What could go wrong? What indeed.

Today's story comes from "Paul" (not his name) and takes us back a few years to an incident that occurred amid the glitz and glamour of Las Vegas.

Paul's story starts in prosaic form. His company was bidding on a time and attendance system for one of the smaller, but rather well known, Vegas casino chains. The company had already provided the accounting department with servers and software, and so seemed a shoo-in for the employee monitoring system. The software was "tailor-made to interface to their payroll and human resources applications," explained Paul, "Best of all there were no competitors being asked to submit proposals."

"Management liked what they saw, so we installed a trial for the payroll department to review and run internal testing. Bear in mind this was our own T & A system, custom designed for casinos with an excellent history at other sites. What could go wrong, we figured?"

What indeed.

Sensibly, there was no big-bang style switch-on. The payroll was run in parallel with the existing manual system and… disaster. The figures didn't add up and the employees that would have seen mistakes in their paycheques were numbered in the hundreds.

"Puzzled," said Paul, "we carefully went over the pay calculation audit logs and found a large number of incorrect configurations on pay/time rules."

"Unions," he added darkly: "it can get complicated."

Undeterred, the gang implemented the fixes and the test ran once more.

Again, disaster. In fact, Paul's team had somehow made things worse. "Even more failures," he sighed, "many from untraceable causes, along with complaints it took too long."

So bad were things that the payroll department demanded that the code be pulled and escalated the issue to management. And so the shiny new app was summarily yanked and Paul moved on to bigger and better things.

And there the story should have ended. We've all been there – seen the latest and greatest come catastrophically undone when put into the hands of users.

Except it didn't. Fast-forward three years and the casino in question had been sold on and Paul's boss happened to be chatting to one of the (now ex) payroll clerks who had made such a fuss over the new system back in the day.

It transpired that the new system had actually worked perfectly. Too perfectly. Not only was it better than the manual system and produced more accurate results, it also took hours to run rather than days.

But those were days that the payroll department had always been all too happy to claim for overtime. Even worse was that by automating all the adjustments, the extra people normally needed to massage the figures would no longer have been required. "If the automated system had been used," Paul told us, "it would cost most of the department entry clerks hundreds of dollars a month, each."

"The reason 'it took too long' is all the time spent sabotaging the test results to ensure it would fail."

And here the story does end with a final ironic twist. Remember the selling on of the casino? The new holding company simply terminated the entire payroll department and sent processing out of state.

The reason?

"The locals were too expensive to retain."

Oddly "protecting our paycheques" is rarely given as a response to the old saying: "this is why we test" but maybe you've been the victim of sabotage by fiscally concerned users? Or perhaps you were the one creating those impossible failure scenarios? Confess all with an email to Who, Me? ®