The Daily WTF

On April 10th, I hosted The Daily WTF: Live! in Pittsburgh. It was a blast. We had a great crowd, and some great performances.You know him as the master of the Errords, the king of the CodeSODs, the Dev-Master of the Dev-Disaster, Mark Bowytz. Once upon a time, though, he was just another lowly office drone like yourself. This is his origin story: the WTF that launched a thousand head-desks.

Government Department prided itself on the precision of its process and procedures. Every function in the organization had its functionary, at least in theory. Joe had only been on the job a month when he discovered that figuring out which functionary would actually function wasn’t as easy as it looked. The Department used a database known as CAS to track all its financial data, including wages and work orders. Since Joe intended to earn wages in return for coordinating those work orders, he was going to need access to CAS. His first inkling that there might be a problem with the pervasive process was that, despite all employees needing at least basic CAS access for the payroll system, it wasn’t until his fourth week with the department that Terry, his team lead, gave him the good news.“You’ve been cleared for a CAS userid,” Terry said. “Go ahead and call up the CAS service desk to request it.”“So they haven’t created my ID yet, just cleared me to have one?” Joe asked.“That’s right. The CAS desk’s extension is 8888.”Joe dialed the extension. At the other end was the cheerful recorded voice of one of those programs that asks you to say what you want instead of pressing buttons. Joe just blurted, “CAS.”“For new or returning Government Department employees,” the voice said, “contact the security unit at 8889, or speak to the CAS role 132 user from your local IT unit. Goodbye!”Joe muttered to himself and dialed the next extension. This time, the voice was neither recorded nor cheerful.“Security. What seems to be the problem?”“Well, I need a CAS account-”“You need to contact the CAS service desk.” And Joe was hung-up on for the second time in five minutes.The process having officially sent Joe in a circle, he tried the cheerful recording’s alternative. He found his way to the local IT office and asked the team lead there about CAS. The response was cheerful, not recorded… but not helpful, either.“CAS? Oh, we can’t give you that. The service desk’s extension is-”“I already called them. They told me to talk to you… something about the CAS role 132 user?”The IT Team Leader chewed on that for a while, then turned and picked up his phone. While he dialed, he looked over his shoulder at Joe.“You know, it’s funny! I just finished getting CAS accounts for some new team members- took three days in the end!”Joe grimaced. The IT TL spent some time saying “uh-huh” into his phone, then hung up. He asked for Joe’s TL’s number, and promised to walk Terry through the necessary process. Joe returned to his desk and waited. That afternoon, Terry popped in to give him the good news.“I sent an email to that address IT told me about, it bounced back saying we need to contact the local CAS coordinator. I just emailed her, so we should be good to go any time now!”Terry left, and Joe returned to his job of waiting to be allowed to coordinate work orders. Fortunately, it didn’t take long to get a reply from the CAS coordinator. Joe was CCed:

“If you want to put everything under test, you have to write code like this.”At least, that’s what Alex’s co-worker said to him, when Alex demanded an explanation for this block of code.

"I clicked 'Yes' when asked if I wanted to send a report of VLC's crash, but apparently my attempted cooperation wasn't really appreciated," David K. writes.

TLDR; I have another Kickstarter Project, this time it's a kids book about programming!##Last year, I put a project up on Kickstarter that was inspired by things I personally love: games and software. Release! was supposed to be a one-off, quick card game project, but thanks to all of your help, it got pretty popular, pretty fast. We're halfway through selling our second print run of the game, and while it'll never do well enough to pay the rent... it may just do sell enough to get us a nice bottle of scotch, which we sorely need.I had such a great time with the whole venture that I wanted to put out another project. Which leads me to: Programming Languages ABC++. Here is the idea, it's an alphabet book which has a different code language for each letter: A is for Ada, B is for Basic, etc. Each page has a "Hello World" program in that letter's language, along with some facts about the language, and a colorful illustration of our mascot, the Computer Bug.Before you say it, I do realize that a toddler won't understand the code. It's not about teaching a baby to make a program, it's about creating a way for us parents, uncles, aunts, etc. to connect with the kids in our life. You know, share a little about what we do, in a context that the kids will actually enjoy.The whole thing started with my friends Michael and Martine Dowden, a pair of developers who had an idea to make an alphabet book that was all about programing. Within seconds of them explaining the idea to me I knew this would be the next fun project.Anyway, the project is live, and you can score a book for just $15, or a number of other fun rewards. Even if you don't have any kids in your life, and you've mastered your ABCs, backing at a $1 is still a great way to show your appreciation -- which, of course would be much appreciated![Advertisement] BuildMaster is more than just an automation tool: it brings together the people, process, and practices that allow teams to deliver software rapidly, reliably, and responsibly. And it's incredibly easy to get started; download now and use the built-in tutorials and wizards to get your builds and/or deploys automated!

Sally’s co-worker wanted to turn some data into HTML. It would flow from his application into client-side JavaScript which would build the DOM. He decided that it made sense to use a tree to represent the data as it’s translated.The C# declaration of his tree looked something like this:Dictionary<int, Dictionary<CatalogLoader_Helper.CatalogNode, List<CatalogLoader_Helper.CatalogNode>>> treeOBJMODEL;Isn’t it fantastic how Generics can make your code more readable and type-safe? I mean, that’s not what’s happening in this example, but…To traverse the tree, he used a terse, readable block like 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.Today's installment investigates exactly how a conference comes into being, told from the inside of Steel City Ruby Con.

When a system evolves and grows, it's usually necessary to identify various versions of software living in the wild. There are many ways to do that: some hide their version numbers in code, some keep them in configuration and metadata files, and others store them in the application's database.No matter the scheme, accessing and modifying the current version number should be easy and painless- that is, unless you're working with Stan K.'s codebase. In a truly brillant case of reusing existing system facilities, the developers resorted to a much less common method of determining which patches and upgrades have been applied:

"According to channel 7 in Australia these guys are right into trawling for content," Martin.

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.Michelle’s predecessor had migrated their code-base from VSS to SVN, before fleeing for the hills. Michelle was “the replacement.” Before she finished finding her cube, she was cornered by her manager and peers with some concerns. “About this new-fangled SVN source control system,” they began, and then they tried to pin her down as to how she could address their “issues”…Specifically, Bob, the manager asked: “Is it true that in SVN, anyone can check-out the code?”“Of course”, Michelle replied. She explained that anyone with an account can check out the source code at any time. This started an avalanche of stupidity that, not unlike one of snow, only gained mass and momentum with time.Jim, the lead developer, said that this was a problem. “If I checked out a file, I would have no idea if someone else was working on that file as well.” When Michelle just looked at him, blankly, he continued: “VSS was much better in that respect.”Michelle explained that this was the whole point, and in fact, one of the main benefits of SVN. Unlike VSS, SVN supports concurrent development, and it’s smart enough to automatically keep track of who’s changing what for you.Jim was worried that if he was working in an area of code, he needed to know that nobody else was working on it, so his change(s) wouldn’t get overwritten by the other developer.Michelle went on to console him by explaining the concept of merges and how merge collisions would be handled.“Yeah, but we’re working on a major bug and need to know that no-one else is working on those files!”Michelle then explained the concept of branches. She further explained that the file history was available for examination, and in an extreme case, an automatic email notification could be sent where anyone on the mailing list would receive notification every time someone committed code.Bob and Jim would have none of that. Bob complained, “No that’s not good enough. We can’t risk developers clobbering each other’s code. You need to change this. When I go to the bathroom, I have exclusive use of the stall. Others can only use it before me or after me, but not at the same time as me. We need this same level of isolation in handling our source code.”Try as she might, there was no explaining that this was really not necessary, as going to the bathroom and editing source code were, in fact, two very different things, and that it defeated the point of a multi-versioned, concurrent development environment…Bob insisted, in absolute finality: “No it’s too dangerous. Please change SVN to make to make it single check-out only; now! Before something terrible happens!”In reality, something terrible already had. Michelle resigned herself to the stupidity of running source control in the same way as accessing a toilet, she wrote a trigger script hack to disable parallel check outs. But at the end of the day, she couldn’t bring herself to activate crap mode.[Advertisement] Release!is a light card game about software and the people who make it. Play with 2-5 people, or up to 10 with two copies - only $9.95 shipped!

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.Since the fourth Requirements Clarification Meeting was dragging on into hour two, Bert was getting a little snippy. So when Ernie asked for clarification on exactly how long a given printout might be, in millimetres, Bert couldn't help himself: he cracked. "Well, potentially infinite, I guess!"The code Ernie delivered:

"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.Al was a stranger, but Al had made his presence known from the very first day of class. You see, Al had industry experience. Al had been working with a global manufacturing company for a few years, and didn’t really need this class. He lived this stuff. He knew more than the professor, so Al spent most of his time trying to help the other students, even going so far as to hold is own informal “office hours” in one of the computer labs. At their first team meeting in one of the conference rooms in the library, Al explained, “This project here looks pretty close to some of the work I’ve been doing.”“You’ve implemented a database for a library to track users and assets?”“Not exactly,” Al said, “but it’s a basic data-driven application. I’ve written thousands of these.”“That’s really great to hear,” Andy said, “because Mindy and I haven’t actually taken the databases class yet- we don’t really know SQL.”“Great!” Al said. “I can work on the data-layer.”As an experienced enterprise developer, Al took the weekend to write up a specification for the database layer, which he gave to Andy and Mindy. They could use a stubbed version of the database layer, while Al did all the work on that side.“Now,” Al warned as they reviewed the latest ER diagrams in a quiet corner of the campus coffee shop, “I’ve worked on a lot of projects like this, so let me warn you- we’ll probably need to spend some time doing some serious integration testing to link all of these modules together.”“Oh, I’d expect as much,” Andy said. “If you can finish your work within the next week, we’ll have two weeks left to do our testing.”“Will do,” Al said.Al didn’t do. He didn’t get his database layer committed until one week before the due date. He skipped the next team meeting and sent an email, “Project crunch at work, not available. Will send updates.”Andy and Mindy fired the application up with a pile of instructor-provided test data. It took nearly 100 seconds to filter through the 1000 test users and find a single user’s account. Performance got worse with larger data-sets, like the list of books in their “library”.If it were just poor performance, Andy would have thrown indexes at the problem and hoped that cleared things up. There were worse problems, though. For example, according to the database, today’s date was “Martha Sawyer”. User “Jim Mahony” had $–155132 in late fees, there were 15,005.542 books in the database, and 16,000 of them were available to be checked out to users.Andy decided to take a look and see if he could address those bugs. He immediately regretted the decision, because one look at the code told him that he had just given up on getting any sleep for the next week. Al did okay at managing database connections, but his “vast” industry experience apparently didn’t include the use of the “where” clause. Every single query he wrote followed the pattern:

…Whatever remains, no matter how improbable, must be XML.Developers have many weaknesses, among them this: they don’t like to say that something can’t be done. That’s why when Glenn M’s client, TelCo, asked if their request was really impossible, instead of apologizing and vigorously nodding his head, Glenn said, “Well, technically…”And that’s how he ended up writing this.

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.The existing system was manual and thus slow and rife with error. Sales agents would have to copy all of a customer's information, by hand, from 3CoH into a web form, which boiled down to a lot of copying and pasting. But since the vendor provided a SOAP API and 3CoH had its touted scripting language (essentially Java with some syntactic sugar for querying the 3CoH database), there was probably a way to automate the process. The task of doing that was assigned to Ian.Of course, going directly from 3CoH to the vendor was out of the question, as it would involve hand-crafting a SOAP request and filling in fields by just concatenating together a giant string of XML with some variables. Some of his predecessor PHP developers at the company had thought that was a perfectly fine thing to do, and had created some scripts to employ that anti-pattern.Ian had a less fragile idea in mind. With the aid of a Java library that generated Java classes from a WSDL, he set up a bridge server to stand between 3CoH and the vendor. 3CoH would package up all the needed information into JSON and send it to the bridge server. The bridge server would shuffle the data from the incoming JSON into the objects representing the SOAP request, generate the SOAP request, and send it off. When the reply came back, the process would go in reverse; the bridge server would pull out the URL returned by the vendor, and send it back to 3CoH as a regular HTTP response.After a few development iterations, it worked, albeit slowly. That is, it would take about 30 seconds for the whole process, which is a long time when you're on a cold-call with a customer. Even worse, it would make Chrome assume the page had frozen and pop up a scary-looking dialog box to that effect. Ian was testing by pointing to the vendor's QA website and not the real one, so he naturally assumed this was the cause of the slowdown.He was wrong.Once they went live, he found that it was still just as slow, and the sales agents and managers were not happy, summarily resulting in various high-level managers alternately panicking about a failed project and spewing brimstone and fire down his neck about getting it fixed.But the surprise came when Ian timed each segment:

"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.That was the good case. In the bad case, the service method called status.fail, added one or more user messages, and returned without sending a reply. The error handling in the base class detected that the call failed, and sent an error response containing the user messages.Roland had just introduced that pattern, which was meant to put an end to the convoluted error handling in older parts of the codebase. It seemed to work well. Then one day, he encountered a different use case: a service method that didn’t return any data in the good case. For the sake of symmetry, he decided it would return an empty JSON object, and got to work implementing that.You're doing something wrong, his inner voice cautioned.Roland had just copied some code from the good case of another service method: setting the MIME type and charset of the response, getting the OutputWriter, writing the data, closing the stream. Five lines total.Still, he supposed his inner voice was right. Five lines of code for an empty reply was a bit excessive, but that was how he’d implemented the good case elsewhere.Yes it is, the voice said. But for this? There's got to be a better way.Roland reviewed the base class, checking whether there was any code he could reuse. Unfortunately not. The five lines were built into the error handling logic, and could not be invoked directly.Time for some refactoring, the voice said.Roland cringed hard at the thought. He’d spent so much time in the base class already. He was thoroughly fed up with refactoring.You've got all the access you need, and you've got the source code in the editor already! Go on now...Just as he was about to give in, Roland noticed something interesting: when he triggered the error handling without adding user messages, it sent an empty JSON object.What the hell?And he could specify the HTTP status code! Roland set it to 200.

"Lindsay."Lindsay did her best to ignore her co-worker, Asher. Ever since management had removed cubicle walls (to "facilitate communication"), it had been a never-ending trial focusing on fixing bugs with the world's most annoying webdev prodding her every few minutes to talk about some inane television reference or sports event."Lindsay."Lindsay closed her eyes, picturing the Maui beaches where she hoped to be reclining in two days time. Surely she could hold out that long, right?"Lindsay!""What?!" She snapped, ripping off her headphones to look at his screen."Did you see that P1?"Stunned that Asher was actually bothering her about, wonder of all wonders, work, Lindsay closed her travel agent's website and pulled up the bug tracker.Sure enough, she'd been assigned a P1 defect. In the self-service component of the Procurement website, all users were able to download a spreadsheet containing the price lists for...Lindsay gave a low whistle. "Is that every client's price sheet?"Asher nodded, face grim. Pricing was a strictly held secret in the business-to-business world; if one client found out another was getting a deal they didn't qualify for, there'd be hell to pay. Only admins should've had download privileges, but somehow, that download button was enabled for every user of the site.Priority one was usually reserved for "the entire site is down." A price sheet leak was pretty much the one exception.It was easy enough for Lindsay to pull up and duplicate. She wondered how long the button had been incorrectly enabled. There was no indication in the ticket. Lindsay called the user, who explained they'd just noticed the problem. "But who knows how long it's been that way?"Crap. It wasn't just a simple matter of reviewing what had changed since the last build. Lindsay pulled her headphones back on, switching from relaxing white-noise to something more upbeat while she brought up the debugger. Three grueling hours later, she found the reason why any and every user was able to download the price sheet:

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.

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.Some people, however, take it a bit too far. Today's example of abusing good practices was provided by David, who sent the following code with a comment: "This code takes $10 million USD in transactions a month". After reading it, it's fairly obvious the developers shouldn't be trusted with the loose change in their pockets:

"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.Scott loved working in such a store while going to college for an IT degree. He didn’t work on the floor, where the poor retail staff dealt with angry customers trying to negotiate down the price of a few 2x4’s, or trying to return 1000 pounds of tile (which was clearly defective because it shattered when they dropped it on concrete). Scott was the store’s IT tech, doing all the tasks that Bob, the store’s “IT Associate” and self-proclaimed “computer expert”, should know how to do but didn’t.Scott got an after-hours call that the computer system was entirely down, and Bob couldn’t figure out the problem. This was strange, since Bob was the “expert”. The small server closet, designed and installed by Bob, was supposed to be entirely redundant. The server had a hot spare and both systems had redundant power supplies.“Scott, glad you’re here!” a panicked cashier greeted him as he ran into the store. “We can’t run any transactions and the customers are getting furious!”Scott quickly made his way to the small closet in the back of the office area. Both servers were off, with no power at all. Pushing the power buttons did nothing. Meanwhile, he could hear irate customers with access to power tools and sledgehammers berating the helpless cashiers whose registers were offline.He traced the power cables from the server and facepalmed when he discovered the problem. Each server had two power supplies. The first power supplies were plugged into a nice, long-corded surge protector, which connected to the wall outlet. The backup power supplies were plugged into a $3.50 power strip somebody had pulled from the store’s shelves. Those cords weren’t long enough to reach a separate outlet, thus it was plugged into… the first surge protector!The room was fairly warm, and with the full load of two “redundant” circuits, the surge protector had overheated and tripped its breaker. Scott rewired the power supplies into an actual redundant fashion, reset the surge protector, and had the registers back up and running within half an hour. He called it a day and went back home.Until an hour later, when the cashiers called him back in: everything was down again. Now that the servers didn’t die when it got mildly warm in the room, it had turned into a furnace. Bob, the “expert”, was busy trying to fan the heat out with a towel when Scott arrived. Scott set up one of the industrial fans in the store to ventilate the room and called maintenance to get someone to look at the HVAC system.The fan got the servers cool enough to keep running, but Scott and Bob waited around to see what maintenance found. One of the technicians grabbed them. “Did you know the thermostat was set to 45ºF?”“What?” Scott blurted.“Of course,” Bob said. “Computers should be as cold as possible. They run better.”“Not that cold!” Scott said.“Well, you can’t keep them that cold,” the tech said. “The AC unit just runs continuously, and the coils get so cold that they start to freeze. Literally- your AC unit is a block of ice right now. Leave it off for a few hours, and then turn it back on at a reasonable temperature.”That day, Bob and Scott followed their instructions, but Bob remained unconvinced about these warnings. As the seasons transitioned into summer, he cranked the thermostat lower and lower. Through the hottest months of the year, Bob caused six more heat-related outages as he did his best to destroy the AC unit. Fortunately, they worked in a hardware store. Scott installed a lock-box over the thermostat and told Bob that maintenance had done it.[Advertisement] BuildMaster is more than just an automation tool: it brings together the people, process, and practices that allow teams to deliver software rapidly, reliably, and responsibly. And it's incredibly easy to get started; download now and use the built-in tutorials and wizards to get your builds and/or deploys automated!

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.While trudging through the migration of their code from one SharePoint solution to another, S. T. encountered this soul-sucking comment about the code that follows:

“It’ll be a cold day in Hell,” Roger said, “when this system goes down.”

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 storytelling@jetpackshark.com, 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.This event is brought to you by our awesome and proud sponsor, Puppet Labs*. As we mentioned in their sponsorship announcement article, thanks to their support, we’ll be able to create some exciting new content, do more meet-ups, and have a lot more fun all-around. This is an example of that and we are still very excited to be working with them! Check out their intro video, it gives a pretty good overview of how they help their customers get things done.We’d also like to thank Code & Supply for helping us network with the Pittsburgh IT community. Code & Supply is the largest IT community group in Pittsburgh, with frequent meetups and a variety of activities. They’ve helped connect us with performers and are helping promote the show with their community. They even let this guy give a talk on using storytelling to communicate technical details.[Advertisement] BuildMaster is more than just an automation tool: it brings together the people, process, and practices that allow teams to deliver software rapidly, reliably, and responsibly. And it's incredibly easy to get started; download now and use the built-in tutorials and wizards to get your builds and/or deploys automated!

"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.Travie had been tasked with writing a helper application in Java to interact with and process data from a third-party web service. The third party processed their data on certain days at certain, known times, and their app needed to wait and pull down the data after it was guaranteed to be there. The ticket involved the wrong data being collected: at 5:15AM on the second of the month, the script was pulling in the previous month's data to process, rather than the current. Was it running early?Steph found the repo with the Java code The Whiz Kid had written and checked it out, skimming over the list of files as she finished her morning latte. She opened the Schedule class, winced, and closed it again. "Definitely need more coffee."

Radio WTF Presents!Jump to transcriptToday's episode: "Quantity of Service", adapted for radio by Lorne Kates, from a submission by LyfeLinks To Downloads

James stood on the precipice of a significant upgrade to his company’s reporting capabilities. Purchasing had cut a deal with the vendor ÜberWarehouse to upgrade their warehouse inventory tracking system from a basic .NET application with limited functionality to a full-blown data warehousing system. He jokingly called it the “Warehousing the Warehouse Project”. He was the only one who found it funny.

I'll be in Japan once again, and figured it'd be the perfect opportunity to celebrate Hanami with Tokyo-area TDWTF readers:Hanami (花見) roughly translates to, hangout with a group of friends and colleagues under a cherry blossom tree while drinking beer, sake, and possibly whisky, along with enjoying various snack foods. As the above picture above (courtesy of Ari Helminen on Flickr) depicts, it's pretty much the thing to do in Japan this time of year.So, if you're up for getting together this Friday (possibly Saturday?) for Hanami, and likely an izikaya afterwards... please drop me a note via the contact form or direct, apapadimoulis/inedo.com.[Advertisement] Manage IT infrastructure as code across all environments with Puppet. Puppet Enterprise now offers more control and insight, with role-based access control, activity logging and all-new Puppet Apps. Start your free trial today!

Our sponsor, Puppet Labs, wants to know what your DevOps needs look like. Take their survey, and be entered to win some valuable prizes.[Advertisement] Release!is a light card game about software and the people who make it. Play with 2-5 people, or up to 10 with two copies - only $9.95 shipped!

One of the well-known rules of life is that the most straightforward solution is usually the best solution. Obviously it's not always possible to "keep it simple, stupid," but one should aim to make their creations as self-explanatory and to-the-point as possible- otherwise it's easy to end up with a nightmare in terms of both maintainability and performance.Some people, however, have chosen to defy that rule. One of them was Rube Goldberg. This engineer turned cartoonist became famous for inventing ridiculously complex contraptions to achieve the simplest tasks. And while Mr. Goldberg passed away in 1970, the concept of a "Rube Goldberg machine" outlived him, showing up in hundreds of cartoons, events, and comedy movies.And, as Matt R. learned, it also made its way into his codebase. While refactoring and rewriting a 32,000-line long file, he came across this incredible machine:

"I was casually browsing Bingo games and this one asked me to finish developing their site for them," writes Steven W.

Robert ran a web service used to store legal file data for a number of clients. One day, he received an email from his biggest client, Excédent, asking to meet about a new requirement."We've purchased new accounting software that requires us to track an additional piece of data," Philippe, Robert's contact from Excédent, explained over the conference call a few days later. "Each of our cases must now have a ‘cost center' associated with it. There are a lot of these cost centers, so when our employees enter case data, we'd like for them to be able to pick the one they need from a list."Robert frowned in thought. "Well, you guys already use every available field in my database. This would require me to add a new field to the database and web forms." A database change on a web service used by many clients wasn't horrible, but not exactly a prospect Robert relished either."Is that a problem?" Philippe asked. "We're getting a lot of pressure from above on this. We really need it as soon as possible."Robert couldn't refuse his largest client. Besides, it was one measly field. "No, it should be OK. I'll figure out the nitty-gritty details myself. In the meantime, can you put your cost centers in a spreadsheet and send them to me? I'll import them into the database when I'm ready.""Sure!" Philippe said.It didn't take Robert long to create the new cost center table (VARCHAR(100) seemed safe), link it to the case data tables, and update his web forms with a new dropdown field. However, the spreadsheet from Philippe took longer. Much longer.Where the heck is this thing? Robert wondered. Wasn't this supposed to be "urgent?"Over the following several weeks, Robert sent a few gentle prodding emails. Finally, Philippe responded. Sorry for the delay! I was cleaning up the data. The list is about half as long as it used to be. Thanks!Robert smiled. That was nice of him, whittling down the list to, what a couple hundred or so? Time to import them and test everything out…He opened up the spreadsheet- and froze in horror.Robert realized he'd made one of those terrible assumptions we all make from time to time: believing a client's simple request was just as simple as it sounded. There were nearly 1800 "Cost centers" in Philippe's spreadsheet, each one with 17 fields (four of which aren't visible in the screenshot).Excédent employed 3600 people. Philippe claimed to have whittled the list down by half- meaning that before he'd scrubbed the data, there'd been nearly one cost center per employee.Robert scrolled up and down the spreadsheet in mute horror for several minutes before grabbing the phone and ringing Philippe's desk. "This is kind of a lot of data to put into a dropdown," he explained, heart pounding. "Is there any way to simplify this further?""No, sorry," Philippe said. "That's the best I could do."Who's going to scroll through 1800 cost centers every time they log a case? Robert wondered. Panic transitioned to desperation. "I think we need another call."A week later, Robert met with the client to explain that the "cost center" ""field"" was simply too complex for him to accommodate. They decided not to import the list after all, and to have employees manually enter cost centers into a text field (ex. "345 Water Distribution"). Not optimal, but it worked.To Robert's complete lack of surprise, a quick browse of those values manually entered over time showed that only a tiny handful of the 1800 cost centers had ever been used.[Advertisement] Use NuGet or npm? Check out ProGet, the easy-to-use package repository that lets you host and manage your own personal or enterprise-wide NuGet feeds and npm repositories. It's got an impressively-featured free edition, too!

Who’s Down With PHP?PHP often gets a bad rap. A lot of the time, that’s because it’s used by developers that don’t know what they’re doing, just like there’s nothing inherently wrong with spandex, but there are times, places and people where it is inappropriate. And don’t get me wrong, the language has made big strides in recent years (good luck finding a web server hosting one of those versions, though). But there are just uses of PHP that reinforce that reputation. Robert Osswald provides this example from the contact-form editing code of a domain registrar database.Let’s say you have some JSON data from an AJAX request, and it looks like this:

In the 1980’s, there was a TV show called The A-Team. There was the scrounger, who could scam anyone out of anything. He would make promises that were sort of true to get what he wanted (sound like marketing?) There was the tough guy who could intimidate anyone into doing anything. He knew how to get things done, but underneath it all, was a nice guy. There was the leader, who could always come up with a plan to save the day. And there was the one guy who was a little crazy (the good kind of crazy), but who you could count on in a pinch. There was also the occasional outside helper who would run interference and recon. This was a group of folks who worked as a well-oiled machine to get the job done. Failure was not an option! They were a team!The A-Team never filed a project methodology document. No wonder they were wanted criminals.Alex had taken a job on a new greenfield development effort to replace an aging and unsupportable birds-nest-o-wtf™. Naturally, the position was advertised as “we intend to do things right!” The project is fully funded. We will have the proper equipment and team personnel to get this job done. We have the full support of six layers of management plus all of the users. Alex was optimistic.The first thing they did was spend several months wrapped in those numerous layers of management, end users, support folks, senior people who used to support the project (to explain the problems that plagued the old system), and the three architects of the new system. The new architecture was heavily documented, presented to and signed off on by all of the above. It was even reviewed with a critical eye by an independent third party regulatory auditing agency to ensure that the overseeing authorities were confident that the correct approach was being taken.An 8 page document detailing development coding guidelines (e.g.: code formatting settings, naming conventions, unit tests, code coverage and other such team-wide items) was created, reviewed and decreed to be followed by all who worked on the project.The project was off to a good start.Job one was to hire the development part of the team. For this, they looked (very far) offshore to find the cheapest possible talent. After all, anyone can be trained, right? A team of 11 developers who collectively had 13 years of experience, and a team leader with 5 years of experience were hired and put in place.The next major decision was which database should be used. There were three in widespread use at the company. Since all of the databases were hosted on centralized servers, one was immediately ruled out because the hardware that hosted the data servers was insufficiently powerful to handle the expected load in a reasonable time frame. Of the other two, one was widely used by everyone on the team. They knew its syntax, quirks and limits. The the third was mis-configured to have a reputation as being flaky. However, that one also was the corporate standard. In spite of the objections of the team, they used the third one.Project management decided that QA folks could be brought in later.Finally, it was time to begin doing detailed design. The offshore lead decided that a lot of time could be saved by doing design on-the-fly as required. Of course, the architects objected, but the project manager agreed to it.And so the architects started working on building the controller engine and other such mainstays of the project. The junior team, which was to query numerous remote systems for input data, merge, filter and pre-process it, decided that they knew better than what was specified in the architecture document, and started designing their own way of doing things. Without telling the architects or management.Come time for the first sprint check-in and all sorts of red flags flew up during code reviews. The junior lead decreed that the architecture document was only a suggestion that could be ignored in favor of the developers desires. Naturally, this spawned lots of are-you-f’g-kidding-me’s and emails up the chain. The project manager and above seemed disinterested, saying that the junior developers shouldn’t be doing that, but we trust them to do the right thing.This went on, with the architects pointing out implementation flaws and shortcomings that would not support the requirements. All suggestions were ignored, because the offshore lead said “Google fosters an environment of innovation and creativity; we should too!” He was reminded that Google is (in large part) a think-tank, and that this was a highly regulated project within a highly regulated industry. The architecture, which had been signed off by more than 40 managers, was not optional or a suggestion, but mandatory. This was not kindergarten, where creativity is fostered; you had to stick to the approved plan! Now, we’re not talking about how to write a subroutine, or encapsulate an object; we’re talking about using threading incorrectly and in the wrong places, doing database accesses and interprocess communication in such ways that would not be scalable, or provide enough throughput to finish daily runs by regulatory deadlines. Spawning multiple processes instead of just using threads. Using files to act as semaphores, because that’s how they did it in school. The list goes on.None of that mattered. The junior developers resented that they were not consulted on the architecture, and so were bent on ignoring it - with the blessing of their lead. The project manager continued to acknowledge the problems, but didn’t do anything about them. The problems were reported up the chain, and nothing was done. Everyone on the team should have an equal say in things.In the real world, if a student thinks the teacher is wrong, he doesn’t get to change his grade. The surgical resident cuts where the surgeon says and not the other way around. The general doesn’t discuss strategy with the privates. If you join a union, and as the new guy demand to have equal say on policy with the union bosses, you’ll be bunking with Jimmy Hoffa. Experience speaks with exclamation points. Inexperience speaks with question marks.Except on this “team”.The junior developers continued to do what they thought was best, ignoring the architects at every turn. Much of their code was written and rewritten several times over because the designs by the juniors didn’t take things into account. Things more experienced folks know to plan for. By the time 8 months had passed, so much damage had been done that some of the more complex requirements simply couldn’t be hooked in, and more than a month of back-pedaling had to be done on a greenfield development project.About this time, management acquiesced and asked some of the business users to write business-level tests (e.g.: via a spreadsheet that would be fed into JBehave to JUnit test things). The developers would provide the underlying code and some sample entries in the spreadsheets. The architects said that QA folks should be hired because business folks rarely know how to deal with edge cases, precision issues, etc. But the money was not to be spent. After six months of effort, the business users proudly decreed that all the tests for the entire application (e.g.: the entire requirements document) had been set up. A five minute glance showed that they didn’t handle edge cases, null cases, precision cases, or most of the other things that usually require tests. In fact, they had put all of the records that could possibly be processed (at least in their minds) into one giant pass-fail test. Of course, when something changed and it inevitably failed, there was no way to know what failed.Finally, it got so bad that the architects built a physical wall in the code between the setup code (written by the offshore folks) and main engine (written by the architects) sections of the application. Immediately before the main engine began to grind the data, every single variable in the system would be flushed to a state table in the database, so that when something would inevitably be challenged, they could show the inputs that were provided and send the fix-it work to the offshore team. At least this way, they could insulate the main engine from the debris.The department saved a lot of money by using cheap labor, no QA folks and the politically expedient database. Of course, all of the code of the setup portion done by the offshore team was a disaster, and for the most part, very difficult to learn, support, debug and enhance.The product hadn’t even been deployed yet, and the users were already complaining that it took too long to diagnose and fix problems (one of the main reasons the whole rewrite project was authorized), that perhaps the rewrite wasn’t satisfying the main purpose of the rewrite, and that perhaps something might be wrong…[Advertisement] Manage IT infrastructure as code across all environments with Puppet. Puppet Enterprise now offers more control and insight, with role-based access control, activity logging and all-new Puppet Apps. Start your free trial today!

Perl is jokingly referred to as a “write-only language”. This is because Perl’s primary solution to any problem is to throw a regular expression at it. Regexes are powerful, but cryptic. Imagine RJ’s joy at starting a new contract for an OCR/document-management system that makes heavy use of regexes. Even better, the system doesn’t use widely implemented “Perl-compatible regular expressions” syntax, but instead, uses its own, slightly tweaked version.So, for example, when the system needs to pick the document ID out of the scanned document, it uses this regex:

"Hey, may I get your permission...quickly? I'm about to leave for a world tour and I have a LOT of ground to cover," writes John

A few years ago, Joel Spolsky wrote his simple, 12-point test to measure how “good” a software team is. Stan was thinking about this test quite a bit, when he started a new job at a company which set a new record for failure.Stan’s journey started after an excited recruiter told him, “I have a great role for you, working for a cutting edge online retailer in London!” Stan became a Senior PHP Developer on a team of three others. Each day there, he asked another question from the Joel Test.Let’s review Stan’s experience against the 12 questions from the Joel Test.1. Do You Use Source Control?Stan asked about source control during the interview, and the interviewer replied, “No, we don’t have any at the moment. But we will soon!” When Stan started, he found that the only copy of the source code was the live website. Any changes meant downloading the site, altering the files, and re-uploading the changes over FTP. He very quickly got used to hearing the question, “Is anyone changing users.php?”, or “Hey, where are all my changes from yesterday?!” Having four people work on a live website using only FTP to synchronize work caused friction, like throwing sand in an engine.Joel Test Question 1: Fail2. Can You Make a Build in One Step?Building should be as easy as possible. The best solution is to have a script which can handle the entire build process from start-to-end. Check everything out from source control (if you have one!), compile binaries, and create the installation packages. Without this, building will be error prone.Without source control, and without any concept of development servers or test servers, “builds” were deployed via FTP. The team made database schema changes by uploading specific PHP scripts with the required SQL and loading them as a page while praying that nothing breaks. When things did break, it was extremely difficult to debug or rollback the changes. I’m not sure “build” or “release” are even valid terms for this company, any more than “architect” describes a kid who lobs globs of mud at a wall.Joel Test Question 2: Fail3. Do you make daily builds?Daily builds make sure your repository trunk is in good working condition. At least once a day, obvious errors like incomplete check-ins or missing dependencies are easily discovered, and discovered early, before any software enters production use. The term “daily build” implies some sort of integration and testing environment, not ad-hoc FTP uploads to a live site.Joel Test Question 3: Fail4. Do you have a bug database?You need a good way to track defects. What’s the error? Who reported it? How can it be reproduced? What’s the priority? When was it fixed? Of course, tracking bugs is meaningless when one developer’s FTP upload can overwrite another developer’s previous efforts, causing the bug fix to be lost for all eternity.Joel Test Question 4: Fail5. Do you fix bugs before writing new code?Stan’s company fixed bugs all of the time, as any software firm must. However, those bugs regressed all the time too, since one developer’s fix could easily be rolled back when another developer uploads their version of the PHP file a few hours later. This methodology ends up like this.Joel Test Question 5: Fail6. Do you have an up-to-date schedule?Having a schedule would mean having a list of features, a timeline by which they need to be finished, and priorities to help determine what gets in and what doesn’t if the timeline slips. Instead, Stan had a constant stream of emails, memos, and Post-It Notes handed down from management.Stan might be half-finished with a “top priority” feature when a different director would storm into his cube. “Did you fix my issue yet? Get on it! Now! NOW! It’s an EMERGENCY!”Joel Test Question 6: Fail7. Do you have a spec?Good software has some kind of list of requirements, or at least a description of what the software should do. For Stan, his “spec” was determined by which director was currently in his cube, screaming about their personal fire that needed to be extinguished. It’s only by the grace of good fortune that his cube was too small for two directors to be badgering him at once- that situation might have come to blows.Joel Test Question 7: Fail8. Do programmers have quiet working conditions?“Are you aware of the exciting new opportunities available to you, with our products?”One of the many “top priorities” for their company was marketing, so they hired a stable of telemarketers. Short on office space, they stuffed them in the only place that was free: next to the development team. Within a few days, the developers wanted to chop off their own ears, just to quit hearing the marketing script on endless repeat.“Are you aware of the exciting new opportunities available to you, with our products?”Some offices invest in cheap white-noise generators to cut down on that sort of cross-talk. Stan’s wasn’t one of those.“Are you aware of the exciting new opportunities available to you, with our products?”In fact, the office had other infrastructure problems. When winter arrived, the building’s heater broke down. Working from home was out of the question- how could directors storm into your cube to “clarify” priorities? Instead, everyone was forced to work in the sub-zero office.“Are you aware of the exciting new opportunities available to you, with our products?”Developers huddled in their cubicles, wearing coats, hats and gloves. Imagine the quality software written by a team-“Are you aware of the exciting new opportunities available to you, with our products?”-wearing gloves, in the freezing cold, while listening to the steady mumble of marketing copy.Joel Test Question 8: Fail9. Do you use the best tools money can buy?Developers need to have powerful PCs. If you give your development team a stack of Pentium M laptops with single-core CPUs and 512MB of RAM in 2015, they’ll spend 90% of their time standing on their rolly office chairs and fencing with makeshift swords, or just watching Chrome cry while rendering web pages.When Stan first started, he was assigned a nice, shiny MacBookPro, stuffed to the gills with RAM and an SSD. Shortly after he got it set up for development use, the sysadmin informed him that this was a requisition mistake. “This machine was actually for one of the new graphic designers. You get this one.”The replacement was a 5 year old machine that was suitable for email, Solitaire, and virtually nothing else.Joel Test Question 9: Fail10. Do you have testers?Stan’s company almost wins this one on a technicality. While they didn’t employ any testers, they had customers. They were abused as testers, since they would naturally call in and complain when ~a software release~ big ball of mud was FTP’d to the live server.A generous grader might be tempted to give partial credit for this, since they at least recognize that testing needs to happen. But let’s repeat this: their customers were their dedicated testers on a production website.Joel Test Question 10: Double Fail11. Do new candidates write code during their interview?During Stan’s interview, he was not asked to write any code. In fact, his interviewer didn’t speak English terribly well, so the interview was mostly the two of them smiling and nodding at each other. It probably didn’t matter, since most of Stan’s day wasn’t spent writing code- it was spent rewriting the code that got deleted after the last FTP-based screw-up.Joel Test Question 11: Double Fail12. Do you do hallway usability testing?A good way to test is to grab a random person as they walk through the hallway, and force them to use the software you just wrote. They don’t work on your team, and may not be familiar with the project or its requirements. Can they use it? Is it intuitive? Does the user interface make sense? This is a great way to discover usability issues that developers easily overlook.In Stan’s company, they sort of did the opposite. Random directors would storm into Stan’s cube, not to try the software, but to dictate a new mandate without any thought to whether or not it made sense.Joel Test Question 12: Reverse FailTotal Score: –2.0000000000000000001420001, thanks to two double fails, and the floating point rounding error is caused by the Reverse Fail.As the new Senior PHP Developer, Stan fought to clean things up somewhat. He got a Subversion server set up on a spare box, and managed to get a development server with a clone of the live system. In a few months, they started working almost like a “real” software team. Productivity went up, bugs got patched before users saw them, and FTP-induced rework was almost entirely killed.Sadly, after all these changes, management called in the team and complained that they were all overpaid, lazy, and a drag on the company. Stan quit on the spot, and over the next few days, the rest of his developers followed him. Weeks later, he heard through the grapevine that they’d brought on a new team, and were undoing Stan’s “wasteful” changes.Apparently, the highest priority directive was to ensure their record-setting score on the Joel Test.[Advertisement] Manage IT infrastructure as code across all environments with Puppet. Puppet Enterprise now offers more control and insight, with role-based access control, activity logging and all-new Puppet Apps. Start your free trial today!

You’ve read the posts. You’ve submitted your own WTFs. Now it’s time to take it to the next level: The Daily WTF: Live is coming to Pittsburgh, PA.In the style of The Moth or Risk! podcasts, we’re getting our fellow IT drones up on stage, to share their tales of their worst WTFs, their successes, and true tales of life in the IT trenches.The live show is April 10th, 8–10PM at the Maker Theater in Pittsburgh. Tickets are available now.Don’t worry if you can’t make it to Pittsburgh. We’ll be recording the show, and sharing the best stories here on the site from time to time, in addition to our normal stream of WTFs.If you’re in around around Pittsburgh, and think you’ve got a killer story and want to get in front of those lights, we still have open slots for storytellers. Send a brief (1–2 paragraph) pitch for your story to storytelling@jetpackshark.com, and Remy will be in touch to discuss. (Your story doesn’t have to be a pure WTF) We'll work with you to build up a great 8-10 minute piece you can perform.This event is brought to you by our awesome and proud sponsor, Puppet Labs*. As we mentioned in their sponsorship announcement article, thanks to their support, we’ll be able to create some exciting new content, do more meet-ups, and have a lot more fun all-around. This is an example of that and we are still very excited to be working with them! Check out their intro video, it gives a pretty good overview of how they help their customers get things done.We’d also like to thank Code & Supply for helping us network with the Pittsburgh IT community. Code & Supply is the largest IT community group in Pittsburgh, with frequent meetups and a variety of activities. They’ve helped connect us with performers and are helping promote the show with their community. They even let this guy give a talk on using storytelling to communicate technical details.[Advertisement] BuildMaster is more than just an automation tool: it brings together the people, process, and practices that allow teams to deliver software rapidly, reliably, and responsibly. And it's incredibly easy to get started; download now and use the built-in tutorials and wizards to get your builds and/or deploys automated!

As any competent developer knows, not all Web browsers were created equal. In a stew of standards, drafts, vendor extensions, and JavaScript engine quirks, each of them can behave a little differently under various circumstances. Many people tried to resolve this situation, but "creative" coders are always one step ahead, finding new and amusing ways to mandate the dreaded "runs only under Internet Explorer 6" popup on their webpages.This time, our submitter found out that his bus timetable was working just fine on Safari:Under Firefox, however, it was curiously missing one of the schedules:Is it a JS compatibility hack gone wrong? he wondered. Maybe a badly-placed -webkit- prefix? Curious, he checked the source.It was neither. Instead, the author of the code just really, really, really wanted the link to be blue:

We've all learned to write programs a bit more generically than the immediate problem requires. We use interfaces in our code and include concrete implementation classes via some language-appropriate mechanism. We use factories to produce the object we want, rather than hard code them. We use code generators to spew forth mountains of code from configurable templates. Sometimes, we even generate SQL on-the-fly. It provides more flexibility that way; instead of having to write a separate query for every permutation of question, we can write something that can dynamically create the query, execute it and return the results.At Initech, Ian was assigned an interesting JIRA ticket: Investigate errors regarding column length. Since that was all the information written in the ticket, Ian hunted down the author of the ticket to pry out a tad more information. Apparently, the part of Initech's intranet website that was used by the sales agents was suddenly throwing errors about some kind of maximum-size error, and he needed to find out what it was, why it was happening and how to fix it.Sounds routine enough. Someone probably overflowed some buffer somewhere, or had too much data to fit in some column in the database.The website in question was nothing out of the ordinary. It was written in PHP using the Zend framework connecting via PDO to a MySQL database. It had been mostly written by several programmers who had left the company a few months prior, and was of a quality that was not unusual for a corporate PHP website. There were functions with reasonably sensible names. The MVC pattern was applied in a rational way. It was possible to follow the code structure without retching or having seizures.Of course, since this was a fairly decent sized company, there were also the requisite SQL injection vulnerabilities on every single input field. No input was ever sanitized; not even manually. There was no error checking on query result sets. Countless uninitialized variables littered the landscape, scattered amongst informative debug statements like: echo("whyyyyyyyy?");The page producing the error was written by Gary. It was a multi-tabbed form with only some minor WTFs. One drop-down box had a completely different look&feel than all the others on the page, and any kind of error more complicated than a validation error produced the error message "1".Sales agents were supposed to use it while talking to customers to enter information about the person they were calling. The error they were getting was a MySQL error regarding maximum row sizes, but it wasn't because of too much data in an input field. After a double-take and a quick Googling, Ian found that yes, MySQL -does- have a maximum size on the length of a row, namely 64KB. But this was just an Insert statement, right? What would maximum row length have to do with an existing table schema?After several spelunking sessions down through the fetid bowels of the system, Ian found the fecal mass of detritus that was causing the problem.It turns out that Gary was being micro-managed by the VP of Operations. This led to an endless series of requests to add a new field to the form. Gary got tired of doing the same work over and over, and took it upon himself to automate the problem. To this end, any time a new field was added to the form (usually by someone SSH'ing onto the remote server and just editing the necessary PHP files directly in production), the page would later on detect that the database did not have a matching column for it, and would create an alter table statement to add the new column to the database. Automatically. On the fly. With no human knowledge of, or intervention thereof. Live. In Production.The fact that it had lasted several months without causing some kind of outage was impressive.The name of the new column was the ID of the field on the form. But what would the data type be? The answer Gary settled upon was... varchar(255). Fast-forward a few months; all those varchar(255) columns started to add up, as management decreed more and more and more fields for more and more and more customer data to be recorded. While having a database table with 200+ Stringly-Typed columns is a WTF in and of itself, the fact that they were automatically added and with a substantial size only made the problem worse, particularly as 255 characters was far more than necessary for most fields. Two-letter state abbreviations, 5-digit Postal codes, 4-digit Zip+4 postal codes, 8-digit customer IDs, apartment numbers, phone numbers, and many others were all blanketed under the varchar(255) datatype.While Ian wanted to tear out this monstrosity and banish it to the recesses of the Git commit log, he was informed by his boss that, since the Intranet website was going to be taken down in a few months, it would be more prudent to simply resize some of the columns to buy them enough time to take the whole site down. And so, choosing some of the more egregious offenders, Ian altered ten columns or so to reduce them to a sane size (or, better yet, to turn columns holding integer values into actual Integers).[Advertisement] Use NuGet or npm? Check out ProGet, the easy-to-use package repository that lets you host and manage your own personal or enterprise-wide NuGet feeds and npm repositories. It's got an impressively-featured free edition, too!

There's only so much time left to get your free TDWTF mug, with the new logo and everything. Be the first kid on your block to have one.Last year around this time, we did a Free T-Shirt Day. You all gave some great feedback, so I thought we'd try it again with a Free Mug Day!My company, Inedo, will be once again sponsoring this round of The Daily WTF mugs. Although we haven't yet released our v5 of BuildMaster yet, we've made a lot of big improvements since last year, and thought this would be a good opportunity to show them off. The mugs will be the same, serious grade as always -- but this time, they'll feature the brand-new logo (unlike the one below).

Pop quiz: how do you ensure that a number is negative? You could do something like:

"I'm not sure what happened...maybe they ran out of vowels?" Mitch wrote.