Forums
In technology as in life, some folks get it, and some don’t. Trying to make the ones who don’t get it get it can sometimes challenge even the hardiest of tech-souls. Michelle made a valiant effort to enlighten one such individual, and failed. This is her story.
Marcus inherited a big-ol-ball-of-mud PHP application. The entire thing is one difficult to summarize pile of WTF, but he searched long and hard to find one snippet that actually summarizes how awful the code is.
That snippet is this :
On April 10th, I hosted The Daily WTF: Live! in Pittsburgh. It was a blast. We had a great crowd, and some great performances.
Our first story is one of my own- a tale about how one computer virus finds its violent end.
It had been a long meeting, and Bert was exhausted. Now, normally when a story on TDWTF starts that way, we go on to tell you about a hapless developer trapped in management hell, but this time, we're flipping the script on you: Bert was the Business Analyst on a project to enhance some self-check software for a number of supermarket chains. Ernie, the Software Engineer, was one of those braindead devs who needs everything spelled out before he'll write so much as a line of code, and Bert was much more comfortable with the looser specs in Agile projects.
"For a site that is used to view pay stubs, you'd think that they'd come up with better security questions," Carter K. wrote.
Our anonymous friend writes: I was tasked with figuring out why invalid XML was being output by a homegrown XML parser. As I looked into the code, I found the way this code handles writing out XML files…
Yes, it really does open and close the file handle for every xwrite call. This means that it opens and closes it 3 times PER TAG when writing out the XML.
Like most schools, Andy’s requried a “capstone” project for their software engineering track. It was a group project, which meant the project’s success was largely dependent on the luck of the draw. For his partners, Andy drew Mindy and Al. Mindy, he knew from other classes and had worked with before.
…Whatever remains, no matter how improbable, must be XML.
While Ian was working at Initech, one of the major projects he undertook was an integration with a third-party vendor. They had recently gotten set up with this product that became known internally as the Third Circle of Hell (3CoH), and wanted to export some data from it over to the vendor's website. Sales agents needed some information during cold calls, and 3CoH promised to provide the data interactively, so that they could continue their call somewhat intelligently.
Getting in to the 3CoH might be easy, but getting out is another matter.
"How new is this beer? They didn't even finish the packaging!" wrote Jérôme.
Roland was working on code that implemented HTTP service methods. The 'status' variable held one of those pass-it-everywhere objects that were sometimes called 'RunData'. It contained the request, response, security context, and other needed information. When JavaScript sent an asynchronous HTTP request, one of the service methods performed some backend magic and returned a JSON object with the appropriate data.
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 doStuff() does.
"I know that whenever I sit down to watch the adventures of brutal 14th century Mongolian warlords and Italian explorers, I want to dress the finest from my Ralph Lauren collection. And you should too!" writes Mike S.
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.
Early in life, we learn to grab the food and then put in in our mouths. Later, it's grab the ball and then roll it. In general, you must have something before you can attempt to do something with it.
...Or so you'd think.
“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!”
This is your reminder: TDWTF's live show is happening this Friday, from 8–10PM at the Maker Theater in Pittsburgh. Tickets are available now.
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 [email protected], 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.
-- Remy
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.
"We don't know what it is, but it must be bad, so we'll wake you up in the middle of the night to let you know about it!," writes David L.
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.
Mar 15
