Steven quietly bowed his head as the planning meeting began. Their leader, messiah, and prophet was Jack, and today’s sermon was was the promise of Heaven- Heaven being the codename of their ground-up rewrite of their e-commerce solution.
Jack sat at the head of the table, in front of the projection screen. Behind him glowed the Spreadsheet of Pending Tasks, and the cells surrounded his head like rectangular halos. His eyes glowed with the power of his vision. “In Heaven, our customers will be able to customize everything. Everything!”
Jack had lead the development on Heaven’s predecessor. Like Heaven, it was endlessly customizable. It was also slow, buggy, impossible to maintain, utterly incomprehensible, and tied to a deceased proprietary technology stack. Jack had climbed the mountain and brought back word from management: a total rewrite.
Unquestionably, a good method name should be descriptive. With today's code completion and code analysis features, almost all developers expect the names to give them at least an idea of what a method should do. When you write a library, or work on a shared codebase, it's a must- and even if one doesn't expect anybody else to use their code, it's still good not to have to remember what stuff
The average big-box hardware store is like a small city. They have every piece of hardware or tool imaginable (except, of course, the one you’re looking for). You’ll find no less that 15 aisles of power tools stocked with everything from battery operated screwdrivers to arc welders. To store all these tools, you can purchase the 6-foot-tall rolling toolbox, with a 20-watt stereo, built-in beer chiller, wi-fi connectivity, and a Twitter or Facebook app. One aisle over, there’s row after row of pristine white toilets, occupied by a small army of playing children. Near the back of the store, nestled between endless rows of storm doors and windows is a quaint “grocery” section, as if someone uprooted and transplanted a gas station convenience store, and trimmed away all of the bits that weren’t junk food. Finally, outside the building, is the drive-thru lumber yard, where you drive to the end to purchase your 20 cubic feet of mulch and invariably get stuck behind an idling vehicle abandoned by a socially-clueless DIY-er who either disappeared on an epic quest to find help loading 200 short tons of bagged white river rock into his 1993 Ford Ranger, or more likely, thought it was a convenient parking spot while he left for an 8-week sabbatical on a mountain in Tibet.
“It’ll be a cold day in Hell,” Roger said, “when this system goes down.”
With those words, Roger, Systems Architect, went on sabbatical from Monocorp. The edifice he left behind served its purpose as foretold, until the day Danny O. was pulled out of a meeting by a panicked intern. “Everything is down,” the young man panted, short of breath and sweaty from a brisk dash around the office, trying to find which boardroom the IT team had been assigned for that day’s conference. “Everything! All requests to the web tier are returning some kind of duplicate record error that doesn’t even make sense! We’re dead in the water!”
We still have room for a few more storytellers, so if you're in the Pittsburgh area, pitch us your "real life" IT story. It need not be a WTF, just a story. Send a brief (1–2 paragraph) pitch for your story to firstname.lastname@example.org, and Remy will be in touch to discuss. We'll work with you to build up a great 8-10 minute piece you can perform.
It's Easter, so we're taking a little break around here. Instead, enjoy this classic from Alex. Stories like this inspired "Remy's Law of Requirements": no matter what the requirements say, what the users actually want is Excel.
For as long as The City (as I'll call it) has supplied water to its residents, it has had one big headache called "The Annual Water Survey." Like residents of all large metropolises, The City's residents want to make sure the water they drink has only a miniscule amount of the "bad stuff," such as heavy metals and pathogens, and just the right amount of the "good stuff" -- chlorine, fluoride, etc. The water survey -- a 100-plus-page report that details test after test after test -- was their vote of confidence.
Compiling the survey had always been a long and tedious process. At first, field technicians would take samples from across The City, add drops of various indicator chemicals and record the results in their logbooks. From there, lab technicians would transcribe the numbers and use special slide rules to create tables of meaningful results. Typists would then compile the various tables into a giant binder and send it off for duplication.
Steph had been at this job long enough to be fairly good at it, but not quite long enough to have peeked in all the dark corners yet. As such, when she heard that there was an issue with scheduled jobs, her first thought was to poke through cron to see if she could pick out what schedule was misbehaving. Apparently, all of them- cron was empty.
Confused, she went to her team lead Greg, asking about where she might find the scheduling setup. And that was when she heard about Travie the Whiz Kid. A junior developer with no degree, he'd been hired solely based on his ability to talk a big game about how he single-handedly saved several companies by providing them with innovative websites during the dot-com bubble... when he was twelve. The Whiz Kid was a Special Snowflake; he preferred to reinvent the wheel rather than implement stable but "boring" code. Upper management was convinced he was an unparalleled genius, and had exempted him from the usual QA standards. Unfortunately, he'd grown utterly bored with Business Intelligence and transferred to the Web team, leaving his inventions behind for Steph to maintain.
Today's episode: "Quantity of Service", adapted for radio by Lorne Kates, from a submission by Lyfe