The Daily WTF

It’s tempting to pick on PHP, because PHP is a terribly designed language. At the same time, there’s an air of snobbery and elitism in our mockery of PHP. I mean, half the Web runs on PHP, so how bad can it be? These examples could easily have been written in nearly any other language, and they’d be just as bad in those languages too. Is it fair to single out PHP? Perhaps not, but each of these examples does nothing- or nearly nothing- which may very well be PHP’s greatest asset.As a case in point, Ethan inherited some code. It needs to count how many sub-directories there are in a certain directory.

Steven worked for Integrated Machinations, a company that made huge machines to sell to manufacturers so they could actually manufacture stuff. He didn't build the machines, that would require hard physical labor. Instead, he wrote computer programs that interfaced with the machines from the comfort of the air-conditioned office. One such program was a diagnostic app used to log the performance of Integrated Machinations products. The machines didn't break down often, but when they did, logging was very important. Customers wouldn't be in a mood to hear that IM didn't know why the equipment they dropped fat stacks of cash on failed.Steven also had a subordinate named Thomas, who was foist upon Steven in an effort to expand the small development team. Steven could have easily handled everything himself, but Thomas needed something to do so he was given the simplest part of the diagnostic app - the downloader. Steven's code handled the statistical compiling, number-crunching, and fancy chart-making aspects of the application. All Thomas had to do was make the piece that downloaded the raw files from the machines to pass back.Thomas spent two months on something that would have taken Steven a week tops. It worked in their test environment, but Steven wanted to code review it went to production. Before he could, the higher-ups informed him there was no time. The logging and downloading system was installed and began to do its thing.Much to Steven's pleasant surprise, the downloader piece worked in the real world. Thomas had it set up to run every minute from Crontab on every machine their pilot client had. It passed back what the compiler needed in XML format and they had neatly-displayed diagnostic stats to show. This went on for a week, until it didn't.Steven came in that Monday to find that nothing had been downloaded over the weekend. As soon as Thomas meandered in, unshaven and bleary-eyed, he instructed him to check on the downloader. "Sure, if I can fight off this hangover long enough. Are you sure your stuff isn't broken??" Thomas replied, half joking, half trying not to pass out.Two hours passed, half of which Thomas spent in the bathroom. He finally came back to Steven's office to report, "Everything is back to normal! We lost all the logs from the weekend, but who works on the weekend anyway?" He quickly disappeared without further explanation.So began a repeating cycle of the downloader crashing, Thomas coming to work hung over, then fixing it without explanation. The Thomas problem got resolved before the downloader problem. He was relieved from his employment at Integrated Machinations after his sixth "no-call, no-show". This left Steven to support the downloader the next time it went down. It was completely undocumented, so he had to dig in.He found the problem was with the log file itself, which had bad XML for some reason. Since XML has a rigorously specified "Parse or Die!" standard, and Thomas wasn't much for writing exception handlers, the next time the downloader ran, it would read in the XML file, get a parse error, and die. It was at this point Thomas would have to delete the XML file, restart the downloader, and things would get back to normal.Digging in further, he found every time the downloader ran, it read and parsed the entire log file, then manipulated the parse tree and added a new <download> element after each record. Finally, it wrote the whole thing back to disk.

"In life, there are good surprises and bad surprises, but Microsoft fails to differentiate," writes Rob

Ah, the ternary operator. At their worst they’re a way to obfuscate your code. At their best, they’re a lovely short-hand.For example, you might use the ternary operator to validate the inputs of a function or handle a flag. Adam Spofford found this creative use of the ternary operator in a game he’s developing for:

Recently, we featured the story of Alex, who worked in a little beach town trying to get seasonal work. But Alex isn't the only one with a job that depended entirely on the time of year.For most seasonal work in IT, it's the server load that varies. Poor developers can get away with inefficient processes for three quarters of a year, only to have it bite them with a vengeance once the right season rolls around. Patrick, a Ruby developer, joined an educational technology company at the height of revision season. Their product, which consisted of two C#/Xamarin cross-platform mobile apps and one Ruby/Rails back-end server, was receiving its highest possible traffic rates. On his first day at the office, the entire tech team was called into a meeting with the CEO, Gregory, to address the problem.Last year, the dev team had been at a similar meeting, facing similar slowness. Their verdict: there was nothing for it but to rewrite the app. The company had, surprisingly, gone in for it, giving them 6 months with no task but to refactor the app so they'd never face this kind of slowdown again. Now that the busy season had returned, Gregory was furious, and rightly so. The app was no faster than it had been last year."I don't want to yell at anyone," boomed Gregory, "but we spent 6 months rewriting, not adding any new features—and now, if anything, the app is slower than it was before! I'm not going to tell you how to do your jobs, because I don't know. But I need you to figure out how to get things faster, and I need you to figure it out in the next 2 weeks."After he left, the devs sat around brainstorming the source of the problem."It's Xamarin," said Diego, the junior iOS Dev. "It's hopelessly unperformant. We need to rewrite the apps in Swift.""And lose our Android customer base?" responded Juan, the senior Mobile Dev. "The problem isn't Xamarin, it's the architecture of the local database leading to locking problems. All we have to do is rewrite that from scratch. It'll only take a month or so.""But exam season will be over in a month. We only have two weeks!" cried Rick, the increasingly fraught tech lead.Patrick piped up, hoping against hope that he could cut through the tangled knot of bull and blame. "Could it be a problem with the back end?""Nah, the back end's solid," came the unanimous reply.When they were kicked out of the meeting room, lacking a plan of action and more panicked than ever, Patrick sidled up to Rick. "What would you like me to work on? I'm a back end dev, but it sounds like it's the front end that needs all the work.""Just spend a couple of weeks getting to grips with the codebase," Rick replied. "Once exam season is over we'll be doing some big rewrites, so the more you know the code the better."So Patrick went back to his desk, put his head down, and started combing through the code.This is a waste of time, he told himself. They said it was solid. Well, maybe I'll find something, like some inefficient sort.At first, he was irritated by the lack of consistent indention. It was an unholy mess, mixing tabs, two spaces, and four spaces liberally. This seriously needs a linter, he thought to himself.He tried to focus on the functionality, but even that was suspect. Whoever had written the backend clearly hadn't known much about the Rails framework. They'd built in lots of their own "smart" solutions for problems that Rails already solved. There was a test suite, but it had patchy coverage at best. With no CI in place, lots of the tests were failing, and had clearly been failing for over a year.At least I found something to do, Patrick told himself, rolling up his sleeves.While the mobile devs worked on rebuilding the apps, Patrick started fixing the tests. They were already using Github, so it was easy to hook up Travis CI so that code couldn't be merged until the tests passed. He adding Rubocop to detect and correct style inconsistencies, and set about tidying the codebase. He found that the tests took a surprisingly long time to run, but he didn't think much of it until Rick called him over."Do you know anything about Elastic Beanstalk auto-scaling? Every time we make a deployment to production, it goes a bit haywire. I've been looking at the instance health, and they're all pushing 100% CPU. I think something's failing out, but I'm not sure what.""That's odd," Patrick said. "How many instances are there in production?""About 15."Very odd. 15 beefy VMs, all running at > 90% CPU? On closer inspection, they were all working furiously, even during the middle of the night when no one was using the app.After half a day of doing nothing but tracing the flow, Patrick found an undocumented admin webpage tacked onto the API that provided a ton of statistics about something called Delayed Job. Further research revealed it to be a daemon-based async job runner that had a couple of instances running on every web server VM. The stats page showed how many jobs there were in the backlog—in this case, about half a million of them, and increasing by the second.How can that work? thought Patrick. At peak times, the only thing this does is make a few jobs per seccond to denormalising data. Those should take a fraction of a second to run. There's no way the queue should ever grow this big!He reported back to Rick, frowning. "I think I've found the source of the CPU issue," he said, pointing at the Delayed Job queue. "All server resources are being chewed up by this massive queue. Are you sure this has nothing to do with the apps being slow? If it weren't for these background jobs, the server would be much more performant.""No way," replied Rick. "That might be a contributing factor, but the problem is definitely with the apps. We're nearly finished rewriting the local database layer, you'll see real speedups then. See if you can find out why these jobs are running so slowly in the meantime, though. It's not like it'll hurt."Skeptical, Patrick returned to his desk and went hunting for the cause of the problem. It didn't take long. Near the top of most of the models was a line like this: include CachedModel. This was Ruby's module mixin syntax; this CachedModel mixin was mixed into just about every model, forming a sort of core backbone for the data layer. CachedModel was a module that looked like this:

“This is part of a home-grown transpiler…”, Adam wrote. I could stop there, but this particular transpiler has a… unique way of deciding if it should handle module imports.Given a file, this Groovy code will check each line of the file to see if it includes an import line, and then return true or false, as appropriate.

Let’s take a moment to talk about documents. I once worked on an application that needed to generate some documents for Sarbanes-Oxley compliance, and without confessing to too much of a WTF, let’s just say it involved SQL Server Reporting Services, SharePoint, and some rather cryptic web service calls that I’m almost certain have stopped working in the years since I built it. The solution belongs here.I bring this up, because I’m happy to announce a new sponsor here at TDWTF: Atalasoft, which would have kept me from writing that awkward solution.Atalasoft makes libraries for working with documents from your .NET applications. There are SDKs for manipulating images, working with PDFs, and mobile SDKs for doing document capture on iOS or Android devices, and WingScan provides interaction with TWAIN scanners right from inside of a web browser. Their products provide zero-footprint document viewing, easy interfaces for constructing and capturing documents, and come with top-tier support for helping you get your application built.This sponsorship coincides with their latest release, which partners with Abbyy’s FineReader to add OCR support, the ability to interact with Office documents without Office installed, new PDF compression options, and a variety of improvements to their already excellent controls and SDKs.[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!

In my formative years, I had experienced such things as Star Trek, and the advent of new games like Pong, Space Invaders and Asteroids. As I ventured out of college and into the Orwellian future of 1984, I began a 3+ decade long sojourn into the world of technology. I mused about the wondrous changes that these new-fangled gadgets would bring to all of our lives. Telescreens that connected us both visually and orally in real time. Big Brother. History could be rewritten. Technology would boldly take us where no one had gone before... Hollerith cards were replaced with Teletypes, then CRTs and finally flat panel displays. You can still fold, spindle and mutilate a flat panel display; it just takes more effort.Pneumatic tubes were replaced with email and finally text messages. Try as you might, there's simply no way to text someone a live critter.Interactive Voice Response systems. Talking to a helpful customer service representative is no longer necessary now that we can listen to a recording droning on. After all, don't you just love doing a depth-first search through 17 sub-menus to get what you want?ARPANET d/evolved into the internet. Google has eliminated the need to have bookshelves of manuals, or remember anything you've ever posted - because it's all there in perpetuity. Granted, a lot of it is filled with pron, but you don't actually have to look at it!Programming languages. We went from assembly to FORTRAN to C to C++ to Java/.NET/... to scripting languages. While it's true that auto-GC'd languages make it easier to concentrate on what the program must do instead of interfacing with the machine, VB/PHP/Excel/etc. brought programming within reach of those who should not have it. COBOL lives on (as it turns out, the Enterprise does have a mainframe)Communication. Snail-mail was slow. Email sped things along, but we got impatient so they invented texting. Apple leap frogged a great idea, but only for the truly nimble-fingered. They still haven't gotten dictation-transcription to work properly; we're nowhere near the point of saying: Computer, build me a subroutine to... because the replicator would spit out a submarine.Security: Challenge-response questions aren't a bad idea, but too often all the allowed questions can have multiple answers, which forces you to write the Q/A down and keep them nearby (I don't have an older cousin, neither of my parents has a middle name, my first pet was twins and the place I met my wife was in a village in a township in a district in a county).Security: Requirements that vary wildly for the password-make-up, and change-frequency from system to system and company to company (requisite link).Hmm, 4-8/6-12 characters? Numbers/upper/lower case? Subsets of: ~!@#$%^&*()_+-={}[]:;"',.?/) Change it every 4/6/8/12 weeks? Maybe I'll just go with the fail safe PostIt. FWIW: I haven't had to change the password on my bank ATM account in 35 years because I. Don't. Tell. It. To. Anyone.Now that the government has shown that any device, no matter how secure, can be cracked, we must all realize that encryption, no matter how sophisticated, ain't cutting it...Security: We could just write everything in Perl; it would be completely secure after 24 hours (even without encryption) as nobody (including the author) would be able to decipher it (missed opportunity).Editors: edlin, notepad, vi: when they were all you had, they were a blessing. Notepad++, vim, IDEs, etc: big improvements. But with convenience comes dependency. I once had to edit a config file for a co-worker because they couldn't figure out how to edit it on a *nix production system where Emacs wasn't installed!Smart phones allow you to concentrate on that all-important email/text/call instead of driving. You can play games (like Pokemon-GO) while behind the wheel, so you can crash into a police car.Of course, how many times have you texted someone about something only to end up sending an auto-corrected variant (Sweetheart, I'm going to duck you tonight).Smart cars allow your navigation system to blue screen at highway speeds. This happened to my CR-V, and the dealer told me to disconnect the main battery for 30 seconds in order to reboot the car.The computer can also modify your input on the gas pedal to make the car more efficient. This sounds like a good thing. Unless you stomp the accelerator through the floor (clearly demanding all the power the engine can give) and the computer decides otherwise, which leads to some very WTF looks from the truck driver that almost pancaked you.Smart appliances: we no longer need to pester our spouses because, while at the supermarket, we can now contact our appliances directly to see if we need this or that. This will inevitably lead to weekly security-updates for our cars and appliances (you know the day is coming when your fridge and coffee maker start to automatically download and install a Windows-10 update).Games: from Conway's Life to Sim*, Tetris to Angry Birds, the assorted 80's video and arcade games, Wolfenstein/Doom/Quake/etc., and everything that followed. Games have drastically improved over time and provide tremendous entertainment value. They have yet to build a computer that can count the number of hours of sleep lost to these games.Miniaturization: they spent zillions creating monstrously large flat panel TVs and then zillions more to get us to watch movies on our phones. After they spent zillions making stuff smaller, they flooded those smaller devices with ads for stuff to enlarge things.These topics were chosen randomly while thinking back on my career and wandering around my house, and of course, there are many more, but rather than having made drastic improvements in our lives, the changes seem oddly even...On the other hand, I don't recall Scotty ever having to download a Windows update, and Lt. Uhura never got a robo-call from someone in the Federation (Enterprise: if you would like a scan of the 3rd planet of the system in sector 4, press 3), so maybe the future will be brighter after all.[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!

"Just perfect. This is not a good day for the entire Internet to break. Thanks for the heads up, Moodle," writes Đuro M.

This anonymous submission is the result of our submitter decompiling a Flash application to see how it worked. It’s not often that one thinks to himself, “Wow, some case statements would’ve been a lot better,” but here we are.

Maintenance programming is an important job in nearly any software shop. As developers move on to other positions or companies, the projects they leave behind still need someone to take care of them, to fix bugs or implement customer requests. Often, these products have been cobbled together by a variety of programmers who no longer work for the company, many of whom had only a loose understanding of the product (or even programming in general).Martin was one such maintenance programmer. After being hired, management quickly realized he had a knack for digging into old systems and figuring them out well enough to update them, which often meant a full rewrite to make everything consistent and sane.One such system that quickly fell into his lap was essentially a management appliance, a Linux virtual machine (VM) prepackaged with a web-based management interface to control the system. The web application worked well enough but the test suite had…trouble.The tests used Selenium to deploy a fresh VM and perform some pre-defined actions on the user interface. Most of the test suite was written by a former employee named Jackson who, as far as Martin could tell from his notes and source control commit messages, had very odd assumptions about how things worked, especially involving concurrency.The test suite had some serious performance issues, as well as a ton of inexplicably failing test cases. The system did not scale up as more VMs were deployed, at all, and Martin uncovered the scary truth that Jackson had wrapped everything in synchronization primitives and routed all actions through a global singleton which stored all state for all VMs. Only one test operation at a time was supported, across all test VMs, forcing them to queue up and run sequentially.Seeing how all test state was stored in a global singleton, Martin realized that a huge number of the test suite’s failures had to do with leaky state. One test VM would set some state, then give up its lock between tests, providing a small window for another VM to grab the lock and then fail because the state wasn’t valid for that specific test.He asked around the office to see if anyone knew more about the test system, and though nobody knew the specifics, his coworkers did recall that Jackson was hugely concerned that state would leak between test VMs and cause problems and had spent most of his time designing the system to avoid that. So Martin started reviewing source control history and commit messages, and found that Jackson was ignorant of anything beyond basic programming. Somehow, he believed the singleton would prevent state from being shared. Commit messages spelled it out: “Used a singleton to avoid shared state for concurrency.”And so Martin spent a few months improving the system by removing the singleton and mutexes, and generally cleaning up the tests’ code. During testing, Jackson’s shared state woes never surfaced, and when Martin was finished the test suite scaled very well by the number of VMs. Most of the spurious test failures simply disappeared and the entire suite ran in a fraction of the time.And now Martin understood why Jackson was no longer with the company. His solution for dealing with concurrency problems from “potential” shared state was to rewrite the framework to use “assuredly” shared state. [Advertisement] Atalasoft’s imaging SDKs come with APIs & pre-built controls for web viewing, browser scanning, annotating, & OCR/barcode capture. Try it for 30 days with included support.

C++ is a language with a… checkered past. It’s grown, matured and changed over the decades, and modern C++ looks very little like the C++ of yesteryear. Standard libraries have grown and improved- these days, std feels nearly as big and complicated as parts of Java’s class library.One useful function is std::toupper. Given a char, it will turn that char into an upper-case version, in a locale-aware fashion. What if you want to turn an entire string to upper-case?You might be tempted to use a function like std::transform, which is C++’s version of “map”. It alters the string in-place, turning it into an upper-cased version. With a single line of code, you could easily convert strings to upper-case.Or, you could do what Tomek’s highly-paid consultant did.

In a good organization, people measure twice and cut once. For example, an idea is born: let's create a data center that is set up properly. First, you figure out how much equipment is needed, how much space is required and how much power is needed to run and cool it. Next, you size back-up batteries and fuel-powered generators to provide uninterruptible power. And so forth.In a good organization, each of these tasks is designed, reviewed, built, tested and verified, and approved. These things need to be right. Not sort-of right, but right!Close only counts in horseshoes, hand grenades and thermonuclear war.Here's a tale of an organization doing almost everything right... almost.In the late noughties, Mel was working at something that wasn't yet called DevOps at a German ISP. It was a pretty good place to work, in a spanking new office near the French border, paid for by several million customers, a couple of blocks from one of the region's largest data centers that housed said customers' mail and web sites. The data center had all kinds of fancy security features and of course a state-of-the-art UPS. 15 minutes worth of batteries in the basement and a couple of fat diesels to take it from there, with enough fuel to stay on-line, in the true spirit of the Internet, even during a small-time nuclear war. Everything was properly maintained and drills were frequently held to ensure stuff would actually work in case they were attacked or lightning hit.The computing center only had a few offices for the hardware guys and the core admin team. But as you don't want administrator's root shells to be disconnected (while they were in the middle of something) due to a power outage either, they had connected the office building to the same UPS. And so as not to reduce the backup run time unnecessarily, there were differently-colored outlets: red for the PCs, monitors and network hardware, and gray for coffee makers, printers and other temporarily dispensable devices that wouldn't need a UPS.Now Germany happens to be known as one of the countries with the best electric grid in the world. Its "Customer Average Interruption Duration Index" is on the order of 15 minutes a year and in some places years can pass without so much as a second of blackout. So the drills were the only thing that had happened since they moved into the office, and not being part of the data center, they weren't even involved in testing. The drills were frequent and pervasive; all computer power cut over to batteries, then generators, and it was verified at the switch that all was well. Of course, during the tests, land-line power was still present in the building on the non-UPS-protected circuits, so nothing actually ever shut off in the offices, which was kind of the whole point of the tests.When it inevitably hit the fan in the form of an exploding transformer in a major substation, and plunged a quarter million people into darkness, the data center kept going just fine. The admins would probably have noticed a Nagios alert about discharging batteries first, then generators spinning up and so forth. The colleagues in their building hardly noticed as they had ongoing power.However, on Mels' floor, the coffee maker was happily gurgling along in the silence that had suddenly fallen when all the PCs and monitors went dark.It turned out that their floor had been wired with the UPS grid on the gray outlets from the beginning and nobody had ever bothered to test it. [Advertisement] Otter enables DevOps best practices by providing a visual, dynamic, and intuitive UI that shows, at-a-glance, the configuration state of all your servers. Find out more and download today!

"Shortly after one of our dear colleagues left the business for pastures new, we started to find some messages they left behind," Samantha wrote.

We write a lot about unhealthy workplaces. We, and many of our readers, have worked in such places. We know what it means to lose our gruntle (becoming disgruntled). Some of us, have even been tempted to do something vengeful or petty to “get back” at the hostile environment.But none of us actually have done it (I hope?). It’s self defeating, it doesn’t actually make anything better, and even if the place we’re working isn’t, we are professionals. While it’s a satisfying fantasy, the reality wouldn’t be good for anyone. We know better than that.Well, most of us know better than that. Harris M’s company went through a round of layoffs while flirting with bankruptcy. It was a bad time to be at the company, no one knew if they’d have a job the next day. Management constantly issued new edicts, before just as quickly recanting them, in a panicked case of somebody-do-something-itis. “Bob” wasn’t too happy with the situation. He worked on a reporting system that displayed financial data. So he hid this line in one of the main include files:

In most companies, business growth leads to greater organizational complexity. With more clients to juggle, owners must increasingly delegate less important tasks to a growing pool of employees and lower management. With time, the org charts grow from simple diagrams to poster-sized trees. Departments and SBUs become separate entities. What was once a three-man startup morphs into the enterprise behemoth we all know and love.For Vandelay Books, however, this was not the case. Despite becoming one of the largest book distributors in the state, the owners—a husband and wife pair of successful enterpreneurs—kept a firm grip on every single aspect of business. While it helped to alleviate many of the problems found in large enterprises, it also meant several departments were severely understaffed and barely managed. The internal software department, in particular, consisted of a single developer and an occasional intern or contractor ever since the company had started operating.While it looked like a recipe for disaster, Vandelay Books had two redeeming features: they were hiring, and paying handsomely. For desperate George, who'd nearly exhausted his unemployment emergency fund, all it took was to shake hands with the couple and sign the contract. From there, it was on to a brighter future, assisting with the migration of the company's software suite from an ancient and unsupported database to something more modern.After setting up his desk and workstation, the owners led George to a grey-haired, scruffy man sitting at the other end of the room."This is Doug, our lead developer," the husband introduced."Pleasure to meet you." Doug stood and shook George's hand, smiling from ear to ear. "Have you settled in already?""I think so, yes," George said. "All I need is a copy of the database to work with.""I'll get it for you as soon as possible." Doug turned towards his PC and started typing.After exchanging a few more words with the owners, George left for his desk, expecting the database copy to be waiting in his inbox.An hour later, George had grown impatient. What's taking him so long? he wondered. It shouldn't take more than a few minutes to run a build script.He decided to remind Doug about the copy. Doug was at his desk, furiously whacking at the keyboard and grinning to himself."Hi, how's that database coming along?" George asked, trying to hide his irritation."Almost done!" Doug took his hands off the keyboard, his lips still curved in a beaming smile. "Sorry to keep you waiting, there's a lot of tables in here.""What do you mean, lots of ...?" George began, but a quick glance over Doug's shoulder answered his question. Instead of a shell window or a database IDE, Doug's display consisted of nothing but a large Notepad window, with the cursor placed in the middle of an unfinished CREATE TABLE statement.No wonder it takes so long when you're typing the entire database out! George barely held back from screaming at his coworker. Instead, he stepped away as casually as possible and opened his IDE, morbidly anticipating the horrors lurking in the codebase.A quick skim through the code made George realize why Doug was always smiling. It was the blissful smile of complete and utter ignorance, the smile of someone who'd risen far beyond their level of incompetence and was now eternally grateful for every day things didn't fall apart.And the code looked like it could fall apart any minute. Over 300,000 lines had been thrown together without rhyme or reason. Obviously, Doug hadn't heard of such modern concepts as "layers" or "structured code," instead opting to hack things together as he went along. Windows API calls, business code, inline strings and pieces of SQL—everything was shoved together wherever it would stick, creating the programming equivalent of a Katamari.George sat there, pondering all the wrong decisions in his life that'd led to this Big Ball of Mud, until Doug appeared beside him and shook him out of his stupor."Oh, I see you're already looking at the code!" Doug said. "It's not that hard to understand, really. I even have a few flowcharts that could help you out! Anyway, you just need to go through each of these commands, one by one—remember, it's not really SQL—like here, when it says SELECT with no FROM like this? It's actually a DELETE. And so on. Simple, isn't it?"His head spinning, George decided to risk it. "Actually, I was thinking we could structure it a little. Separate those calls out, make a few functions that read or insert records—""I beg your pardon?" Doug's smile faded, giving way to the surprised look of a deer in headlights."I mean ... uh, never mind."Sure, the migration would take a hundred times longer Doug's way—but as long as the paychecks cleared, it wasn't worth it to George to fix the unfixable.Days passed slowly at Vandelay Books, and George's heroic efforts slowly paid off. The code was still terrible despite numerous attempts to improve it when Doug wasn't looking, and the migration wasn't even close to being completed, but George could finally pay his bills and refill his accounts. Once in a while, the owners would stop by for a friendly chat. Between that and the relaxed atmosphere, George began to enjoy the company, if not the job he was tasked with.Eventually, during one of the conversations with the owners, George felt confident enough to mention that there was a way to get the migration done faster and more efficiently. He hoped they'd be able to convince Doug to let him have more freedom with refactoring the code, or at least fixing some of the most offensive spots.Instead, all he got were puzzled looks and a long, uncomfortable silence.The next day, the husband approached him as soon as he entered the office."George." The owner's voice was dry and stern. "We've discussed what you said yesterday with Doug, and we've decided we won't be needing your services anymore. Please clear out your desk by today."George didn't bother arguing. He quietly packed his things, said his goodbyes, and headed back home to polish his resume again. And although he soon found a job at a much more sanely managed company, he often wondered if Doug were still migrating the application one query at a time—and whether he was still able to smile. [Advertisement] Otter enables DevOps best practices by providing a visual, dynamic, and intuitive UI that shows, at-a-glance, the configuration state of all your servers. Find out more and download today!

Many times, when we get a submission of bad code, we’re left wondering, “what else is going on here?” Sometimes, you think, “if only I knew more, this would make sense.” More often, you think, “if I knew more, I’d be depressed,” because the code is so clearly bad.For example, Devan inherited a report, built using SQL Server’s Reporting Services Report Builder tool. Now, this tool is not intended as much as a developer tool, as a “if you can use Excel, you can make a report!” It uses Excel-style functions for everything, which means if you want to have branching conditional logic, you need to use the IIF function.Just don’t use it like this.

"The date is in the past and there is no time zone specification," writes Hugo K. "But apart from that, everything in this invitation is clear as...verterem mediocritatem?

Port-au-Prince, I wanna catch a glimpse ...Summer's winding down, and we're inexorably approaching the fall. Did you take a vacation this year, reader? Maybe you went to the beach; or maybe you live on the beach and you went to the mountains instead, as I did as a girl. Wherever you may have gone, odds are it was a tourist destination. Do you ever wonder what they get up to the rest of the year?Alexi grew up in just such a tourist town, a little oceanic getaway that was a sleepy ghost town for most of the year, propped up by the brief yet intense tourist season. Her last year of high school, she tried desperately to find a co-op position, but her options were bleak and limited. Finally, she landed the only job she could: the IT guru for the local community college.At first, it wasn't so bad. She spent much of her time reading books in the office, waiting for the hapless student with wifi troubles or the clueless teacher who needed a password reset. The highlight of her career was the day her senior tech, Aaron, turned off Spanning Tree protocol on a router and then flipped it all back on at once, causing a small fire in the broom closet they were using as a server room.But for the most part, her days were quiet. Almost ... too quiet.Jack was a department head, one who was well known by the IT staff. When he stopped by, Aaron immediately ducked into the broom closet. Alexi frowned briefly, but by the time she turned around, she was ready with a polite expression and her asshole-handling kill-'em-with-kindness tone. Her time in retail had prepared her for such a customer."Can I help you, sir?""Yes, I'm having some trouble with this newfangled Internet classroom," Jack said. "Can you help me?"No cursing, sputtering, or calling her useless? Then why was Aaron hiding?"Of course," Alexi replied. "What seems to be the trouble?""Well, I set up the microphone and camera just like your instructions said, but my students say they can barely hear me. I even turned up the volume, and nothing."Now suspecting this to be the oddest prank ever, Alexi launched into the standard bevy of questions. "What kind of microphone are you using?""I have a broadcast microphone from the telecommunications department, plugged into about 300 feet of cable."That was weird, but not unheard of; there was plenty of old equipment floating around. "All right, and where does the cable plug into?" she asked, expecting an audio interface of some type to be involved."What do you mean?" Jack asked, a polite yet puzzled expression adorning his face."Well, you said there was 300 feet of cable, right? It has to be plugged into something.""I thought it was wireless."Wireless? With that long of a cord? "No. That's why it has 300 feet of cable ..."Sensing that they were both confusing each other more than before, Alexi closed her laptop and asked the gentleman to show her the setup.The classroom Jack was using was a large lecture hall, complete with a chalkboard and podium. There was a desktop machine sitting under the podium, but Jack had elected to use his own laptop on top of the podium instead, with the camera clipped to the hinge. He demonstrated for her that he was speaking loudly enough as he dragged the microphone, entirely untethered, around the stage area.A 300-foot tail of black cable dutifully followed him to and fro, but surely was not capable of conveying sound to his laptop. The crappy built-in microphone on the laptop itself, however, was more successful in picking up his voice. [Advertisement] Infrastructure as Code built from the start with first-class Windows functionality and an intuitive, visual user interface. Download Otter today!

Good intentions are never enough. If they aren't coupled with the wisdom to follow through properly, they can result in a horrible mess. Today’s Anonymous submitter has learned this the hard way:

Old Peter’s company has a legend. It has been passed down through generations of programmers and staff through an oral tradition. Oh, from time to time, someone would be inspired to record the tale for posterity, but inevitably, the hard copy was recycled, the digital copy was lost.It was 1982, and the German tech industry was booming. Old Peter’s company manufactured a line of 8-bit computers that were targeted towards businesses. Their targets were generally larger companies and government organizations- like Frequenzhof Busgesellschaft.Frequenzhof Busgesellschaft - the bus company of Frequenzhof - served a bustling metropolis in the heart of Germany. They had a growing ridership and a growing need to automate their accounting processes. They bought one cabinet-sized 8-bit microcomputer and if they liked it, planned to buy another. With the addition of tape drives and other accessories, the Busgesellschaft was going to be a very valuable client.So when the director of the bus company called support, people jumped to solve their problem. Unfortunately, it was easier said than done:“When we use your computer to run our weekly batch process, all of our radios stop working. We cannot communicate with our drivers! This is unacceptable!”The technician tried to clarify the problem. “I’m sorry, but… if you run an accounting job, the radios stop working? Our computer doesn’t have anything to do with your radios!”“And yet, when we turn on your computer, the radios stop working! We think it must be interference.”“That… that really can’t be.” A computer, of course, does throw off some electromagnetic fields- anything using electrical current did. But to kill a voice radio network? That seemed implausible.The technician gathered more details, and then escalated. Management didn’t want to lose future sales, and got defensive about their system. It relatively well shielded, and the frequencies it generated- all harmonics of the 1MHz chip running in the system, or of the 50Hz mains power- were nowhere near common voice frequencies.Over the next few months, a series of radio and electronics technicians examined the situation. They tested a computer right as it came off the assembly line, proving that it didn’t radiate any significant EM noise, especially not at the bands the radios used (≈ 26MHz - 27MHz). The company, eager to keep their customer happy, replaced the “defective” computer with a fresh one, confident that this would solve the problem.It didn’t.Frequenzhof Busgesellschaft grew increasingly concerned. This computer was an expensive capital asset, and they couldn’t use it without cutting communications with their drivers- what if there were an accident or an emergency? Fingers were pointed, blame was doled out, and the Busgesellschaft threatened to take their business elsewhere.The computer company begged for one last opportunity to send in a technician, because obviously there was something extremely unusual going on. “This shouldn’t be happening,” they agreed, “but work with us to fix it.” So they sent Fritz out to the customer site.Fritz was an expert in radio systems. Rumor had it that, before he entered the private sector, he had been working in signals intelligence, spying on the Russians. Whether or not there was any truth to the rumor, he was considered one of the best in his field. If he couldn’t solve the problem, no one could solve the problem.When Fritz’s car pulled up to the bus company’s building, he had a suspicion as to what might be wrong. When he entered the computer room, and saw the computer was positioned against an exterior wall, he knew what was wrong. This was, after all, 1982. In Germany. Frequenzhof Busgesellschaft was housed in a late 1960s slab of brutalist concrete. Hidden inside of that concrete was structural rebar. The computer’s tiny EMF resonated with the rebar grid, creating a chain of harmonics that laid static over the radio system, killing communication.Fritz’s solution was as elegant as his diagnosis: relocate the computer to the middle of the room, far enough away from the rebar that it couldn’t couple with it. They followed his instructions, and it worked perfectly- even when they did get around to adding that second computer.[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!

Paulo F was doing a little online banking with one of the largest banks in Brazil. He wanted to buy a pre-paid debit-card. He chose a value from the drop-down, for example R$50,00- fifty Reals. The site promised him a card loaded with R$200,00. It didn’t matter what he chose, the site offered him a completely different value.Curious, he pulled up the element in the inspector.

"All the news that's fit to print, eh?" Jared S. writes.

September 17, 20XXDear Susanna,I hope the fresh start of a new college semester finds you well. I have great news! I've just signed a 2-year contract with one of the world's largest investment banks, and will be helping to maintain a next-generation trading platform.This is the sort of programming assignment I've dreamt of since being in your shoes, imagining what post-college life might bring. In these first few years, my naiveté was rewarded with arcane VB6 apps and moldering SharePoint servers—but no more! I can't wait to start.I shall log my experiences for your edification. Whenever you feel discouraged, remember my example and know it won't be much longer before you, too, realize your dreams.-FredericDay 1. I expected the words to flow from my fingers with electric thrill, dear sister. Instead, I write to you now in a mood of deep bemusement.The morning began well enough. My cubicle, laptop, phone, and network credentials were furnished to me straight away: a true rarity in the business world. Then my new boss took me to meet the genius behind the cutting-edge trading platform I'd been told so much about. He's a man they simply call The Architect.The moldy smell of expired sandwiches hung about his cubicle. The man himself had sharp, beady eyes and a patronizing smile. He's either plumbed the universe's darkest machinations firsthand, or he believes he has.My boss asked The Architect to give me a quick preview of the trading platform. I was genuinely excited to see what cutting-edge, next-gen software looked like.The Architect obliged, remoting into the server hosting the application and launching it. On his monitor, the splash screen appeared, displaying a Greek soldier posing like Zeus. I realized he looked familiar.It was The Architect's face Photoshopped onto a warrior's body.A spine-curling cringe settled over me, which I struggled to suppress. This was no sign of world-class software, rather the opposite. I don't recall anything else. Now I'm alone in my cube, shuddering in dread of all that's yet to come.No, I mustn't succumb to pessimism. Perhaps The Architect simply has a bad sense of humor. Worry not for me, Susanna. The next time I write, it will be in much higher spirits.Day 2. Can this be real? I've sat down with my first coffee and have barely begun to look into the code base, and I'm already horrified by what I see. The main file, which is just for bootstrapping, contains over 10,000 lines of spaghetti code. The comments and log files contain multiple instances of Who cares?, Bah, and other expressions of futility.The other developers are starting to filter into the office now. Peeking over the cubicle walls, I see plainly the hopelessness in their eyes.I feel as though I stand at the edge of an abyss. Though I can't see the vast chasm below, I'm aware it's terribly far down, and the darkness stretching in between is fraught with uncertainty.Day 5. It gets worse. Further dealings with The Architect's code have revealed more horrors, Susanna, things you must promise me never to permit within your own software projects:

Comments are rough. I always take the stance that code should always be clear enough to explain what it does, but you’ll may need a comment to explain why it does that. I recently attended a talk by Sean Griffin (maintainer of Rails) who argued that commit messages should accomplish that goal, since they can contain far more content than a code comment, and while code comments and code can drift apart and cease to be accurate, commit messages are always linked to the point-in-time when they were made. Donald Knuth, on the other hand, might argue that code should annotate comments instead of the opposite.Regardless of the method we use, I think most of us would agree that code needs some documentation in the same way it needs tests: it should exist, but we don’t want to have to create it.Stephania found herself in the situation where she was creating the documentation. In this case, I don’t think we have to worry about the comment ceasing to be an accurate description of the code. This comment doesn’t need to be linked to a specific point in time- it tells us everything we need to know about the entire codebase.

Let’s talk about maintainability.Those of you that know me know that in my civillian identity, I work as a SQA professional. QA gets a bum rap sometimes; manual functional testing can be one of the most boring parts of software engineering, but while there’s plenty of button-pushers who will be happy to poke at an application for minimum wage, there’s a lot more to quality than simply functionality. One of the commonly overlooked aspects is maintainability: the ease with which changes can be made to the software system.Now, maintainability can be measured. You can track how long it takes to discover the root cause of an issue, or how long it takes to work a simple enhancement request. You can track the number of groans or “WTFs” per minute in code review. You can track the cylcomatic complexity of the codebase or, if you’re a masochist, the Halstead complexity. But there’s a number of informal, “gut feel” warning signs you can use to tell if your application is maintainable. Here’s a sampling I’ve collected from various programmers in the industry. I like to call it Your code might be unmaintainable if…Your code might be unmaintainable if the programmers give it nicknames like “the monster” or “the barge” or utter the words “there be dragons”Your code might be unmaintainable if you can tell how old a file is by what revision of the coding standards it follows – within 3 seconds of opening the fileYour code might be unmaintainable if requesting a dependency map from the database server chugs for 30 minutes then crashes with an “out of memory” exceptionYour code might be unmaintainable if you’re the most senior dev on the team… six months out of uniYour code might be unmaintainable if you can’t localize the text of dropdowns for a new locale because that would break the existing 400-line if-else chain that lists out every localized string and keys functionality based on itYour code might be unmaintainable if management dictates the design of the codebase – down to the nitty-gritty tactical level. Bonus points if the manager is a non-technical VP who responds to criticism by firing the developer on the spot.Your code might be unmaintainable if half the variable names are in a different language and nobody’s quite sure whichYour code might be unmaintainable if you’re serving 20MB of CSS files on every requestYour code might be unmaintainable if your dependency graph is unreadable when printed on a single sheet of 8.5“ x 11” paper. Or a single sheet of A4. Or a single sheet of A3.Your code might be unmaintainable if your variable naming “convention” is u734, u1234–2, u623, etc… and variables all change names between filesYour code might be unmaintainable if you have a single function webservice with 17 layers of abstraction between the entry point and where the business logic lies. Apparently the developer had never heard of YAGNIYour code might be unmaintainable if you re-order the properties of an object and the code breaksYour code might be unmaintainable if Microsoft Access forms a critical part of your business workflow. Or Microsoft Excel. Bonus points for unreadable Excel macros that fall victim to other traps in this article Your code might be unmaintainable if it includes the line #defined ONE_HUNDRED 100 unironicallyYour code might be unmaintainable if you find the source code! …in a folder marked DEV_BACKUP_2013Your code might be unmaintainable if you can’t find the malfunctioning bit of code because it’s monkeypatched onto a class you control from god knows whereYour code might be unmaintainable if you go to debug a production issue and not only can you not reproduce, the entire functionality isn’t present in the codebase on the development servers.Your code might be unmaintainable if you go to debug a production issue and not only can you not reproduce in dev, you can’t find the functionality even in production. Bonus points if you finally chase down a series of redirects and end up on some server somewhere, named after a flower, that was meant to have been decomissioned years ago. Double bonus points if you’re pretty sure it shells out to a Minecraft server in the process.Your code might be unmaintainable if it’s full of comments that simply read //BUGBUG. Or //TODO (with no further explanation)Your code might be unmaintainable ifthere’s a header at the top of every page served up in production that reads

Let’s talk a little bit about front-end development. Even at its best, it’s terrible- decades of kruft mixed with standards and topped off with a pile of frameworks that do their best to turn this mess into a cohesive whole.Jameson is suffering through this, and his suffering is the special level of front-end suffering known as “Angular”. Angular bolts Model-View-Controller semantics on top of HTML/JS/CSS, and its big selling point is that it makes two-way data-binding trivially easy.Under the hood, that two-way data-binding is implemented using a concept of “watchers”. Essentially, these abstract out the event handling and allow Angular- or your own custom code- easily detect changes in the various UI widgets. These watchers also implement nice features, like automatically detecting if a form field is “$pristine” or if the form (or any given field) happens to be “$valid”.So, for example, if you wanted to have a submit button automatically disable itself if the form were untouched or invalid, you might do something like this:

"Look like Microsoft really, really wants me to celebrate Windows 10's birthday," wrote Andrew.

As web developers, we spend a fair amount of time protecting our valuable server resources from the grasping tentacles of Internet ruffians and malfeasants. Occasionally, we're tasked with exposing data endpoints to the public Internet. This is generally a carefully crafted solution of whitelists, authentication, authorization, escaping input, limiting access and other protective measures.But we are not, and cannot be, the domain experts for the system. There is always an inherit tension between our area of expertise, namely software development, and the needs of our business users for their own purposes. Never is this more true than when the problem domain is something that borders on our own area of expertise.Kit was a quantitative analyst; he knew enough Ruby to be dangerous, but nothing of software engineering as a discipline. Nevertheless, his understanding of the problem domain was deep and thorough. He knew what he needed to accomplish, and enough of how to do so that all he required from Karla’s company was server maintenance for his analysis and the accompanying “big data” SQL database. He was spending more time than he wanted to be administrating the machine sitting in his closet. Since his group had an existing relationship with Karla’s company, it made sense to delegate to her team.Karla was tasked with examining the code to ensure it would pose no threat to their other existing clients. The code was typical of new programmers who understand the problem better than the solution: inconsistently spaced, with a coding style that matched no known format, and weak in places—but it would work, and it wasn’t just a rootkit disguised as an app. Karla was about to advise accepting the code when something caught her eye: it was designed to take in POST requests and execute them as dynamic SQL queries.

Let’s say you have a collection of objects which contain geographic points. You want to find a specific item in that collection, and then extract the lat/lon of that item. You might write code like:

If you get the rare luxury to start a new project from scratch, there's something deep down inside you that makes you want to do it right. You pick the right people, equipment and tools so that you have the best chance of success. Unfortunately, sometimes incorrect decisions are innocently made and a technical time bomb is placed in the code.About 20 years ago at Big Money Inc., such a project was started and such a mistake was made. In this case, the mistake revolved around choosing a messaging platform that failed miserably when asked to pump more messages than was intended. The original developers knew not of this otherwise widely-known limitation.Compounding things was the choice of implementation. Usually, when you build a transport layer, you do something like this:

I did a brief contract with Hershey, the candy manufacturer, once. The biggest thing I recall from the experience was that they had bowls full of candy all over the place. You could just grab them by the handful.I bring this up, because Brenda worked for a pharmaceutical company, and I can only assume that there are bowls full of random drugs scattered around, and someone has been chowing down on them by the handful. That’s the most logical explanation for the following code:

Nick writes, "Well, it just goes to show you - don't under estimate the cultural significance of modal windows."

Imagine you’re a financial institution. You’ve built an application that processes financial transactions, and there are a number of flags that need to be set as constants to determine application behavior.You might choose to write code like this:

It was Brian’s first day at AutoDetective, a website for comparing listed car prices vs. blue book values. His work inbox was overflowing with style guides, best practices, and notes from the dozen or so other developers he would be working with. His interviewer, Douglas, had mentioned that the site ran on a substantial chunk of legacy code, but Brian had experience with plenty of old code.He spent most of the day digging through the source, getting a feel for the in-house development style. It didn’t take long before he noticed how … off the code was.It wasn’t just legacy code. It was obtuse legacy code.Just Don’t Touch ItDouglas came to debrief Brian at the end of the day. Brian explained how he spent the afternoon going through the codebase, looking for a project to get his hands wet. “There’s a lot of inefficient code,” he said. “I figured I’d fix something small.” He pointed to a bit of code:

I took my first official programming class circa 1997, and that year was notable, only because it was the last years that class was taught using Turbo Pascal. In future years, it was taught in C++. For the teacher, this was quite the transition. To help her make the transition, at the end of the course, she spent a few days teaching us basic C++, so she’d be more ready for the following class, and we got a little bonus education.As far as I know, future runs of the class went just fine. I bring this up, because Frank had some co-workers who needed to make the exact same transition, from Turbo Pascal to C++. They may have done it a bit less gracefully. When reviewing some of the C++ they wrote, Frank spotted lots of code like:

In this world, there are those with common sense, and there are managers. In the world of high finance, there are only those with power and those without it. Those who have power make decisions - regardless of their familiarity with the relevant subject matter, or their ability to prioritize things involved in the decision. Those who don't have power (aka: us) live with the aftermath.James T. joined a major financial company. Because they have over $1B in revenue a year, he was under the impression that these folks knew what they were doing. They paid very lucrative salaries. They all seemed intelligent. They talked a good game about best practices and doing things right. They hit all the right buzzwords during the interview.What James didn't realize is that they were power brokers who used words without understanding what they actually meant.We do Modular Development. Translation, each person works in a vacuum to build their own little modular piece of the system. There is no need to talk of interfaces because management doesn't know there's a need for different pieces of the application to communicate with each other. It just has to work. (Magic happens here).We design our programs so that they lend themselves to code reuse. Translation, find some piece of code that is close to what you need, make whatever changes are necessary and cut-n-paste it into the new program.We discuss different approaches and the Best Idea Wins. Translation, the boss has the best idea because he has the most experience, so we do it his way.We build Frameworks. Translation, a framework is just an application to perform a certain task. It does not need to be generic because it only needs to do one or two things, so we just hard-wire everything.OK, so programming application-specific code might not be the antithesis of framework development, but it's close enough. When trying explain the value and difference of framework code to application code his boss literally asked Why would anyone ever need that?As it turned out, most of their "developers" were really engineers and traders. Like most businesses they're ingrained into their current paradigms. Like some engineers, they're very resistant to doing things differently.So James is building his little single-purpose reusable module and has some questions about the specifics of what it's supposed to do. In response, his management advises him that the details are unknown at that point, but that he should forge ahead, and they'll figure out what it's supposed to do after he delivers it and they see if it's useful to the end users in production!Forget measure twice, cut once; these folks threw away the tape measure and grabbed a power saw, leaving mountains of scrap lumber all over the place. Then they wonder why it takes so long to get anything useful delivered. [Advertisement] Incrementally adopt DevOps best practices with BuildMaster, ProGet and Otter, creating a robust, secure, scalable, and reliable DevOps toolchain.

"I wonder how many packages end up in rural Alabama?" Andreas wrote.

Today, programmers, let us celebrate all the varied and wonderful facets of code commenting: an art that too few of our brethren bother with, and even fewer master. Those who do stand to leave their mark on untold generations to come!There are the comments that make us laugh out loud, as Hopsas illustrates:

In lieu of a traditional WTF, I want to use today’s post to talk about the real WTF, or at least the source of all the WTFs we get to write about: our readers.We’ve got great writers here, and every time I hit “publish” on one of their articles, I’m happy with what’s about to go out to the world. They do a great job building funny, entertaining narratives that highlight some of the unique challenges of working in IT. We get great support from our sponsors, who fund the site and keep it running.None of that would matter, though, without the raw materials: the submissions that we get from our readers. This site wouldn’t be possible without you. We love reading all of the submissions we get; even if we can’t turn them into a story, we read them all.No matter how creative or inventive our writers are, we could never create a character like Paula Bean, or come up with a solution like the ITAPPMONROBOT. We love our readers, and we’re happy with the years of support and each of submissions that we get.And we want more of your submissions. There’s a lovely little Submit Your WTF button on the side of the page. If you’ve been in this industry for more than five minutes, I know you’ve got a story that deserves to be told, and we here at TheDailyWTF want to hear about it. Submit early, submit often. You can submit completely anonymously, and we’re always happy to change details to help keep your anonymity (there are a few stories in our archives that I submitted anonymously, not that you’d ever know). Or, slap your name on there and gain whatever degree of Internet fame- or infamy- you’re looking for.So, thank you. Without our readers, without their submissions, we wouldn’t have much to do here. And don’t worry, we still have a WTF for you today. This comes from Molly, who’s inherited some filtering code.

Modern object-oriented languages tend to support the concept of “reflection”. Reflection lets you inspect an object and find out its methods and invoke them dynamically. If you’re building extensible frameworks where you’re handling objects where their type might not be known until runtime, it can be very useful. On the other hand, if you’re using a strongly typed language and find yourself in this situation frequently… you’re probably doing something wrong.For that reason, when Adam encounters calls to method.invoke() in Java programs, he gets suspicious. So, when he saw this:

SuperFast Performance Monitoring Systems was an ordinary, average production monitoring company, promising to keep an eye on web traffic and alert customers if they needed to scale up their cloud hardware to match incoming demand. Their core product was simple, straightforward, and solid, doing what it claimed to do without incident ... but it wasn't sexy. Enter Wile E. Coyote, Supergenius Programmer, hereafter called Will for short.Will didn't seem to be a bad programmer, at first. He was a little slower than he promised, but his task was a complex one: he was to generate multi-variable graphs of the performance of the apps, something your ordinary front-end programmer wasn't necessarily versed in. With a little help, he got the visualizations running. They were sleek, sexy, and downright spectacular, and they wowed the pants off the Marketing folks.The feature shipped, Will was given a certificate and a hat to reward him for going above and beyond, and sales went through the roof. Everyone was happy.Except ...It didn't start out terrible, not really. Of course, they dogfooded their own software, so they kept a close eye on the performance of the graph feature, but it was above and beyond the specs, so people gradually began ignoring that corner of the monitor.A month or so later, however, it wasn't spectacular anymore. And another month after that, it was looking sub-optimal. Sluggish, even. Nothing too bad, nothing that would piss off users—quite—but something to be concerned about."Not to worry, not to worry. It's probably just the disk I/O. I'll just optimize the caching algorithm a bit, we'll be back in tip-top shape." Will's excuse sounded plausble enough, and he dove right into it. And sure enough, the speed bounced back ... a little.Two weeks later, the performance gains were gone. There was obviously a problem, and it was only getting worse.Will didn't look quite as confident this time, but he dove into the project with only a little less gusto than before. He drove out to the datacenter to test network connections, he switched to a more highly optimized image generation library, he added more RAM to the database. Each change added just a bit more performance ... which was lost again the next week, or the week after that.Will wasn't getting any shiny certificates now. He was getting phone calls from department heads and emergency strategy meetings. He took to hiding in the breakroom with his laptop so people couldn't find him to ask for status updates. He lost weight. His hair went frequently unbrushed. All he did now was seek out this performance issue as the meter crept further and further into the "red zone". There was no getting around it: the feature was slow.Marketing started drafting up new sexy features to sell product, and gave them to someone other than Will. He was a pariah, accursed, unable to escape the burden of his past.Still, he perservered. It was SQL, he argued. The overhead from relational tables was eating up their performance, they needed to move to Mongo yesterday.Nobody was having it. Their other report visualization tools were working fine on SQL Server. What made his fancy graphic so different?Will became a shadow of his former self, always sulking in the corner during status meetings while mumbling about Cassandra. Finally, he cracked, and left the company for greener pastures. Nobody threw him a going-away party.A couple weeks after his departure, a coworker named Brad decided to take a look into the code himself. He was working on Marketing's newest idea, and wanted to learn from the "supergenius" who'd built the previous toy.There was a ton of filtering logic in the code. Concerned, Brad took a look at the DAO's query to get the user's information, the very first query in the series of operations that led from historic data to dynamic image:

"So, do I enter a number 0 to 65,535 or −32,768 to 32,767? What if my experience wasn't an integer? This is a really technical question for applying at a restaurant," writes Brennan.

Objects left in the garage or the attic tend to multiply. If you don’t clean them regularly, you find mysterious and inexplicable things have bred like rabbits. “Why is there a bag of marbles in this box, and when did I ever buy an ugly Christmas sweater?”Without regular refactoring, the same thing can happen to your code-base. Michal is finally taking a look at a bit of code that hasn’t been touched since 2001. The original developer has left the company, there’s no documentation, and the SVN history has long since been discarded.This leaves Michal with many questions. For example- why did the original developer pepper the code with dozens of calls to System.exit(0)? While that’s one way to end a Java program, it’s not the sort of thing you tend to scatter through the code-base like rice at a wedding. Even worse, though, the calls looked like this:

Jake eagerly stepped into his new job, grateful for more experience and new challenges, craving to learn new software stacks and see what his new company had to teach him about the world of software.They told him he’d be working on some websites, dealing with JavaScript, Node.js, JSON, and the like. It sounded pretty reasonable for web development, except for the non-technical interviewer’s comment that it was all “built on top of Subversion” which he assumed was a simple misunderstanding.Then he was thrust into a project using the company’s custom “JSON-based Domain Specific Language”, or JDSL. His boss told him to check out a copy of the project he’d be assigned to, and spend a week or two getting familiar with it. “Just ask anyone for help if you have questions, but you shouldn’t have any trouble judging from your experience.”So Jake began an SVN checkout…and long story short it took two days to complete. When he asked about it, his coworker Scott told him, “Oh that’s normal. Just play Solitaire or something until it finishes.”Two days later he started poking around. He started with a seemingly-innocuous file called “customers.json” and stared in confusion at its contents:

Reader Bernie submits for our approval this wonderful C# log base 2 implementation. He says: “We can distinguish two halves in that code. It looks like it was originally written for an unsigned 16-bit int, and later on extended for signed 32-bit integers.”This code reminds me of the change-sorting machine I have in my closet, which sorts change based on weight. That thing has no error handling if you try to sort, say, a huge boulder through it; it'd just fall apart. At least here, we have the assurance that the universe's biggest numbers all have a log base 2 of 31.

The year was 2006. Nelly Furtado was getting promiscuous, the Winter Olympics were in Italy, and Domino was an application developer for Rocketware, a company that produced multimedia applications. Back then, applications were still commonly distributed on CD-ROMs: small round disks of plastic that contained grooves that could be read by a specialized laser and interpreted as data. This was handy in a period when only 30% of Americans had broadband Internet.Rocketware had done some software for a government agency, which of course had been bundled with a support contract for updates, paid in advance. Maintenance for this application fell into Domino's lap, and he was soon asked to do a small update.Unfortunately, the software had been written by an infamous pair of numbskulls. Jessie and James had both been fired over a year previously for sheer incompetence, but they'd worked on this project together, meaning it was a ball of spaghetti held together by twine. Or at least, it probably was. Problem number one on Domino's plate: finding the source code.The application wasn't in any of the source code repositories; Jessie and James hadn't "believed in" version control. They would've been forced to use it during their tenure, but James had also done network support, and therefore had had access to the bare repositories when he'd been fired. Domino suspected that, in retaliation for being forced to use source control, James had deleted his projects before being escorted from the building.Thankfully, the pair had lacked access to the backup facility. Domino took the latest backup, added a new database, and implemented the fix: 5 hours of work, after about 3 hours of combing through backups to find the right version. Done and dusted. Right?Wrong. The agency quickly complained of features missing, of old bugs re-introduced. Clearly that wasn't the version that'd been burned onto the CD and mailed to them, but the source code for that version was nowhere to be found.Domino's boss, Giovanni, asked him to just go ahead and re-implement the missing features, see if he couldn't get things working to the agency's liking.Now, this application wasn't any old application. The source code consisted of about 10k lines of Lingo code, entirely undocumented of course, and another 10k lines of ActionScript 1.0. There were 20 files, hundreds of frames and clips, a handful of data conversion tools written in Pascal, an Access database, a V12 database, and even some Excel spreadsheets. It was the Wild West: a little of everything, held together with duct tape and prayers. Still, Giovanni insisted that Domino clean up this mess as best he could:

"Um, I'm not sure the programmers and the engineers were working together on this one," wrote Rob.

When you want to store data in Amazon’s S3 cloud-based storage, you have to assign that data a key. In practice, this looks and behaves like a filename, but the underlying APIs treat it like a key/value store, where the value can be a large data object.S3 is flexible and cost-effective enough that Melinda’s company decided to use it for logging HTTP requests to their application. These requests often contained large data files for upload, and those files might need to be referenced in the future, so a persistent and reliable storage was important.Each of these incoming HTTP requests had a request_id field, so a naive implementation of logging would be to write the body of the request to an S3 key following a pattern like requests/c418b58b-164d-4e1f-970b-ed00dea855b6. For a number of reasons, however, clients might send multiple requests using the same request_id. Since a logging system that overwrites old logs would be pretty terrible, they decided that each log file also needed an ID, so they could write them out with keys like requests/c418b58b-164d-4e1f-970b-ed00dea855b6/${x}, where ${x} was the ID of the log file.The developer responsible for implementing this decided that ${x} should be an auto-incremented number. This presented a problem, though: how on earth could they keep that index in sync across all of their API nodes?