KUKA Industrial Robot Writer

Jon worked for a small company that specialized in automation of inspection systems: basically the industrial version of home automation, where you glue together a series of disparate automatable parts to create a specialized workflow. Jon was the only software person at his 15-man company. The client was in Russia, and the company was in the USA, so communication went through email and primarily via a client representative, Sam. Sam would gather the requirements verbatim from the client and hand them to Jon; Jon would augment the software to meet their automation needs, and send a new version over to Sam to deliver. It worked, after a fashion. The system was designed to control a robot that mostly opened boxes, picked things up, ran a series of quality checks on the things, and put them back.

With home automation, most of the time the equipment isn't dangerous: light bulbs, speakers, maybe a garage door. Much of Jon's job, by contrast, was figuring out how to safely encode sequences of steps so that the robots—and the people standing nearby—didn't break. Requirements like "Don't move this piece while the robot is in motion" or "Don't put things into a box if the box is closed" required a good deal of time and effort to encode. Requirements like "Don't start the software if the robot isn't attached" seemed designed to hinder testing as much as possible.

The software shipped, and the inevitable change requests started rolling in. There had been two configurations of crate and robot that the company had initially asked for, but in practice, they used at least six. One of the changes they asked for was a checkbox to tell the robot whether it needed to open the box or whether the box simply didn't have a lid at all. The initial requirements had been concerned about the human error of accidentally forgetting to toggle the checkbox and causing the robot to smash through a closed lid, but in practice, the workers weren't going to add lids to boxes that didn't arrive with them, so it was needed after all. That particular update shipped, and Jon got to work on the next update.

It wasn't long before Sam was at his desk, frowning a little. "So, I have this bug report from the client, but ... I'm not sure how to enter it into Jira."

"Huh? You just type it in. What's the issue?" replied Jon.

"Well, here, they sent over a video. Come look at this on my screen."

"I'm a little busy, what's the problem?"

"The software just ... goes crazy. Somehow."

This Jon had to see. He walked with Sam back to the latter's desk, hovering awkwardly behind his chair as they watched the video. Sure enough, after enabling the "bypass lid" checkbox, when the settings were saved and the dialog box closed, random buttons began depressing, settings toggling, and other behavior. It was absolute pandemonium—and Jon knew instantly what had happened.

Software testing is a bit of an art, really: you have to be good at thinking like the end user, but you also have to be good at thinking outside of the box and anticipating the un-anticipatable. Testers have come up with shortcuts, ways to help guide testing to be more comprehensive to catch all the edge cases. One shortcut in particular had called to Jon: he could automate the UI, in much the same way the UI automated the robots. By clicking buttons at random, with random timing and random order, he could test extreme user error, determining that even if a literal monkey operated the software it wouldn't do anything unsafe.

He'd of course removed this mode from the final software, but he hadn't removed the code that made it function for fear of screwing up something else on accident after it had already passed his testing. That had worked beautifully in the initial version. However, when he needed a new checkbox, he had seen that there was an invisible one already in place and just re-used it. Furthermore, when he renamed the checkbox, his editor had helpfully renamed the associated click handler so that they remained linked. And without the robot, he couldn't actually start the software to test his code, so he'd just sent the update over and waited for bug reports to roll in.

"Tell them to roll back the update. Tell them I'm very sorry and I'll have a new patch on their desk by the end of day," Jon said, rubbing the back of his neck.

"But what on Earth happened?" asked Sam, gesturing to the screen.

"Ghosts." Jon shrugged.

"What?"

"The software's possessed. Haven't you ever heard people talk about 'the ghost in the machine?'"

[Advertisement] ProGet can centralize your organization's software applications and components to provide uniform access to developers and servers. Check it out!