Smooth, Like a Factory

Daren S knew that his days were numbered. He was a troublemaker bent on changing The Way Things Were and The Director was hot on his tail. Though Daren worked discreetly, improving his coworkers' productivity a little bit at a time, it only was inevitable that The Director would eventually find out. One does not become The Director by letting such things slide.

A financial services provider, Daren's company did a lot of data processing and aggregation from a lot of different sources. The Director acknowledged that their processes were "a little rough around the edges" but insisted that they ran "smooth, like a factory." An accurate analogy I'd say, especially considering what the typical industrial factory is like: poisonous steam pipes spewing death gas every three seconds; razor-sharp pinwheel governors spinning at different yet predictable intervals; and giant, spiked stampers slamming down on conveyer belts running different speeds in varying direction, all placed inconveniently at the entrance and exit so that they must be meticulously navigated to avoid a significant loss of Life Points. At least, that's what every factory I've been in was like.

Also like a factory, the company's processes were developed over several years by many different engineers who carelessly bolted additions to the diabolical machinery. The most convoluted of these processes was the bi-weekly Hedge Report. One of the business' most critical reports, it took two people two full days to create. It was also Daren's new maintenance responsibility and, consequently, his downfall.

The Hedge Report needed data from four different sources aggregated into a single SQL Server. The aggregation was entirely manual: spreadsheets were generated, copy/pasted to each other, emailed, processed with a special script, emailed again, and so on. Daren's first mistake was to create a Visio diagram that modeled this process. Everyone knew how it worked, so said The Director, and Daren could have just asked any one of the many people involved.

Daren's second mistake was to make a minor change to a VB5 application that extracted data from another SQL Server. Before his change, the application would inform its user of a null datum by crashing and leaving a half-processed file that required the user to dig through, go back to the original SQL Server source, and change the null datum to the string "NULL." Though it shaved a few hours off of the report generation time, The Director felt it was a waste of time, because they had a completely suitable workaround.

Daren's third mistake would have been his suggestion to change an AppleScript that processed semi-raw data to a more manageable VBScript. But he was starting to learn. Although this AppleScript required that someone at another location logon to the company's only Mac workstation, run the script, and email back the results, Daren figured this would be a battle for a much later day.

Sadly, Daren never got to fight that battle. Fed up by Daren's constant requests to "improve" the process, The Director demanded to know what exactly was wrong with the ASP.NET module that Daren kept asking to change. After all, he personally oversaw the addition and paid good money on consultants to build it.

Daren printed out the Page_Load() method using a half-spaced six-point font with two "screens" per page. He highlighted the buggy and incorrect code, spliced the pages together, and went back to The Director's office. In a move that may not have been the wisest career choice, Daren held the first page in the air above his head and let the other taped-together pages cascade to the floor. With over seven-feet of highlighted code in hand, Daren said: "this is what's wrong with the code."

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