The Daily WTF

Lena inherited some C++ code which had issues regarding a timeout. While skimming through the code, one block in particular leapt out. This was production code which had been running in this state for some time.

As is the case with pretty much any language these days, Python comes with robust date handling functionality. If you want to know something like what the day of the month is? datetime.now().day will tell you. Simple, easy, and of course, just an invitation for someone to invent their own.Jan was witness to a little date-time related office politics. This particular political battle started during a code review. Klaus had written some date mangling code, relying heavily on strftime to parse dates out to strings and then parse them back in as integers. Richard, quite reasonably, pointed out that Klaus was taking the long way around, and maybe Klaus should possibly think about doing it in a simpler fashion.“So, you don’t understand the code?” Klaus asked.“No, I understand it,” Richard replied. “But it’s far too complicated. You’re doing a simple task- getting the day of the month! The code should be simple.”“Ah, so it’s too complicated, so you can’t understand it.”“Just… write it the simple way. Use the built-in accessor.”So, Klaus made his revisions, and merged the revised code.

A great man once said "I used to be over by the window, and I could see the squirrels, and they were merry." As pleasing of a sight as that was, what if the squirrels weren't merry?Grady had an unpleasant experience with bushy-tailed rodents at a former job. Before starting at the Fintech firm as a data scientist, he was assured the Business Intelligence department was very advanced and run by an expert. They needed Grady to manipulate large data sets and implement machine learning to help out Lenny, the resident BI "expert". It quickly became apparent that Lenny didn't put the "Intelligence" in Business Intelligence.Lenny was a long-term contractor who started the BI initiative from the ground-up. His previous work as a front-end developer led to his decision to use PHP for the ETL process. This one-of-a-kind monstrosity made it as unstable as a house of cards in a hurricane and the resultant data warehouse was more like a data cesspool."This here is the best piece of software in the whole company," Lenny boasted. "They tell me you're really smart, so you'll figure out how it works on your own. My work is far too important and advanced for me to be bothered with questions!" Lenny told Grady sternly.Grady, left to fend for himself, spent weeks stumbling through code with very few comments and no existing documentation. He managed to deduce the main workflow for the ETL and warehouse process and it wasn't pretty. The first part of the ETL process deleted the entire existing data warehouse, allowing for a "fresh start" each day. If an error occurred during the ETL, rather than fail gracefully, the whole process crashed without restoring the data warehouse that was wiped out.Grady found that the morning ETL run failed more often than not. Since Lenny never bothered to stroll in until 10 AM, the people that depended on data warehouse reports loudly complained to Grady. Having no clue how to fix it, he would tell them to be patient. Lenny would saunter in and start berating him "Seriously? Why haven't you figured out how to fix this yet?!" Lenny would spend an hour doing damage control, then disappear for a 90 minute lunch break.One day, an email arrived informing everyone that Lenny was no longer with the company after exercising an obscure opt-out clause in his contract. Grady suddenly became the senior-most BI developer and inherited Lenny's trash pile. Determined to find the cause of the errors, he dug into parts of the code Lenny strictly forbade him to enter. Hoping to find any semblance of logging that might help, he scoured for hours.Grady finally started seeing commands called "WritetoSkype". It sounded absurd, but it almost seemed like Lenny was logging to a Skype channel during the ETL run. Grady created a Skype account and subscribed to LennysETLLogging. All he found there was a bunch of dancing penguin emoticons, written one at a time.Grady scrolled and scrolled and scrolled some more as thousands of dancing penguins written during the day's run performed for him. He finally reached the bottom and found an emoticon of a squirrel eating an acorn. Looking back at the code, WritetoSkype sent (dancingpenguin) when a step succeeded and (heidy) when a step failed. It was far from useful logging, but Grady now had a clear mission - Exterminate all the squirrels. [Advertisement] Otter - Provision your servers automatically without ever needing to log-in to a command prompt. Get started today!

We all have our little bits of sloppiness and our bad habits. Most of us have more than one. One place I'm likely to get lazy, especially as I'm feeling my way around a problem, is with magic numbers. I always mean to go back and replace them with a constant, but sometimes there's another fire you need to put out and you just don't get back to it till somebody calls it out in a code review.Then, of course, there are the folks who go too far. I once got a note complaining that I shouldn't have used 2*PI, but instead should have created a new constant, TAU. I disavow the need for tau, but my critic said magic numbers, like two, were disallowed, so I said "ciao" and tau is there now.Angela A, who's had some experience with bad constants before, has found a new one.

These days, it almost seems like most of the developers writing code for the Java Virtual Machine aren’t doing it in Java. It’s honestly an interesting thing for programming language development, as more and more folks put together languages with fundamentally different principles from Java that still work on the JVM.Like Kotlin. Kotlin blends functional programming styles with object-oriented principles and syntactic features built around writing more compact, concise code than equivalent Java. And it’s not even limited to Java- it can compile down into JavaScript or even target LLVM.And since you can write bad code in any language, you can write bad code in Kotlin. Keith inherited a Kotlin-developed Android app.In Kotlin, if you wanted to execute some code specifically if a previous step failed, you might use a try/catch exception handler. It’s built into Kotlin. But maybe you want to do some sort of error handling in your pipeline of function calls. So maybe you want something which looks more like:

Let’s talk a little bit about .NET’s TryParse method. Many types, especially the built in numerics, support it, alongside a Parse. The key difference between Parse and TryParse is that TryParse bakes the exception handling logic in it. Instead of using exceptions to tell you if it can parse or not, it returns a boolean value, instead.If, for example, you wanted to take an input, and either store it as an integer in a database, or store a null, you might do something like this:

Linda inherited an inner-platform front-end framework. It was the kind of UI framework with an average file size of 1,000 lines of code, and an average test coverage of 0%.Like most UI frameworks, it had a system for doing client side validation. Like most inner-platform UI frameworks, the validation system was fragile, confusing, and impossible to understand.This code illustrates some of the problems:

Business Intelligence is the oxymoron that makes modern capitalism possible. In order for a company the size of a Fortune 500 to operate, key people have to know key numbers: how the finances are doing, what sales looks like, whether they're trending on target to meet their business goals or above or below that mystical number.Once upon a time, Initech had a single person in charge of their Business Intelligence reports. When that person left for greener pastures, the company had a problem. They had no idea how he'd done what he did, just that he'd gotten numbers to people who'd needed them on time every month. There was no documentation about how he'd generated the numbers, nothing to pass on to his successor. They were entirely in the dark.Recognizing the weakness of having a single point of failure, they set up a small team to create and manage the BI reporting duties and to provide continuity in the event that somebody else were to leave. This new team consisted of four people: Charles, a senior engineer; Liam, his junior sidekick; and two business folks who could provide context around what numbers were needed where and when.Charles knew Excel. Intimately. Charles could make Excel do frankly astonishing things. Our submitter has worked in IT for three decades, and yet has never seen the like: spreadsheets so chock-full with array formulae, vlookups, hlookups, database functions, macros, and all manner of cascading sheets that they were virtually unreadable. Granted, Charles also had Microsoft Access. However, to Charles, the only thing Access was useful for was the initial downloading of all the raw data from the IBM AS/400 mainframe. Everything else was done in Excel.Nobody doubted the accuracy of Charles' reports. However, actually running a report involved getting Excel primed and ready to go, hitting the "manual recalculate" button, then sitting back and waiting 45 minutes for the various formulae and macros to do all the things they did. On a good day, Charles could run five, maybe six reports. On a bad day? Three, at best.By contrast, Liam was very much the "junior" role. He was younger, and did not have the experience that Charles did. That said, Liam was a smart cookie. He took one look at the spreadsheet monstrosity and knew it was a sledgehammer to crack a walnut. Unfortunately, he was the junior member of the engineering half of the team. His objections were taken as evidence of his inexperience, not his intelligence, and his suggestions were generally overlooked.Eventually, Charles also left for bigger and brighter things, and Liam inherited all of his reports. Almost before the door had stopped swinging, Liam solicited our submitter's assistance in recreating just one of Charles' reports in Access. This took a combined four days; it mostly consisted of the submitter asking "So, Sheet 1, cell A1 ... where does that number come from?", and Liam pointing out the six other sheets they needed to pivot, fold, spindle, and mutilate in order to calculate the number. "Right, so, Sheet 1, cell A2 ... where does that one come from?" ...Finally, it was done, and the replacement was ready to test. They agreed to run the existing report alongside the new one, so they could determine that the new reports were producing the same output as the old ones. Liam pressed "manual recalculate" while our submitter did the honors of running the new Access report. Thirty seconds later, the Access report gave up and spat out numbers."Damn," our submitter muttered. "Something's wrong, it must have died or aborted or something.""I dunno," replied Liam, "those numbers do look kinda right."Forty minutes later, when Excel finally finished running its version, lo and behold the outputs were identical. The new report was simply three orders of magnitude faster than the old one.Enthused by this success, they not only converted all the other reports to run in Access, but also expanded them to run Region- and Area- level variants, essentially running the report about 54 times in the same time it took the original report to run once. They also set up an automatic distribution process so that the reports were emailed out to the appropriate department heads and sales managers. Management was happy; business was happy; developers were happy."Why didn't we do this sooner?" was the constant refrain from all involved.Liam was able to give our submitter the real skinny: "Charles used the long run times to prove how complex the reports were, and therefore, how irreplaceable he was. 'Job security,' he used to call it."To this day, Charles' LinkedIn profile shows that he was basically running Initech. Liam's has a little more humility about the whole matter. Which just goes to show you shouldn't undersell your achievements in your resume. On paper, Charles still looks like a genius who single-handedly solved all the BI issues in the whole company. [Advertisement] Forget logs. Next time you're struggling to replicate error, crash and performance issues in your apps - Think Raygun! Installs in minutes. Learn more.

Jen was a few weeks into her new helpdesk job. Unlike past jobs, she started getting her own support tickets quickly—but a more veteran employee, Stanley, had been tasked with showing her the ropes. He also got notification of Jen's tickets, and they worked on them together. A new ticket had just come in, asking for someone to replace the DVI cable that'd gone missing from Conference Room 3. Such cables were the means by which coworkers connected their laptops to projectors for presentations.Easy enough. Jen left her cube to head for the hardware "closet"—really, more of a room crammed full of cables, peripherals, and computer parts. On a dusty shelf in a remote corner, she spotted what she was looking for. The coiled cable was a bit grimy with age, but looked serviceable. She picked it up and headed to Stanley's cube, leaning against the threshold when she got there."That ticket that just came in? I found the cable they want. I'll go walk it down." Jen held it up and waggled it.Stanley was seated, facing away from her at first. He swiveled to face her, eyed the cable, then went pale. "Where did you find that?""In the closet. What, is it—?""I thought they'd been purged." Stanley beckoned her forward. "Get in here!"Jen inched deeper into the cube. As soon as he could reach it, Stanley snatched the cable out of her hand, threw it into the trash can sitting on the floor beside him, and dumped out his full mug of coffee on it for good measure."What the hell are you doing?" Jen blurted.Stanley looked up at her desperately. "Have you used it already?""Uh, no?""Thank the gods!" He collapsed back in his swivel chair with relief, then feebly kicked at the trash can. The contents sloshed around inside, but the bin remained upright."What's this about?" Jen demanded. "What's wrong with the cable?"Under the harsh office lighting, Stanley seemed to have aged thirty years. He motioned for Jen to take the empty chair across from his. Once she'd sat down, he continued nervously and quietly. "I don't know if you'll believe me. The powers-that-be would be angry if word were to spread. But, you've seen it. You very nearly fell victim to it. I must relate the tale, no matter how vile."Jen frowned. "Of what?"Stanley hesitated. "I need more coffee."He picked up his mug and walked out, literally leaving Jen at the edge of her seat. She managed to sit back, but her mind was restless, wondering just what had her mentor so upset.Eventually, Stanley returned with a fresh mug of coffee. Once he'd returned to his chair, he placed the mug on his desk and seemed to forget all about it. With clear reluctance, he focused on Jen. "I don't know where to start. The beginning, I suppose. It fell upon us from out of nowhere. Some say it's the spawn of a Sales meeting; others blame a code review gone horribly wrong. In the end, it matters little. It came alive and spread like fire, leaving destruction and chaos in its wake."Jen's heart thumped with apprehension. "What? What came alive?"Stanley's voice dropped to a whisper. "The hardware virus.""Hardware virus?" Jen repeated, eyes wide.Stanley glared. "You're going to tell me there's no such thing, but I tell you, I've seen it! The DVI cables ..."He trailed off helplessly, reclining in his chair. When he straightened and resumed, his demeanor was calmer, but weary."At some godforsaken point in space and time, a single pin on one of our DVI cables was irrevocably bent. This was the source of the contagion," he explained. "Whenever the cable was plugged into a laptop, it cracked the plastic composing the laptop's DVI port, contorting it in a way that resisted all mortal attempt at repair. Any time another DVI cable was plugged into that laptop, its pin was bent in just the same way as with the original cable."That was how it spread. Cable infected laptop, laptop infected cable, all with vicious speed. There was no hope for the infected. We ... we were forced to round up and replace every single victim. I was knee-deep in the carnage, Jen. I see it in my nightmares. The waste, the despair, the endless reimaging!"Stanley buried his head in his hands. It was a while before he raised his haunted gaze again. "I don't know how long it took, but it ran its course; the support tickets stopped coming in. Our superiors consider the matter resolved ... but I've never been able to let my guard down." He glanced warily at the trash can, then made eye contact with Jen. "Take no chances with any DVI cables you find within this building. Buy your own, and keep them with you at all times. If you see any more of those—" he pointed an accusing finger at the bin "—don't go near them, don't try taking a paperclip to them. There's everything to lose, and nothing to gain. Do you understand?"Unable to manage words, Jen nodded instead."Good." The haunted expression vanished in favor of grim determination. Stanley stood, then rummaged through a desk drawer loaded with office supplies. He handed Jen a pair of scissors, and armed himself with a brassy letter opener."Our job now is to track down the missing cable that resulted in your support ticket," he continued. "If we're lucky, someone's absent-mindedly walked off with it. If we're not, we may find that this is step one in the virus' plan to re-invade. Off we go!"Jen's mind reeled, but she sprang to her feet and followed Stanley out of the cubicle, telling herself to be ready for anything. [Advertisement] Otter - Provision your servers automatically without ever needing to log-in to a command prompt. Get started today!

The Kansas City Developer Conference is this week, followed by PubConf. Between these two events on Friday evening is plenty of time for a TDWTF dinner, and that's exactly what we're planning!If you find yourself in Kansas City Missouri this Friday, for KCDC, PubConf, or perhaps because you live here, please come out to the Dubliner at 5:30 PM for dinner and a pint. I'll be there along with Martine Dowden and some TDWTF swag to give away. We'll talk software, discuss what we took away from the conference, and can head over to PubConf together.If you would like to join us at 5:30 PM CT on Friday, July 19 please contact me at @mrdowden (Twitter) or drop me an email: Michael (at) Andromeda16.com [Advertisement] Ensure your software is built only once and then deployed consistently across environments, by packaging your applications and components. Learn how today!

It’s old hat, but every function, every class, every code unit you write, should all have a single, well-defined purpose. “Do one thing, and do it well,” as it were.Of course, sometimes, it’s easier said that done, and mindlessly following that advice can lead to premature abstraction, and then you’ll have quite a mess on your hands. Still, it’s good advice, and a great design goal, even if you don’t head straight there.Marigold found some code which, well, has a long way to go. A looooooong way to go.

Noam and a few friends decided it was time for them to launch their own product. They were young, optimistic about their career, and had some opinions about the best way to handle some basic network monitoring and scanning tasks. So they iterated on the idea a few times, until one day the program just started hanging. At first, Noam thought it was just a hang, but after walking away from the machine for a few minutes in frustration, he discovered that it was just running really slow.After a little investigation, he tracked down the problem to the function responsible for checking if an IP matched a filter. That filter could contain globs, which made things a bit tricky, but his partner had some ideas about how best to handle them.

If a piece of software is described in any way, shape or form as being "enterprise", it's a safe bet that you don't actually want to use it. As a general rule, "enterprise" software packages mix the Inner-Platform Effect with trying to be all things to all customers, with thousands upon thousands of lines of legacy code that can't be touched because at least one customer depends on those quirks. There doesn't tend to be much competition in the "enterprise" space, so none of the vendors actually put any thought into making their products good. That's what salesbeasts and lawyers are for.Kristoph M supports a deployment of Initech's data warehouse system. Since this system is a mix of stored procedures and SSIS packages, Kristoph can actually read a good portion of the code which makes the product work. They just choose not to. And that's usually a good choice.But one day, while debugging, Kristoph decided that they needed a simple answer to a simple question: "For a SQLAgent Job, how do you create a backup of the database with the day appended to the filename?"SQLAgent is SQL Server's scheduling system, used for triggering tasks. SSIS is SQL Server's "drag and drop" dataflow tool, designed to let users draw data pipelines to handle extract-transform-load tasks.In this case, the SQLAgent job's first step was to launch an SSIS package. Already, we're in questionable territory. SSIS is, as stated, an ETL tool. Yes, you can use it to extract data, it's not really meant as a replacement for an actual database backup.The good news is that this SSIS package doesn't actually do anything to backup the database. Instead, it contains a single task, and it isn't a data flow task, it's a "Visual Basic Script Task". Yes, SSIS lets you run a stripped down Visual Basic dialect in its context. What does this task do?

Oliver works for a very large company. Just recently, someone decided that it was time to try out those “newfangled REST services.”Since this was “new”, at least within the confines of the organization, that meant there were a lot more eyes on the project and a more thorough than average code review process. That’s how Oliver found this.

It’s hard to do any non-trivial programming in C without having to use a struct. Structs are great! A single variable holds access to multiple pieces of data, and all the nasty details of how they’re laid out in memory are handled by the compiler.In more modern OO languages, we take that kind of thing for granted. We’re so abstracted from the details of how memory is laid out it’s easy to forget how tricky and difficult actually managing that kind of memory layout is.Of course, if you’re Jean-Yves R’s co-worker, letting structs manage your memory layout is beginner mode stuff.Jean-Yves was trying to understand why a bunch of structs were taking up huge amounts of memory, relative to how much they should take. Every bit of memory mattered, as this was an embedded application. Already, these structs weren’t actually stored in RAM, but in the flash memory on the device. They served as a database- when a request came in over Modbus or CAN or I2C, the ID on the request would be used to look up the struct containing metadata for handling that request. It was complex software, so there were a lot of these structs taking up flash memory.It didn’t take long to see that the structs were defined with padding to ensure every field fell on a multiple of 32-bits, which meant there were huge gaps in every struct. Why? Well, this is an example of how they’d search the database:

Alice's team was thirty developers, taking up most of the floor of a nondescript office building in yet another office park. Their team was a contractor-to-a-contractor for a branch of the US military, which meant a variety of things. First, bringing a thumb drive into the office was a firing offense. Second, they were used to a certain level of bureaucracy. You couldn't change a line of code unless you had four different documents confirming the change was necessary and was authorized, and actually deploying a change was a milestone event with code freezes and expected extra hours.Despite all this, the thirty person team had built a great working relationship. They had made their process as efficient as they could, and their PM, Doug, understood the work well enough to keep things streamlined. In fact, Doug did such a good job that Doug got promoted. Enter Millie, his replacement.Millie had done a stint in the Air Force and then went back to school for her MBA. She had bounced around a few different companies, and had managed to turn every job change into a small promotion. This was Millie's first time overseeing a pool of software developers, but she had an MBA. Management was management, and there was no reason she had to understand what developers did, so long as she understood the key performance indicators (KPI).Like the quantity of defects. That was a great KPI, because it was measurable, had a clear negative impact, and it could be mitigated. Mitigated with a process.After a few weeks of getting her bearings, Millie called a meeting. "Alright, everyone, I've been observing a little bit of how we work, and I think there may be some communication and organization issues, so I wanted to address that. I've looked at our current workflow, and I've made a few small changes that I wanted to review."On one side of the white board, she drew a bubble labeled "In Production". "This is where we want our code to be, right? Working, quality-controlled code, in production, with no defects." On the opposite side of the board, she added a bubble for "PCCB Ticket." "And any code change starts with one of these- the Product Change Control Board reviews an open ticket. They'll then turn that ticket into a Functional Requirement Document." Millie added another bubble for that.Alice had some questions already, but not quite about the inputs or outputs."Great, okay, so… we need to iterate on the FRD, and once the PCCB signs off we'll convert that to a System Requirement Document. Either a PM or a SME will decompose the SRD into one or more Work Packages."Millie continued scribbling furiously as she explained exactly what a work package was, as this wasn't currently a term in use at their organization. Her explanation wasn't terribly clear, as Millie explained it as the set of steps required to implement a single feature, but a Functional Requirement was a feature, so how was the Work Package (WP) any different than the FRD?"Please, hold your questions until the end, we have a lot to get through."Finally, once the Work Package was analyzed, you could create a "Ticket Lifecycle Document", a new document which would hold all information about all of the efforts put towards the PCCB ticket. Which meante the TLD contained all the WPs, which raised questions about the point of adding work packages. From the TLD to a new PCCB ticket- a "Ready" ticket, then finally those requirements could go onto a Release backlog and a release management plan could be created."Finally," Milile explained, "we're ready to write code." In the center of the board, she added a single bubble: "Code".And on and on the meeting went. The diagram grew. Lines kept getting added. Bubbles got inserted between existing bubbles. Arrows pointed to labels, or to bubbles, or maybe to arrows? By the end of Millie's meeting, it looked something like this."There, that lays out the correct pattern for getting our software to production, with a feedback loop that prevents defects. Any questions?"There weren't any questions at the meeting, no. But boy, were there questions. Loads of questions. Questions like, "What font should I use on my resume?" and "is it time to stop listing my VBA experience on my resume?"Over the next few months, under Millie's leadership, 17 developers from the 30 person team left the company, Alice among them. Every once in awhile, Alice checks the job listings for that company, to see if those developer positions have been filled. They're still hiring for software developers. Unfortunately, Alice hasn't seen any openings for a PM, so Millie is probably still there. [Advertisement] Continuously monitor your servers for configuration changes, and report when there's configuration drift. Get started with Otter today!

Animations have become such an omnipresent part of our UI designs anymore that we tend to only notice them when they're bad.Ben is working on an iOS application which appeared to have a "bad" animation. In this case, it's bad because it's slow. How slow? Well, they have a table view with ten items in it, and the items should quickly tween to their new state- position, text, colors all could change in this process. And it was taking four seconds.Four seconds to update ten items is a lot. Now, their application does have a lot of animations, and the first suspicion was that there was some ugly interaction between animations that was causing it to take a long time. But upon digging in, Ben discovered it wasn't the animations at all.

Jake works in Python. Python is a very flexible language, and Jake has some co-workers who like to exploit it as much as possible.Specifically, they’re notorious for taking advantage of how any symbol can be redefined, as needed. Is int a built-in function? Yes. But what if you want to have a variable called int? No problem! Just go ahead and do it. Python won’t mind if you do int = int(5).Sure, any linter will complain about the possible confusion, but do you really think this developer checks the linter output?Now, this particular block of code happens to be a test, which Jake provided because it’s one of the more head-scratching versions of this pattern, but it’s representative of this approach.

Christopher started a new job as a “full-stack” developer. Unfortunately, most of the developers are still on the “why do you need anything other than jQuery” school of front-end development, despite efforts to transition their UIs to Vue.This meant that Christopher didn’t do much backend, and ended up being the mid-level front-end dev, in practice if not in job title.One of the Vue components was a “Wizard” style component, which was designed to be highly configurable. You supply a JSON description of the Wizard process, and it would generate the UI to navigate you screen-by-screen. Since Christopher was new at the organization, he wanted to understand how the Wizard worked, so he started poking at the code.He got as far as the stepBack function before deciding he needed to rewrite it from scratch. Christopher assumed that stepBack could be as simple as popping the last element off the array of previous steps, and then update what’s currently displayed. That, however, isn’t what it did at all.

The interview was going well—as well as one could possibly expect. Alarik, the candidate, had a no-nonsense attitude, a high degree of precision to his speech, and a heavy German accent. He was applying for a job with Erik's company as a C# developer working on an inherited legacy codebase, and he'd almost earned himself the job. There was just one routine question left in the interview:"So, why did you leave your previous job?""Ach," he said, his face twisting with disgust. "It was my superiors. They did not wish to improve the codebase."This was the first red flag. Erik's company had a terrible codebase, littered with technical debt. He was all for improving it, but it had to be done carefully to avoid breaking their bread-and-butter application while they struggled to keep the company solvent. He'd been leading careful efforts to tackle the worst bits while still delivering new functionality. "Can you tell me more about this?" he asked, frowning just a touch."I was all set to develop unit tests for every unit," Alarik replied. "It would have saved effort in the long run, but the bosses did not see return on investment. It is always about money with them, never craftsmanship."Erik chuckled weakly. "Well, we're a small company, run by developers and former developers. We don't have MBAs here running the show, so we definitely appreciate craftsmanship. But I'll warn you off the bat, the product you'd be working on has no unit tests. We're working towards that, but we're not there yet."Another disgusted noise. "Tch. If you hire me, I will need time to improve this. Perhaps not the entire codebase, but at least the core functionality.""I appreciate your candor." And Erik did—it meant this leading candidate was pushed back to second place. After all, he might be a great developer, but dictating demands in the interview wasn't exactly a strong recommendation.They proceeded with the interview process, but their first choice fell through, so they ended up inviting Alarik back for a second interview. After all, not everyone who appreciates craftsmanship and prefers unit tests is necessarily inflexible."Do you have code samples we could look at?" Erik asked, hoping to convince himself the value of a good developer was worth some butting heads about priorities."Yes, yes, of course. Here, let me show you. I have brought you a unit test I wrote.""Great," said Erik, feigning some degree of enthusiasm. This again ..."This is a unit test for the Absolute Value function in the Math library," Alarik continued, pulling up the code with a few deft keystrokes.Please tell me it's just a sample, Erik thought. Does he think I don't know what a unit test is? Or does he really not trust the built-in absolute value function? What kind of person has a unit test for Math.Abs() pre-written on their computer? Will he tell me some war story about some platform where Math.Abs() failed to work on some edge case?!Erik mustered an insincere smile, sitting through Alarik's walkthrough. It was a well-written test, for certain, but he just couldn't shake the questions about why it was being shown in the first place. "This is a little simple. Do you have an example of a test you wrote for some actual business functionality?"."Ah, yes. Here is my test for `String.split`."Changing the subject, Erik asked about another sticking point: "You mentioned in our first interview that you wanted to break up class files that are too large.""Yes. No file should be over 400 lines."Erik thought back to one code file in their codebase that was over 11,000 lines, wincing a little. We're overdue to break this up, but I'd hate for this guy to come in and rearrange every one of our hundreds of files. "How strictly would you apply that rule to a legacy codebase?" he asked."It is good to be flexible," Alarik replied. "It's not a strict rule."Feeling relieved, Erik drilled further: "What if you found a class file that's a thousand lines long?""That I would break up, of course.""How about 500?""I would break it up.""What if there's no natural way to break it up?""There is always a natural way to break up complexity.""Well, how do you find that? Let's say you found a 11,000 line file. What steps would you take to break it up?""I would move blocks of code into other files."That did it. Erik thanked Alarik for his time, deciding to wait 24 hours and then give him the bad news. In rejecting him, Erik still felt guilty—he felt like the team was sloppy for not using unit tests and having a huge range of source code file sizes.No doubt we'll falter and fail, he thought sarcastically. It would serve us right for not employing the only person who could have taught us proper software development processes.And yet, three years on, in submitting this story, Erik wanted us to know that the company was doing better than ever, still with 0 unit tests in a codebase that's loaded with WTFs, and still feeling guilty enough about this interview to write in. [Advertisement] Otter - Provision your servers automatically without ever needing to log-in to a command prompt. Get started today!

Many decades ago—before laser printers, graphical operating systems, and device-independent imaging models—Gus worked in the IT department of a local college. As a personal project during slow moments at work, he took it upon himself to figure out how to print Greek text. About a week later, he'd hacked together a solution that resulted in a printout of classical Greek writing.Gus' boss, although a manager in IT, happened to be a classical scholar. He'd never seen Greek text printed from a normal printer before, and he was ecstatic. He told his friends, who told their friends, and so on. The world of classical Greek scholars soon buzzed with the excitement of a rowdy symposium.One day, Gus received an email from an unknown professor at an Arizona college. He'd heard from Gus' boss about the wonderful, mythical software. Could he have it, too?Gus wanted to oblige, but there was a problem. His solution was specific to the previous version of the VAX/VMS operating system and Pascal compiler, to one particular VERSAMOD-200 printer that could be put into a dot-matrix mode, and to a special print driver that'd been carefully binary-patched so that it wouldn't mess up dot-matrix images. Gus doubted the professor had the technical knowledge to appreciate this explanation, so he replied in polite, less technical terms: sorry, but his software just wouldn't work anywhere else. A week later, his boss showed up at his desk, mentioning the friend in Arizona and nicely asking whether Gus couldn't find some way to send him the software after all. Gus' attempts to explain the impossibility of getting the code running on any other computer in the world fell on deaf ears."You're a genius, Gus! I'm sure you'll think of something. Thanks!" Pleased with his own optimism, the boss left.Gus thought about what he could possibly do to comply, or even semi-comply, with the request. Finally, he hit upon an idea. Into his computer's shell prompt, he typed:

Chaz had a pretty sweet gig as a software architect at a tech-based toy company. Being able to play around with computers AND toys all day wasn't terrible, but the pot got even sweeter when his company licensed a cool robotic product from a certain Danish toy company that specializes in small, colorful bricks. Chaz was happy to become the lead platform architect for this exciting new initiative.The intended outcome was to make the robots consumer-programmable via an interface with a smartphone app. Chaz had grand ideas for how he wanted to build the app and backend from the ground up with stability, performance, and security as the main pillars. That dream was dashed by Stellan, the CFO-turned-CTO, who insisted they develop against the same in-house platform they'd been using for over a decade. Chaz argued with Stellan until he was blue in the face, but Stellan scoffed at him, "I don't care if smartphones didn't even exist when our platform was designed. The cost of building a whole new one would be astronomical. We want a quick turnaround and high profit margin on these robots!" Stellan clearly showed he was far more qualified to be a CFO than CTO.Chaz and the development team slogged for six months to make the robot toys and the smartphone app work with their antiquated platform. By late July, they were prepared for their targeted launch at the end of August. Chaz was tasked with leading a demo for Stellan and other C-level executives. "Stellan, how to you like your coffee?" Chaz queried, his custom robot proudly displayed on the conference room table. Stellan informed him he took three sugars, two creamers. Chaz punched in a couple things on his smartphone then set it down. The executives stared in amazement as Chaz's robot grabbed a coffee cup, dispensed coffee from the carafe, then added what Stellan requested and gave it a good stir before delivering it to him."That's amazing!" Stellan shouted, looking down at the robot like it just performed a biblical miracle. "What else can it do??""Well, this is all I programmed it to do for our demo. But for anyone with an imagination and a smartphone, there are boundless possibilities," Chaz assured them."Brilliant!" Stellan added. "This gives me an idea!" The grin Chaz had from the successful demo suddenly faded. "I think we would be foolish to not collect data on how consumers are using these robots. We could use it to help improve and know what people look for in our product!""It's a good thought. Anonymous usage data can be beneficial in future product upgrades," Chaz agreed while hiding his skepticism."Future upgrades?" Stellan questioned, looking above the rim of his glasses at Chaz. "The future is now, Chaz my man. We need this data tracking in time for launch next month!" Unwilling to go on a rant in front of all the big-shots, Chaz saved his reservations for a more appropriate time. It didn't matter. Stellan's idea had to be put in. Fast.Chaz and the devs worked long hours over the next month to bang out the activity tracking and log upload functionality. The absurd timeline forced Chaz to approve a lot of corner cutting. The app was set to collect activity data from the robot every 23 seconds. Any higher frequency would cause the app to crash. From there, it would transmit the data back to a shoddy web service that Chaz also had to quickly produce. This gave Stellan the usage data he greatly desired.He gave another demo the week before launch but cautioned everyone that it hadn't been tested nearly as thoroughly as it should be. But it was too late to turn back. The programmable robots created a lot of buzz and there were nearly a million pre-orders by launch day. Chaz and his warnings didn't matter one bit.Launch day came with long lines of fans in cities across the globe eagerly waiting to get their hands on the product Chaz didn't trust. The thrill of all those sales eventually turned into panic as the modest support call center was flooded with calls about "robots gone mad."Chaz got a report from the support manager with a common problem consumers were having. Their robots would be working fine, then every so often, about 23 seconds or so, they would freeze up. Eventually the robots would become unresponsive. Some time later, they would "go crazy" and start doing all sorts of actions without input.Chaz checked the web and database servers. Both were flooded with activity and couldn't keep up. Chaz didn't need to check any logs to know what was happening - the activity tracking functionality couldn't handle to load that the logs a million launch day robots were generating. As for the phycho robots, that was caused by the inputs of users frantically tapping the app when their robots froze up. They would queue up on the smartphone and when the app got back to a point it could send commands to the robots, they all came in at once - giving the appearance of "robots gone mad".In a post-mortem meeting the following week, Chaz took the wrath of Stellan and the other executives. Obviously, it was his fault for arcitecting a bad product. Chaz pleaded with them to let him fix it the right way to make sure it didn't happen again. "Oh, this won't happen again," Stellan rebuffed. "We only had one launch day, there will never be that much activity again. What we have should be able to handle a slower trickle of robots coming online. As for you, Chaz, start packing up your desk. You're done here."Chaz was disappointed to be leaving what had been a cool job. But getting his bonus tied to the number of robot sales as a severance made it more palatable. On the way out, he actually wished he could be around to see Stellan's face after another million or so robots came online Christmas Day. Any angry letters to Santa about faulty robots should be redirected to Stellan by the North Pole post office. [Advertisement] Continuously monitor your servers for configuration changes, and report when there's configuration drift. Get started with Otter today!