The consulting company that Alicia worked for, NewSoft Associates, was in the intelligence business. Their work involved digging through data produced using technology that was years and decades old, identifying the nuggets that were valuable, and persisting them into a central repository so that others could perform the needed analysis and take the appropriate action.

Yes, they were a Business Intelligence company. And Alicia was one of their leading consultants.

When it came to extraction, transformation and loading, there were few in the industry who were better. When faced with divergent definitions of 'customer' or 'month', Alicia had the rare ability to get the parties to find their common ground. But she was even better when digging into the technical morass that frequently surrounds a BI project. For those of you old enough to be involved in Y2K projects, a typical BI engagement is similar. The data structures are convoluted enough to drive the designers of the Byzantine labyrinths crazy. The data is stored in antiquated technology created when COM+ was considered cutting edge. And most of the software used to populate the data was written by monkeys who were annoyed at their lack of an opposable thumb (you trying using the space key without one and you'll understand). Flinging faeces was (and still is) considered bad form in the workplace, so the coders flung good sense to the wind instead.

As a result of Alicia's position in the company, she was often used where no one else could cut it. Such was the case with her current gig, helping the Goodall Construction company extract twenty years of data from their Hyperion system.

The project had run into the standard set of BI issues. Collections of old spreadsheets containing both data and macros. Lack of validation of the data that had been entered. Disparate data sources using different working definitions of the same word (Inigo Montoya would have a field day). But there was one set of data that was consistently failing on conversion. The vast majority of cases worked just fine. But a few cases just blew up the program. The particular value that was causing grief was 2196O.

Now the very astute among you might have already spotted the problem. But put yourself in Alicia's shoes. Hidden amongst a sea of numbers, the difference might not be quite as striking.

Finally, Alicia saw the issue. Quickly she took it to Donald, the Goodall developer who was assigned to the project. When Alicia pointed out that the 'O' at the end of the number was alphabetic instead of the expected numeric value, Donald paused for barely a moment.

"Oh that. Don't you know? This is how we record negative numbers. They are so rare that we usually don't worry about them."

Alicia's jaw dropped. Before she could pick it up off the desk, Donald typed a few keystrokes on this terminal and turned it towards her.

"This should straighten you out", he said.

On the screen, this is what Alicia saw. 

EVALUATE #SIG
   WHEN = 0
   LET $SGN = '}'
   BREAK
   WHEN = 1
   LET $SGN = 'J'
   BREAK
   WHEN = 2t (sic)
   LET $SGN = 'K'
   BREAK
   WHEN = 3
   LET $SGN = 'L'
   BREAK
   WHEN = 4
   LET $SGN = 'M'
   BREAK
   WHEN = 5
   LET $SGN = 'N'
   BREAK
   WHEN = 6
   LET $SGN = 'O'
   BREAK
   WHEN = 7
   LET $SGN = 'P'
   BREAK
   WHEN = 8
   LET $SGN = 'Q'
   BREAK
   WHEN = 9
   LET $SGN = 'R'
   BREAK
END-EVALUATE

It took a couple of moments for Alicia to grasp the WTF-ness of the snippet. But, gathering her wits, she thanked Donald and asked him to send the snippet to her.

After all,, she thought, What if the last digit in a negative number were a '2t'?

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!