Breaking Bad or just a bad breakpoint? That feeling when your predecessor is BASIC

Here I am to save the day!


On Call That Friday feeling is upon us again after a week of dealing with IT issues and dodging the gimlet gaze of the boss. Hopefully yours didn't involve some impromptu debugging in production. Welcome to On Call.

Today are pleased to salute the return of Who, Me? contributor Susan, who previously regaled us with a tale from two decades ago.

Susan's latest anecdote takes place in the months before Christmas 2001 when she found herself suddenly bereft of work. She had been enjoying the lucrative life of a Visual Basic 6 and SQL Server contractor before her employer of four years abruptly went bust, putting her dreams of a lavish festive holiday in the Scottish Highlands at risk.

As was custom back in those halcyon days, she did not have to wait long before a new role dropped into her lap. A few days before she was due to depart on vacation, she had a telephone interview and found herself parachuted into a rescue mission. Her new employer needed a web application brought online; her predecessor had been fired after repeated promises that everything was on track and as deadlines loomed, it had become clear that all was not well.

As for the interview, Susan recalled the clincher: "The IT manager asked, 'Our previous developer couldn't deploy the binaries successfully – do you know how to do it?'"

Her (rather blasé as it turned out) response was: "It's pretty hard to fuck it up."

With the confidence that only years of contracting can bring, she arrived at a strange office, surrounded by strangers, and fired up the project. All looked good, except for the inexplicable inability of the previous coder to deploy the Visual Basic binary. It took her all of five minutes to spot the problem.

Two words to strike fear into the heart of many a VB coder back in the day – "binary compatibility." Checking the option would ensure the outputted binary was compatible with its predecessors. The setting was not ticked so, after checking the interfaces, she turned it on. The problem was solved, "so it was live the very same day."

"If ever there was a case of 'it works on my machine'," she said, "this was it."

But what of the On Call moment? Susan's initial contract was for three months so she was around when the web application finally went live. It was met with much rejoicing and celebration…

…right up until it stopped working.

The expensive contractor who had rescued the project was called upon once again to rescue it for a second time.

She checked the logs. She checked the code. There was no reason for the web application to lock up, but lock up it had, despite passing all tests in the test environment. At a loss, she eventually decided to go where programmers fear to tread and went to look at the physical servers.

The problem was visible the moment she brought up the desktop of the stricken web server.

"Somebody had installed VB6 on the production web server," she told us, "and it was currently in the foreground, stopped on a breakpoint."

In a desperate attempt to deal with the deployment problems, the previous developer had decided to pop a full version of Visual Basic 6 on the production web server along with the source.

"I'm sure the previous developer never informed his boss that he'd done such a monumentally stupid thing!" she said charitably.

The immediate problem was dealt with by removing the breakpoint and hitting F5. Some strong words were later had with the IT professionals responsible for the server itself.

And as for the bigger problem? Well, he'd already been fired.

Ever been called to fix a problem that was very much somebody else's work? Or were you that person who thoughtlessly laid the stinkbombs, knowing that you would be the one paged? Tell your story to On Call. ®

Similar topics


Other stories you might like

Biting the hand that feeds IT © 1998–2021