Steve’s group was quite good,
they made quality software.
Then came Initech.

Initech bought them,
management had a field day
restructuring teams.

Haiku 2008-02-19

Steve was a mid-level developer when his company got purchased by Initech. Naturally, the new owners wanted to change everything. Old people were fired, new people were hired, and HR promised to take this group to “the next level.”

They hired a man named Ty, who replaced the senior developer on Steve’s team.

He was an expert
and his experience would
bring much rejoicing.

Or so said HR.
Steve quickly found himself to
disagree with them.

Early on in his new employment, Ty called Steve to his desk. “I’ve got this requirement, but I just can’t quite get the code to work. I’m getting an input from the user, and if it’s a number or a string, I have to do something different in each case. I can get it to work one way or another, but not both!” Steve quickly showed Ty the documentation for Integer.TryParse and the “if” statement. As he left, he heard Ty mutter, “his framework is way too complex! Nobody trained me for this!”

This was a common scenario. Steve had to hold Ty’s hand through even the most basic programming tasks.

Give him an input
and ask him to validate,
and he won’t get it.

Hand him a double
and have him round it to tenths,
and mainframes will crash.

Show him an error
and stacktrace, his own brain will
overheat and melt.

Fizz-Buzz would have been
enough of a test to stop
his acquisition.

Ty blamed everyone but himself for his problems. “Someone checked in bad code. It worked yesterday!” “My computer is broken!” “Steve is an idiot!” This last was exactly the sort of thing the new management wanted to hear. They pulled Ty into a critical new feature: new reports for their BI application. This happened to mirror work Steve had done just a year before.

When Ty was tasked to
develop BI reports,
Steve kept his distance.

Ty coded and worked,
and after several months his
work was deployed live.

But celebration
was not in order, there
was a big problem.

“Steve! We have a huge problem here!” said Tyler, as he burst into Steve’s workspace. “The numbers in my reports don’t match the numbers in your old reports. You need to figure out what you did wrong.”

Steve blinked. “No one has noticed any problems before. Are you sure your report is right?”

“Of course it’s right!” retorted Tyler. “Now go fix your bugs- we need an answer by the end of the week.”

Steve looked at Ty’s code
and found bad SQL joins.
The output was wrong!

Because of the joins,
sums grew exponentially
based on project count.

Employees with few
projects were in the ballpark,
but still not correct.

Employees with tons
of projects were millions of
bucks overstated!

Steve gathered his findings and prepared for an end-of-the-week meeting. Both Ty and the BI director scoffed at what he found.

Though Steve’s old reports
had not changed in many years,
they had to be wrong.

Ty’s report output
contained a lot more data!
And that’s a good thing!

“You see,” the BI director explained, “look at how many more rows are in Ty’s reports than yours. His shows more information. More information is always better!”

“But,” Steve tried to explain, “the data is wrong. He’s doing cross-joins where he shouldn’t be!”

“How can more data be wrong?” Ty challenged. The BI director nodded in agreement.

Since more is better,
Steve was given a new task.
His heart grew heavy.

Lo, his own reports
must be re-written to work
just like Ty’s reports!

Loosely inspired by this thread

Image Credit: KAMiKAZOW Haiku: Contributors (Own work) [MIT (http://opensource.org/licenses/mit-license.php) or MIT (http://opensource.org/licenses/mit-license.php)], via Wikimedia Commons