The Daily WTF

We get a lot of bad date code samples. Since we all learned to read a calendar in elementary school, everyone assumes they actually understand how dates work, and then tries to codify that knowledge in code. Bad date code is like entry level awfulness, and it takes a lot to surprise me when I see bad date handling code. Mike R knows how to do it, though. He found this code buried in a 30+ file commit, with the helpful commit message, “asdf;”:

Snoofle's tale is a little different than our usual Tales From the Interview, but these kinds of negotiating tactics are TRWTF. -- RemyAfter more than 3 decades in our field, I find my self in the position of being able to afford to retire, but not yet actually ready to retire. This is partly due to the fact that my wife still wants to work. While walking off into the sunset together seems enticing, biding my time until she's ready seems somewhat boring (for the unmarried, having too much fun while she's still at work, even by her choice, is not conducive to marital bliss).Once you realize that you've cleared the financial hurdles where the big bills like college tuition and the mortgage are paid and retirement is funded, your priorities at work change. For example, when you need to pay tuition and a mortgage, you are willing to put up with a certain amount of stupidity so that you can take care of your family. Once those bills are paid, your tolerance for idiocy shrinks quite a bit. To that end, I left my last job - for the first time - with no job to go to.While I'm waiting for my wife to decide to join me, I've decided that taking another job could fill the time. Since I no longer need the money, however, my criteria for taking another job are far more stringent than usual. Specifically, no more managers who offer randomly chosen delivery dates without taking the amount of work into account. No more places that deploy directly to production. No more tolerance for managers that say one thing and then do another, leaving you holding the bag. No more teams of one experienced person to fix the onslaught of wrong-ness inflicted by a bevy of inexperienced junior developers.As you might imagine, most of what crosses my in-box doesn't measure up. However, every now and then, something of interest (that seems to measure up) appears. The latest of these was a position as a highly experienced architect/developer at a non-financial company in NJ. The technology stack they were using was in line with my experience. The phone screen with the developers yielded some honesty about the differences between where they were and where they needed to be, but at least they recognized the shortcomings. It was a try-buy deal (usually a turn-off for me) with the numbers in the right range (e.g.: commensurate with my experience). I decided to go on the interview.Don't get me wrong; if I could find a good position at half the money, but near home, I'd grab it (convenience trumps income). Unfortunately, there's very little in the way of tech offerings near where we live. If I have to make the long daily shlep, then I feel it's only reasonable to be paid along the lines of typical salaries in the industry and location where I'll be working. The fact that I don't actually need the money is personal and should be of no consequence to the company who will be getting my services.The interview went well. A few days later the offer came, but at $50K less than what they had listed in the job posting. Upon querying, I was informed that although they said I had all the qualifications and experience they were seeking, they decided they only needed mid-level experience and so they adjusted the offer to reflect that. Although it's not about money, I don't like being taken advantage of, and declined based upon the discrepancy.The hiring manager called me to try and convince me to take the position as we had all hit it off and seemed to be on the same page. I said that it seemed that they wanted 30+ years of experience but were only willing to pay for 15 years of experience, and that since the number they originally discussed and the one they offered were so different, that I was not interested in giving it away (would they be willing to let me dumb down my skills, knowledge and experience to match the compensation, or did they want me to use all of my expertise to do the best job possible?)Of course he said the latter. He then pointed out that $50K wasn't that much money and it shouldn't be a deciding factor. I said that money wasn't the issue, but how they changed the terms on me after the fact was. I further pointed out that if it wasn't that much money, then I would take the job at the offered rate if he would personally make up the $50K difference.Naturally he railed at that suggestion.I pointed out that it was interesting that $50K was no big deal when it was coming out of my pocket, but it was a huge deal when it was coming out of his pocket; then I declined the offer.A few days later, he called me again and informed me that he got the budget to pay the originally agreed-upon rate.I am presently doing volunteer work, instead. If I'm going to take a paid position, it should be a fair wage given the skills/experience/location/industry/etc. I am not going to give it away. The fact that he tried to renege on a financial agreement just to make his budget look better - to me - is a huge warning sign that dealing with him would be an ongoing WTF, so I chose to pass on the position.When you have fiscal obligations, getting paid something - anything - is better than nothing, but we all know that someone who is qualified but underpaid is someone searching for a new position. When you have the luxury of not having monetary obligations, dealing with someone who treats you fairly and honestly trumps - pretty much - all.[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!

An anonymous reader was chatting with their fellow developers on Slack. They work for a telecom, and thus have to support software and hardware from a variety of vendors. In one Apple-provided API, they found this method.

Dominique finished her instant cup of ramen, her third day straight. She and the other developers at Bento had gone a month without pay as they finished the beta version of their only application: a browser for promotional materials of yet-to-be-released merchandise.Her cellphone rang. It was CEO Stephen, who was wooing investors with a demo. “How hard is it to block a user from capturing a screen image?”“It’s possible,” she began. “We’d need to encrypt all copyrighted images that are stored to disk, disable the print screen button, disable the context menu when a user right-clicks–”“Great, thanks.” Stephen hung up.Stephen returned to the office an hour later. “We’ll need copy protection for a new demo next Monday,” he said.“I didn’t even get to the hard stuff,” Dominique replied. “Like screen capturing software. You’re talking about a dozen different applications we’d need to write fixes for.”“Sure, but you can do it by Monday, right? It’s the one thing they’re insisting on.”The ListDominique assembled the other developers for a stand-up meeting. She wrote on the whiteboard:

"Sure, it's a bit expensive, but hey, where else can you find a place with a huge outside baloney?" Keith S. wrote.

For every line of code that ends up in software the general public sees or interacts with, for every line in your Snapchats and Battlezone: Call of Honor Duty Warfare, there are a thousand lines of code written to handle a supply chain processing rule that only applies to one warehouse on alternating Thursdays, but changes next month thanks to a union negotiation. Or it’s a software package that keeps track of every scale owned by a company and reminds people to calibrate them. Or a data-pump that pulls records out of one off-the-shelf silo and pushes them into another.That’s the “iceberg” of software development. In terms of sheer quantity, most software is written below the waterline, deep in the bowels of companies that don’t sell software, but need it anyway. That’s the world of internal software development.And internal software development, in-house software shops, have a problem. Well, they have lots of problems, but we’re going to focus on one today: Internal Billing and the Billable Hour.At a first pass, internal billing makes sense. If you are a widget manufacturer, then you want the entire company aligned with that goal. If you buy raw materials, those raw materials are going into widgets. If you pay laborers, their labor should be going into making widgets. If you buy capital assets, they should be things like widget-stamping machines.But you can’t just build widgets. Your workers need to organize via email. The new Widget-Stamper 9000 needs network connectivity, so you need network drops and routers and switches, which in turn need regular maintenance. This is, in pointy-haired-boss speak, “overhead”. You need it, but it doesn’t directly make widgets. It’s a cost center.So what do large companies do? Well, they take all those “non-productive” activities and shuffle them off into their own departments, usually in a “corporate SBU”. Then all the departments doing “real” work get a budget to spend on those “cost centers”. And thus, internal billing is born.Each employee needs an email account. Let’s assign that a cost, a rough—sometimes very rough—estimate of the total cost of managing the email account. Our corporate IT department will charge $20/yr per employee to cover the storage, configuration, management, and helpdesk support associated with their email account—and so on through the list of IT-related goods and services. Now the idea is that individual departments know their IT needs better than anyone else. By putting them in control of their IT budgets, they can spend their money wisely.If you’re a widget-making company, you view software and IT support as an overhead cost, and recognize that you only have the capacity to pursue a certain number of IT projects, this makes perfect sense. Budgets and billing create a supply/demand relationship, and they give corporate the ability to cut overhead costs by controlling budgets. (Of course, this is all founded on the faulty assumption that in-house software development is simply overhead, but let’s set that aside for now.)The problems start when internal billing meets software development, usually through the interface of the “billable hour”. The combination of these factors creates a situation where people who are ostensibly co-workers are locked into a toxic client/vendor relationship. The IT department is usually in a disadvantageous negotiating position, often competing against external vendors for a business department’s IT budget. Treating corporate IT as the preferred vendor isn’t all sunshine and roses for the business, either. There are definitely cases where external vendors are better suited to solve certain problems.Putting IT resources on a billable hours system introduces a slew of bizarre side effects. For one thing, hours have to be tracked. That overhead might be relatively small, but it’s a cost. “Idling” becomes a serious concern. If developers aren’t assigned to billable projects, the IT department as a whole starts looking like it’s being non-productive. Practices like refactoring have to be carefully concealed, because business units aren’t going to pay for that.Spending more billable hours on a project than estimated throws budgets out of whack. This forces developers into “adaptive strategies”. For example: padding estimates. If you can get an extremely padded estimate, or can get a long-running project into a steady-state where no one’s looking too closely at the charges, you can treat these as “banks”. A project starts running over your estimate? Start charging that work against a project that has some spare time.Of course, that makes it impossible to know how much time was actually spent on a project, so forget about using that for process improvement later. It also makes every project more expensive, driving up the costs of internal development. This drives business users to seek external solutions, spending their IT budget outside of the company, or worse: to find workarounds. Workarounds like maybe just building a big complicated Excel spreadsheet with macros in it.This isn’t even always restricted to hourly charges, either. I saw one organization that had a charge-back rate of $10,000/yr for a SQL Server database. That wasn’t licensing or hardware, that was just to create a new database on an existing instance of SQL Server. The result? Pretty much no business unit had a working test environment, and they’d often stack four or five different applications into the same database. Rarely, they’d use schemas to organize their tables, but usually you’d have tables like: Users, Users_1, UsersNew, UsersWidgetsoft, ___Users.Forget about upgrades, even if they’re required. Short of making organization-wide modernization a capital project, no department or business unit is going to blow their IT budget on upgrading software that already works. For example, Microsoft still supports the VB6 runtime, but hasn’t supported the VB6 development environment since 2008. So, when the users say, “We need to add $X to the application,” IT has to respond, “We can’t add $X unless we do a complete rewrite, because we can’t support it in the state it’s in.” Either the business ends up doing without the feature or they make it a demand: “We need $X and we need it without a complete rewrite.” Then your developers end up trying to breathe life into a Windows 2000 VM without connecting it to the network in hopes that they can get something to build.Billable hours turn work into a clock-punching exercise. Billing time is how you’re judged, and whether or not that time is spent effectively becomes less relevant. Often, by the end of the week, employees are looking for ways to fill up their hours. This is a task that should be easy, but I’ve watched developers agonize over how much they’re going to lie to make their timesheet look good, and hit their “85% billable” targets. This gets especially bizarre since you’re not self-assigning tasks, but you have to have 85% of your time billable, and thus you need to take the tasks you’ve been assigned and spend a lot of time on the billable ones to make sure you hit your targets, turning five-minute jobs into ten-hour slogs.We could go on dissecting the problems with billable hours, and these problems exist even when we assume that you can just view your in-house software as a cost center. Some of these problems can get managed around, but the one that can’t is this harsh reality: software isn’t a cost center.I’ve heard a million variations on the phrase, “we make widgets, not software!” Twenty years ago, perhaps even ten years ago, this may have been true. Today, if you are running a business of any scale, it simply is not. It’s trite to say, but these days, every business is an IT business.One project I worked on was little more than a datapump application with a twist: the data source was a flow meter attached to a pipe delivering raw materials to a manufacturing process. The driver for reading the data was an out-of-date mess, and so I basically had to roll my own. The result was that, as raw material flowed through the pipe, the ERP system was updated in real-ish time with that material consumption, allowing up-to-the-minute forecasts of consumption, output, and loss.How valuable was that? It’s not simply an efficiency gain, but having that sort of data introduces new ways of managing the production process. From allowing management to have a better picture of the actual state of the process, to helping supply chain plan out a just-in-time inventory strategy, this sort of thing could have a huge change on the way the business works. That wasn’t a skunkworks idea, that wasn’t IT just going off and doing its own thing. That was a real hook for business process improvement.Smart companies are starting to figure this out. I’ve been doing some work for a financial services company that just hired a new CTO, and he’s turned around the “We make $X, not software,” and started his tenure by saying, “We are a software company that provides financial services.” Instead of viewing IT as a sink, he’s pushing the company to view IT as a tool for opening up new markets and new business models.So, yes, IT is a cost of doing business. You’ll need certain IT services no matter what, often fulfilled with off-the-shelf solutions, but configured and modeled to your needs. IT can also be a cost savings. Automation can free up employees to focus on value-added tasks.But the one that’s underestimated in a lot of companies is IT’s ability to create value-added situations. If you make widgets, sure, it’s unlikely that your software is going to directly change the process of making widgets, so it’s unlikely that your software is itself technically “value added”. But a just-in-time supply chain system is more than just a cost savings or an efficiency booster. It can completely change how you manage your production process.By placing the wall of billable hours between IT and the business, you’re discouraging the business from leveraging IT. So here are a few ways that corporations and management could possibly fix this problem.First, as much as possible, integrate the IT staff into the business-unit staff. This might mean moving some corporate IT functionality out into individual departments or business units (if they’re large enough to support it), or dedicating corporate staff to a relationship with specific business units. Turn IT workers into a steady flat cost, not a per-hour cost. When trying to handle priorities and deciding how to spend this limited resource to get new software developed, business-unit management can set priorities.If an organization absolutely must use internal billing to set priorities and control demand for IT resources, move as much work as possible into fixed-rate, flat-fee type operations. If a business unit requests a new piece of software, build a fixed-bid cost for that project, not an hourly cost.While a “20% time” approach, where employees are allowed to spend 20% of their time on their own projects, doesn’t work in these kinds of environments, an organizational variation where some IT budget is used on speculative projects that simply might not work—a carefully managed skunkworks approach—can yield great benefits. It’s also an opportunity to keep your internal IT staff’s skills up to date. When you’re simply clocking billable hours, it’s hard to do any self-training, and unless your organization really invests in a training program, it’s easy to ossify. This can also involve real training, not “I sent my drones to a class, why don’t they know $X by now?” but actual hands-on experimentation, the only way to actually learn new IT skills.All in all: billable hours are poison. It doesn’t matter that they’re a standard practice, they drag your IT department down and make your entire organization less effective. If you’re in a position to put a stop to it, I’m asking you, stop this. If you can’t stop it, find someone who can. Corporate IT is one of the most important yet under-prioritized sectors of our industry, and we need to keep it effective.[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!

We don’t receive many CSS-based submissions, possibly because CSS is already pretty horrible. There are real-world, practical things that you simply need to take a hacky, awkward approach with.Matthew found this code, however, which isn’t a clever hack to work around a limitation, and instead just leaves me scratching my head.

Murray F. took a position as an Highly Paid Consultant at a large firm that had rules for everything. One of the more prescient rules specified that for purposes of budgeting, consultants were only allowed to bill for 8 hours of work per day, no exceptions. The other interesting rule was that only certain employees were allowed to connect to the VPN to work from home; consultants had to physically be in the office.The project to which Murray was assigned had an international staff of more than 100 developers; about 35 of them were located locally. All of the local development staff were HPCs.With that much staff, as you would expect, there was a substantial MS Project plan detailing units of work at all levels, and assorted roll-ups into the master time line.The managers that had created this plan took all sorts of things into account. For example, if you attended three hours of meetings two days a week, then you only had 34 hours available for work; if you had to leave early one day to pick up your kid, it set those hours aside as non-work, and so on. The level of detail even took into account the time it takes to mentally put down one complex task and pick up another one. It was awful to look at but it was reasonably accurate.Until...Weather forecasters are wrong as often as they are right. However, the spiraling pin-wheel of snowstorms was getting bigger and barreling down on the local office, and was so imminent that even the forecasters were issuing absolute warnings. Not "It looks like we might get six inches"; but more along the lines of "Get groceries and plan to be shut in for a while".The storm hit at night and by first light, anyone who looked out the window immediately realized that the forecasters were right and that they weren't going anywhere. In an attempt to be good team players, the consultants called their managers, pointed out that they were snowed in and unable to travel, and given the special circumstances, could they use the VPN and work from home?The managers all responded that the rules were very specific and that the consultants could only work from the office. Since the consultants were powerless to do anything about the weather or the mountain of snow that had to be shoveled, they took snow days and no work was done.That's 35 consultants for 2 days or 70 days of (loaded) work, or about 2 ½ months of work that vaporized. Needless to say, this turned the otherwise green time line quite red.The managers called a meeting to discuss how to make up the time. Their first suggestion was that the consultants put in more time, to which they responded The rules specify that we cannot bill more than 8 hours each day. The managers then asked the consultants if they would work without pay - to get it done. Wisely, the consultants said that they were required to play by the rules set forth by the company, and could not falsify the billing sheets with the wrong number of hours worked.The sponsoring agencies of the consultants all agreed on that one (free labor means no commissions on said labor).This went back and forth for a while until it came time for scheduled demos. Only the work was about ten person-weeks behind schedule and the features to be demo'd had not yet been built.At this point, the senior people who could not see their expected features in action had no choice but to address the snow delay. After much discussion, they decreed that the budgets had to be adhered to (e.g.: billing was limited to 8 hours per day), but the line development managers could hire additional consultants to make up the missed work. The managers got to work adjusting the master project plan.The existing consultants pointed out that it would take a substantial amount of time to find new consultants, get computers, set up development environments, do general on-boarding and get new developers up to speed; and that it didn't make sense to hire new developers for something like this.It was decreed that rules had to be followed, and it didn't matter if it wasn't cost efficient to follow those rules.So they spent about a month interviewing (new project task for existing senior consultants and managers), bringing new consultants on board (getting them equipment, access, etc. - a new project task for managers) , and giving them architecture and code walk-throughs (new project task for existing senior consultants). This necessitated increasing the expense to the project to cover all the additional overhead.All to save a few bucks in additional billing by already-trained-and-equipped developers, which would have been completely unnecessary if they had just let them work from home in the first place.But hey, those were the rules. [Advertisement] Application Release Automation – build complex release pipelines all managed from one central dashboard, accessibility for the whole team. Download and learn more today!

PastorGL inherited some front-end code. This front-end code only talks to a single, in-house developed back-end. Unfortunately, that single backend wasn’t developed with any sort of consistency in mind. So, for example, depending on the end-point, sometimes you need to pass fields back and forth as productID, sometimes it’s id, productId, or even _id.Annoying, but even worse is dealing with the dreaded date datatype. JSON, of course, doesn’t have a concept of date datatypes, which leaves the web-service developer needing to make a choice about how to pass the date back. As a Unix timestamp? As a string? What kind of string? With no consistency on their web-service design, the date could be passed back and forth in a number of formats.Now, if you’re familiar with the JavaScript Date datatype, you’d know that it can take most date formats as an input and convert them into a Date object, which gives you all the lovely convenience methods you might need. So, if for example, you wanted to convert a date string into a Unix timestamp, you might do something like this:

"Web design pro-tip: If it takes a while to load data, just put an 'Animated loading spinner' on the screen," wrote Stuart L.

Today, we present our second installment of Software on the Rocks, complete with new features, like an actually readable transcript done by a professional transcriber. Isn’t that amazing?In today’s episode, Alex and Remy host a special guest, Justin Reese, founder of Code & Supply, one of the largest developer community organizations out there, with a nearly constant stream of events. In this episode, we discuss what building a community is like, when is it fair to really tear into bad code, and that time Alex made 10,000 people late for work.This episode of Software on the Rocks is brought to you by Atalasoft.MP3Web PlayerTune in two weeks, when we’ll have Jane Bailey, one of our writers, to discuss working for the site and the perils of “Programmer Anarchy”. Follow future episodes here on the site, or subscribe to our podcast.TranscriptAlex: I guess this is another podcast we’re doing.Remy: We are doing this again, and you know what? Not only are we doing this again, Alex, but we have brought a friend. This is Remy Porter, editor of The Daily WTF. We’ve got Alex.Alex: Hello, everyone. Hello, Remy.Remy: And we have with us Justin Reese. So, uh, Justin, why don’t you tell us a little bit about yourself?Justin: Oh. Oh, no. Remy met me through Code & Supply, which is an organization that I started to kind of foster a strong software community here in Pittsburgh.Alex: What sort of things do you do?Justin: Well, so, Code & Supply started because there were lots of disparate meet-ups around the city and just holding events. And there were some really small ones that had great ideas and great people involved but they were really small and they were susceptible to one person failing to do something. And the whole community around a language would die in the city. So, I wanted to make a stronger organization, bring on sponsorship money, and pay to do really cool things, and it just kind of –Alex: And so, this is all Pittsburgh-based, all Pittsburgh local. It sounds like a pretty interesting idea.Justin: Yeah, along with something like 8 to 12 events every month, we held Abstractions this year. You know, it was a very, very large conference.Alex: Oh, that was your conference?Remy: That was his conference. I was an attendee. I just showed up. This was an amazing conference.Justin: What’s really amazing is, like, we had a lot of people there. We’re really focused on creating connections between people, so we – The whole focus was building a bridge between, like, a design community, the ops community, the development community into one thing. But we ended up doing some really amazing things, like Larry Wall, the inventor of Perl, for the first time ever, meeting Joe Armstrong, the inventor of Erlang.Alex: Now, Justin, is Abstractions a not-for-profit or – This whole Code & Supply thing, like, is this someone’s full-time job? I mean, it sounds almost hobby-like, but then, you know, a conference – that’s, like, gone beyond a hobby. You know, there’s some real risks you have to take on to do that.Justin: That’s kind of the reason behind Code & Supply, though, is so that the risk is minimized a little bit. I signed contracts with venues and things that would have financially ruined me if something went wrong, but, you know, having Code & Supply as an organization at least protects me, personally, a little bit.Alex: And just to be clear, when you say, “huge financial risks and liabilities,” you know, this is the thing with conferences that always amazes me, right, is that, you know, we’re talking, like, hundreds of thousands of dollars. And why take on all that liability for, effectively, a hobby?Justin: Alex, you have a pretty good point. It is –You know, I mean, it is, to a point, fun, and I’d love to get to a point where I can make it my full-time job. It’s not quite there yet, but, you know, all the money we’ve made so far has been re-invested into our community. So, we took that Abstractions money that we made and we signed up for a really long lease for a community center so that we can have a place to hold events in perpetuity. And most of the time, I’m making decisions based on how to make the community more welcoming, ‘cause growth is kind of what makes Code & Supply awesome, is its incredible size to do really fantastic events. To grow, you got to be welcoming and get all the people involved.Alex: Now, Justin, I’m actually in the midst of organizing my own conference here. Well, I shouldn’t say “my own.” It’s DevOpsDays Tokyo. And this is one of the same issues that we’re facing is this whole notion of being open and being welcoming. The things that I see a lot are the elitism.Justin: Alex, I think that combating that feeling of elitism is kind of important. You know, we’re a polyglot community, and that means a lot of language, so people make choices for different reasons, and that “best tool for the job” mentality really goes a long way.Remy: And so, Justin, what would you say to the – there’s this one kind of tribe of elitists I see. They’ll grab code samples from other people’s codebases, usually offered by a disgruntled co-worker, and then they’ll post these code samples on a website. They, like, have this “Code Sample of the Day,” and they do these very critical code reviews. I don’t know. I feel like these people could be part of the problem.Justin: Remy, are you talking about something specific?Remy: I’m talking about The Daily WTF.Justin: Yeah, yeah, yeah, yeah. That’s –Alex: Oh, hey. That’s –

There’s an old saying, that if your code is so unclear it needs comments to explain it, you should probably rewrite it. Dan found this code in a production system, which invents a bizarre inversion of that principle:

You may remember our new sponsor, Hired. To help them match up talent with employers, they’ve created their own proprietary dataset about salary and hiring trends, and have published their annual report about what they’ve found.There are a few key things in this report. First, as we all know, you don’t need to go to Silicon Valley for a good job in the tech sector- and even though the salaries are among the highest at an average of $134K a year, with cost of living factored in, even the notoriously expensive New York and LA can give you an advantage in purchasing power.If you are thinking of a move, the hot cities are Austin, Singapore and London. Non-local candidates are getting more offers at higher salaries than anywhere else. Even if you don’t want to go to one of those cities, in 12 of Hired’s 16 markets are offering better salaries to relocators.Age and race still matter. While African-American candidates are actually more likely to get hired, that may be because they’re being hired at a much lower salary than white candidates. Latino and Asian candidates ask for salaries comparable with white candidates, and are both less likely to get hired.If you’re between 25 and 30, you’re much more likely to get an “average” job offer for your experience level, but past 45, you’ll start to see a decline.There’s a lot more in here, including lots of global data. Read the white paper yourself, and if you think you could take advantage of these trends, get on Hired today and get some offers. [Advertisement] Otter, ProGet, BuildMaster – robust, powerful, scalable, and reliable additions to your existing DevOps toolchain.

During the interview, everything was gravy. Celestino Inc. was doing better business than ever before, and they were ready to expand their development center. They had all the keywords Gigi was looking for: Java 8, serving up a SPA for a hot new streaming product, outsourced from a company with money to burn but no developers of their own. She loved the people she'd interviewed with; they were smart people with great ideas. It'd been a long, grueling job hunt, but it'd been worth it. Gigi was eager to work with the technology, not to mention having plenty of budget and a greenfield to work with.By the time Gigi started work, however, the deal had fallen through. The big name with the budget had gone elsewhere, leaving Celestino in the dust. Gigi's boss seemed surprised to see her. He assigned her to work on bug duty for their 7 year-old Java product instead.A few minutes of settling in, and Gigi found the Jira for the product. She clicked through to "Unresolved issues" ... and nearly fell out of her chair. There were 8,800 bugs.That can't be right! she thought. Maybe they're not setting a resolution when they close them?But there was no such luck. Clicking into a dozen or so of the older ones revealed that they'd been filed years ago and never opened.Where do I even start? she wondered."I'll give you an easy one," said the manager, when asked. "Just fix this one thing, without touching anything else, and we'll get it rolled out to prod in the weekly release. Be careful not to touch anything else! We've had guys in the past who broke stuff they didn't realize was there."The bug did look easy, at least: if one chose a red background in the app, the text "looked funny". Gigi had no trouble reproducing the effect 100% of the time. All she had to do was find the offending line of code and tweak it. No risk of introducing extra bugs.And it was a snap—of her patience, not her fingers. The codebase had 133,000 source files implementing 3,600 classes, all just for the backend part of the application. She found a surprising number of places calling TextOut() that could've produced the text she saw, and the code was, of course, awful to read.Gigi gave up understanding it and tried the old standby: a binary search of the codebase by commenting out half the instances and seeing if the "funny" text still appeared. Six comments were inserted, and the code recompiled, taking 20 minutes. Gigi had been warned that if she tried to run make all, it'd take six hours, but that the build script was reasonably reliable—"reasonably" being the operative word.Still, it compiled, and she booted up the app. In theory, if the problem was in the six output statements she'd commented out, she'd see no text; if it was in the six she'd left alone, it'd still appear.She never anticipated a third outcome. The red background was gone, indicating that the output was in the commented half ... but instead of nothing, she saw two copies of the text that'd been hidden behind the red background, both reading the same thing, but in different fonts and different positioning.Gigi stared at the screen, a sinking feeling in the pit of her stomach. A vivid daydream flashed across her eyes: she envisioned packing up her purse, walking out the doors into the sunshine, and never returning. Maybe, if she were feeling generous, she'd call and explain she'd been deported to Mars or had suffered a violent allergic reaction to the application or something.It was her first day, after all. Nobody would miss her. Nobody depended on her yet. Nobody ...She flipped open her cell phone, staring at the lock screen: a picture of her husband and year-old son. They were counting on her. She needed to stick it out at least long enough to look good on her résumé and help her get the next job. She could do this for her family. She had to be brave.Taking a deep breath, Gigi resumed her herculean task. She commented out a few more text outputs, hoping to figure out which of them was causing the effect. After another build and run, there was no text—but the text box twitched and flashed alarmingly.There's at least three layers of bug here! How am I meant to solve this without touching any unrelated code?!Gigi turned back to the Jira, realizing now why so many of these defects were ancient and still unopened as she set the bug back to "todo" status and went to find the manager.The next defect she was able to resolve, putting her back on solid ground. Not that it'd been easy—the problem was in a button event handler, spread across six source code files. The first file created an object and a thread; the next file scheduled the thread in a private queue. The third class hooked the thread up to the button, while the fourth class caught button clicks and scheduled another thread to handle the event. There were a few more layers of passing data around between files, until finally, another thread was queued to destroy the object. But once she got her head around the architecture, the bug was a simple typo. Easy enough to resolve.A week later, an email came through: some contractor in Siberia had resolved the first bug ... by upgrading the video drivers. Apparently there was a known issue with layering visible text on top of invisible text, with or without the red background.Why was the invisible text there? What did it have to do with a red background? What unearthly combination of branches created that particular display?Gigi didn't know or care. She was too busy filling out applications on Monster.com. Résumé be damned, she needed to escape. Maybe she'd just leave this one entirely off.[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!

An email from Andrea Ci arrived in our inbox, with nothing more than some code and a very simple subject line: “VB Conversion: a year in hell”.A lot of people have that experience when encountering Visual Basic code, especially when it’s VB6, not VB.Net. Even so, could it really be that bad? Well, let’s look at the sample Andrea provided.

"Thanks for the explanation because thanks for the explanation because false!" writes Paul N.

Famed placeholder company Initech is named for its hometown, Initown. Initech recruits heavily from their hometown school, the University of Initown. UoI, like most universities, is a hidebound and bureaucratic institution, but in Initown, that’s creating a problem. Initown has recently seen a minor boom in the tech sector, and now the School of Sciences is setting IT policy for the entire university.Derek manages the Business School’s IT support team, and thus his days are spent hand-holding MBA students through how to copy files over to a thumb drive, and babysitting professors who want to fax an email to the department chair. He’s allowed to hire student workers, but cannot fire them. He’s allowed to purchase consumables like paper and toner, but has to beg permission for capital assets like mice and keyboards. He can set direction and provide input to software purchase decisions, but he also has to continue to support the DOS version of WordPerfect because one professor writes all their papers using it.One day, to his surprise, he received a notification from the Technology Council, the administrative board that set IT policy across the entire University. “We now support Two-Factor Authentication”. Derek, being both technologically savvy and security conscious, was one of the first people to sign up, and he pulled his entire staff along with him. It made sense: they were all young, technologically competent, and had smartphones that could run the school’s 2FA app. He encouraged their other customers to join them, but given that at least three professors didn’t use email and instead had the department secretary print out emails, there were some battles that simply weren’t worth fighting.Three months went by, which is an eyeblink in University Time™. There was no further direction from the Technology Council. Within the Business School, very little happened with 2FA. A few faculty members, especially the ones fresh from the private sector, signed up. Very few tenured professors did.And then Derek received this email:

Artie S. writes:

We've all built table driven software. In your engine, you put a bunch of potential callbacks into some data structure, perhaps a map, and call the relevant one based upon some key value. Then the calling logic that uses the engine has some structure that holds the key(s) of the method(s) to be called for some context. If you change the key(s) for a given context, then the corresponding method(s) that get called change accordingly. It's neat, clean, efficient and fairly simple to implement.At least you'd think so.Unless you run into one of those folks who believes that everything, and I mean everything belongs in the database.About 15 years ago, a mid level developer was tasked with creating a table-driven mechanism to call methods based upon values returned from a query to a remote system in real time. He took the phrase "table driven" literally. After I was hired, I was tasked with diagnosing and fixing the performance problems that were weighing down the application. This developer spent a little time explaining his table driven software to me (minus the fact that it was actual DB tables) and that this was highly efficient and couldn't be the source of the performance issues.There was a single stored procedure call named Engine which took as a hard wired argument the name of the method to call, and an arbitrary list of up to 100 pairs of parameter type and value strings. It would then look up the specified method name to see if it existed, and grab the user id from the environment and look up whether the user had permission to call said method. If so, it would parse the arguments until it hit a null, and based upon the specified types, verify that those types matched the ones configured for the specified method, build up a string representing the method call, exec it, grab the results, and spit them back as a delimited string in a single output parameter.It looked something like this:

Microsoft recently announced that they’re changing how they handle .NET languages. Up to this point, the focus has been on keeping them all feature compatible, but going forward, they’ll be tuning VB.Net towards beginners, C# towards professionals, and F# towards people who have to use .NET but want to “be functional”.VB.Net’s biggest flaw is that it’s inherited all of the Visual Basic programmers. You may be able to write bad code in any language, but I’m not convinced you can write good code in VB6 or earlier. Those bad habits, like Hungarian notation, can mark out “modern” code written with a distinctly “non-modern” mindset.Like this:

"I have two questions: First - Why make the dropdown go all the way down to 1908 if you don't want people selecting it? Second - Why can't I view garfield.com if I'm 101 years old?" wrote Tom.

Welcome to Software on the Rocks, the Daily WTF podcast. This is a new feature we’ll be running on a bi-weekly basis for a first season of a few short episodes. If folks like it, or more important, if we really like doing it, this may continue, but for now, we’re committed to season of 6 episodes.In this episode, Alex and Remy discuss ruining the site, the dangers of booking airline tickets, and why Angular 2 is absolutely the best possible framework for those who love lots of boilerplate.This episode of Software on the Rocks is brought to you by Atalasoft.Tune in two weeks, when we’ll have special guest, Justin Reese of Code & Supply, to discuss software communities and the value of a good bar. Follow future episodes here on the site, or subscribe to our podcast.Direct MP3 DownloadTranscript Welcome to software on the rocks, a daily WTF podcast brought to you by Atalsoft.Remy ® So, I guess we are going to do a podcast thing. This is one of our new things and I guess I probably should take it lame. Hello everyone, welcome to software on the rocks, I’m Remy Porter, chief editor of the daily WTF and responsible for single heading, ruining the site, if I judge by the comment section.Alex (A): Hi everyone, this is Alex and I started daily WTF and still tried to take all the good credits for it. And any times someone complain, just really blame on Remy. I remember starting WTF in 2004 or something like that and literally in the 2 months it had been going downhill. I don’t know…R: The high of the first day. Let’s talk about why we are doing a podcast: we have been doing periodical sponsor posts and this is really not a site that makes a lot of money by driving traffic.A: WTF it could be probably be a full time job, if we were able to turn it into a proper media publication, but it is a hobby site. It’s not free, there are server bills and other expenses and in order to pay for that you could just get google ads, but we wanted to do something different and that is why we have a handful of sponsors. By enlarge they are taking care of the website costs. One things that we wanted to do by giving sponsors, was starting a podcast, so thanks to them we are doing it.R: Atellasoft is a vendor that makes SDK for doing document imaging: scanning documents, storing and processing them. It seems like a relatively good idea to solve the problem and I don’t see other good solutions.A: well, they have been around forever and have a solid community and product and I would recommend to just check them out.R: one of the bullet thing that they do: web scanning for dot net. So they do scanning from a Java script API, which is a funny possibility. It brings back one of the projects I worked on. This was for a company called TPG industry. They almost certainly made the paint on your car. They care about colour, that means a lot. This is something that as a developer I really simpatize with: they make the paint. They take it to GMs factory and than GM applies the paint to the cars. The application process has to be extremely tightly controlled, because if the pressure used is wrong, the colour will come out different and when you will put the bumper on the car, the colour will be different of the one of the fender. And so they will get in fight with their customers: GM will say “the paint you gave us is bad, because we sprayed them to the fender and it doesn’t match the bumper. But then TPG says “no, the paint we gave you was good, we fulfilled your requirements, you are using it wrong”.A: I’ve never heard that before in any other industry, that’s amazing.R: They have a device, that behind the scenes launches a windows executable. What we deploy just launching the webserver on the user’s machine and from the browser we can do cross-orange requests to the webserver running locally on their machine.A: So he built a website that downloaded a thick client, then installed the webserver, than used it to do all the hard work stuff.R: YepA: It seems like not the easiest way. Why don’t just have the desktop UI than?R: They didn’t want it, they wanted a web browser based UI. What is your hobby outside this?A: That’s a funny way to drive that requirement I guess. So, what are you doing now?R: The hobby that pays the bills is that I am consultant, I’m good at training and this weekend I’m teaching a group of people to use Angular 2-A: Wow, I’ve heard a lot of wonderful things about it, mostly from you, even if I don’t do a lot of web developing.R: Yes, I really love it. What I appreciate the most about Angular 2 is the big quality of sheer boiler plate. I want to have a series of project files that have nothing to do with my business that simply need to exist, so the application needs to find its own hustles.A: Yes, you right. The advantage of having a giant number of files is that it gives the developer a sense of responsibility, it makes you really feel like you are building a web application. I see angular 2 more like the shitty sequel of regular 1R: Yes. If you write code that works with angular 2, it might not work tomorrow. Angular 2 didn’t care to make angular perfect: which each single release changes completely the program. That is the framework that they are giving you a product, that is goodish.A: Some might say it’s bad product management, but I say it’s brave. If you just needed to upload angular and your code works, where is the fun in that? More applications should be doing that.R: Sure! Furthermore, angular is creating new jobs, because of its complexity. But, putting the sarcasm down, I will definitely admit that there are actual benefits from Angular’s approach. A while back I took a course about leading business improvement and me and the teacher had the same approach: we look at a process and model it. IT people when they see a complex process try to automate it. My solution is to delete the process, so it’s not a problem anymore. I think that is a big cultural problem.A: Yes, they are engineering a poor solution to an irrelevant or misunderstood problem. What have I been working on lately… oh booking airplanes tickets. What is fascinating to me about the airline industry is that it existed before information systems were a thing. All their fair rules are so deeply ingrained in the process that it is incomprehensible. Why not just simplify the way airlines work? If you start from scratch you will easily find a solution for that business problem than implementing the absurd business requirements.R: But then you see something like South West Airline. What they did when they entered the industry, they did throw away lot of the legacy craft: they standardize their process and that is why circa 2002 every management magazine was “what is South West Airline doing now?”. But it’s the same idea: can we simplify the process?A: They did it rapidly, we are talking about years not decades. They adapted to very fast changes in the market. That is all what this agile thing is all about.R: It seems that might be one of your problems now.A: Yeah, here at DevOps my job is to take ideas into reality quicker and to collaborate with different teams. It’s easy, but sometimes anyone is in a different trench and is thinking about a small problem, without collaborating.R: Sometimes they want to do something different, but as you said, organizationally they can’t.A: They recognize that the 6 months process sucks. The devup’s software will give you the possibility to release in less than 6 months, which is amazing for them.R: developers have fund a new solution, even better than devup that gives you feedback and doesn’t require automation.A: we call that develop misconstruction’s Basically you take a bad software and you run it to the customers, waiting for bug feedbacks and when they come you make the adjustments. They are accepting a low quality process and product. Having a half working product is totally acceptable for this companies, which is very sad to me.R: the idea of risk management is something that IT doesn’t take really into consideration. All this things are rooted in risk management and risk tolerance.A: this is an important topic, but nobody is going to care if we call out this things.R: we believe that risk management is something important to talk about. We need a buzz-word and would love to see some ideas in the commentsA: furthermore, for future episodes we would love to bring up a guest, somebody outside usR: yes, there are already some people aligned up.A: this is going to be fun, I’m exited and hope we can keep it up.Machine Generated Transcript [BREATH] and.

Let’s start with a brief lesson on .NET. .NET, like most OO languages, needs the ability to perform “cleanup” when an object finally dies. One option for this is the Finalize method, which is called when the memory is freed, but since it’s the garbage collector’s job to do that freeing, you have no idea when (or even if) that will happen.To solve that problem, .NET has an interface, IDisposable. The I, of course, is one of the lonely last relics of the tyranny that was “Hungarian Notation”. Classes which implement this interface have a Dispose method, which should be called by an instance’s owner to trigger cleanup (or can be auto-invoked through some nice syntactic sugar).As an interesting, and odd quirk, classes may implement interfaces privately, so a disposable object might have a private Dispose method, that can only be invoked if you first cast to IDisposable.There was a different problem .NET had, specifically, “wouldn’t it be nice to have a way to safely extend objects without inheriting?” Thus came “extension methods”. These are essentially static methods that simply take an object as its input and perform some operation on the object, but can be invoked as if they were class members.For example:

Douglas had just joined a large eCommerce company that was constructing its own in-house PHP development team. It was a big step for them, as they only relied on cheap freelance c0derz to get things done before. Because of this, Douglas and his cohorts had to maintain a glut of legacy applications made by people who were long gone.A vast majority of the horrid legacy apps were created by a man simply known as Shayne. The sight of his name in the code comments would send icy chills down Douglas' spine. Shayne was freelance down to the very definition of it. His signature philosophy to coding seemed to be "roll your own" and his framework weapon of choice was a version of CodeIgniter that was two years out of date at the time he utilized it.One of the more egregious examples of Shayne's hand-rolled disasters was the authentication script he reused on every site he built. Because of his custom session-generation code, a user could log in to one of his websites and copy the 'session' cookie (which contained hashed user details, rather than a unique session ID) to another Shaynesite. From there, they could instantly log in to it, regardless of whether they had the authority to do so.The authentication script, however, had nothing on the poison marsh that was Shayne's eCommerce platform. The platform was developed a few years prior and used to build up the rest of what was supposed to be the company's triumphant new version. Douglas was brought in at the 11th hour to give it a once-over before it got deployed. It didn't take long for him to find an entire mast's worth of red flags.Within half an hour, he found five separate ways to get a free order out of the system. Simple methods involved changing the cart value to '0' in a hidden input since the back end didn't validate the cart total, and more complex methods like spoofing a 'success' callback from card processor WorldPay. Since the application only checked the order ID (which was available prior to the payment stage) but neither the server origin of the payment callback nor the shared secret; the system would be fooled into thinking that an order had been successfully paid for.Douglas immediately brought his findings to his supervisor and informed him that under no circumstance should it be released as-is. He was convincing enough that the brakes were pressed on the release, but the resolution option his boss presented was less favorable, "I'll see if we can dig up this Shayne's phone number and try to get him back in here to fix this mess!"The colorful, four-letter language Douglas used in reply to that suggestion probably should have been enough to get him fired. Fortunately, his boss used more colorful vocabulary daily. Douglas again swayed him to under no circumstance let Shayne in the door ever again. Wanting to make a good impression, Douglas committed his nights and weekends for the foreseeable future to cleaning up the disaster. But before he did that, he began drafting a letter of recommendation to Amazon to hire a great talent like Shayne. Because who wouldn't love to be able to get a bunch of free stuff from Amazon? [Advertisement] Infrastructure as Code built from the start with first-class Windows functionality and an intuitive, visual user interface. Download Otter today!

Brian found himself digging through some C++ code, trying to figure out a cross-thread synchronization bug. It had something to do with the NetLockWait function, based on his debugging, so he dug into the code.

"Every Sunday my 'smart' watch does this. Other days, it displays an abbreviation of the day," wrote Lawrence W.

A lot of the things we do in IT aren't particularly important. If this or that company doesn't sell enough product and goes under, it sucks for the employees, but life goes on. Sometimes, however, we're faced with building systems that need to be truly resilient: aviation systems, for example, cannot go down for a reboot midflight. Government services also fall toward the "important" end of the scale. The local mayor's homepage might not be important, but services like Fire and Rescue or 911 are mission-critical.The control room Kit was installing needed to be up 24/7/365, presumably only allowing a maintenance window every four years. The building was designed to be fireproof, terrorist-proof, electronic-evesdropping-proof, you name it. This was going to be one of the most secure, resilient rooms in the entire city, and we're not talking about a small city, either.Kit hooked up the servers to power. The power had been designed with two independent feeds from two separate substations, with a huge UPS in the loft (to keep it safe from potential floods) with a twelve-hour capacity. The basement housed two diesel generators, and if all else failed, there was a huge socket on the garage wall to allow a transport container generator to be plugged in.It was an excellent design—but you know what site you're on, so you can guess how it all worked out.Kit was in the middle of commissioning and testing the systems they'd installed. Everything was looking good in the control room, and the customer was running some training exercises.Then, it happened: the servers stopped responding.The terminals remained on, but there was clearly nothing for them to connect to. This was around 1990, so it was still very much a mainframe setup. Kit's team headed to the equipment room, only to find the gut-wrenching sight of dead machines: no lights, no fans, nothing.It has to be the power, Kit thought. The system was working five minutes ago, and they're redundant servers. They wouldn't all just break down.He was sweating, but tried not to let his team see. "All right, let's check the UPS," he declared, trying to sound casual."This way," replied one of the techs, leading him to the stairwell ... and down the stairs."Isn't the UPS in the loft?" Kit asked, frowning."No, sir," the tech replied with a grin. "Turns out the floor up there isn't rated for the weight of the lead acid batteries."The best laid plans of mice and men ... Kit thought, then shook his head.Twenty minutes later, the UPS checked out fine. It wasn't flood-proofed anymore, but there wasn't any water, so it ought to have been working. The diesel generators had kicked in, which was why the overhead lights were still on. There had to be some kind of wiring mistake for the servers.Kit traced the wires, mentally correcting the specification to account for the relocated UPS. That led him back to the equipment room without any obvious sign of fault other than "equipment not working." After pulling open a wall panel, he were able to figure out the mistake pretty quickly: the servers were powered by the UPS, but the switch was hooked to the raw mains, and everything was designed to shut off if the switch went down.Kit rubbed his forehead, sent a tech to check all the outlets, and kept looking for any other bonehead moves.The control room power didn't route through the equipment room. When Kit ran a check, half the gear in that room didn't seem to work, either. It had power, but the communication was down.This was all fine before the power went, he reminded himself. Now where's that intercom switch?Then he remembered: the training room. You see, due to the massive amounts of equipment needed to run the control room, there wasn't any space for the communication switches. The nearby training room, however, had much less equipment in it, so they'd moved the switches there.Sure enough, as Kit poked his head into the training room, he found the whole place dark. Who'd want to train during an emergency? Nobody, that's who. So why bother with redundant power? Save the juice for the important rooms—which now couldn't function because they were missing key components.Only one question remained: why did the power go out in the first place? It wasn't a scheduled disaster drill. There were two redundant power lines coming in, so it would've taken something massive to knock them both out. Was one of them disconnected? No; Kit had been there when the electrician went over the wiring, and had seen him sign off on it. Concerned, he wandered out back ... and immediately facepalmed.Both cables came into the building at the same point, so they could both be fed into the same grid. That point was currently occupied by a small backhoe and some frazzled looking contractors.Mystery solved. [Advertisement] Infrastructure as Code built from the start with first-class Windows functionality and an intuitive, visual user interface. Download Otter today!

Dealing with types in dynamically-typed languages is always a challenge. Given a variable, does it hold a string? A number? An object? Without inspecting it, you have no idea!Thus, most of these languages have methods for inspecting variables, where you can ask questions like, “is this a number?” and then decide where to go from there. This can make validating your inputs a bit more difficult.Of course, this code Joe found might make it more difficult than it needs to be:

Steven was an engineer at a US-based company whose leadership had decided to take some dramatic cost-saving measures. A mandatory company meeting convened at 12:00PM, with nary a crumb of food in sight, to allow management to make their big announcement:"We're opening an office offshore, and one of the first things we'll be transitioning there is product documentation."Ah, transitioning: a nice way to say they were firing every US-based tech writer immediately. From that point forward, the engineers would have to send notes on product features to the offshore team, who would then compile the documentation.Steven was nervous about the prospect. He'd had a good working relationship with the tech writers. They could take his notes, add their personal experiences with the products, and compile it all into something useful (for the rare user who actually bothered to look at the manuals). Hesitantly, he raised his hand. "Will the offshore team be trained on our products?""Don't worry. We're working with a consulting company that's helping us hire the best talent available," the meeting presenter assured him with a saccharine smile. In other words, No way in hell. Steven saw through the ruse, but didn't have the guts to call it out. No one else did, either. After all, no one wanted to give management the idea that perhaps engineers were just as replaceable as tech writers.They had no choice but to wait and see. With any luck, the hiring firm would find some good writers, at least.A few weeks later, Steven sent off his first round of notes and crossed his fingers. Unfortunately, what he got back was his own notes copied and pasted into the standard manual template, surrounded with typos and broken English.No, wait, they hadn't just copied his notes. They'd tried to "improve" upon them. In one case where Steven explained the behavior of a quirky installer, he'd written:

The Best of Email feature is not one that gets a lot of traffic these days, but this particular submission couldn’t fit anywhere else. It started when Justus got a ticket: “customer spam filters are blocking our emails”. How on earth was he going to fix customer spam filters? He almost replied as much to the ticket, when he noticed that the end user had helpfully attached a sample email.This was the “to” line… and I present it here in its entirety, exactly as supplied by Justus. I apologize to mobile users in advance:

"I can't read German, but that doesn't look like glowing praise," writes Bruno G.

Alex T had hit the ceiling with his current team, in terms of career advancement. He was ready to be promoted to a senior position, but there simply wasn’t room where he was- they were top-heavy as it was, and there were whispers among management of needing to make some cuts from that team. So Alex started looking for other openings.There was another team at his company which had just lost all of its senior developers to other teams. Alex knew that was a bad sign, but in general, climbing the career ladder was a one-way street. Once he had a senior position, even if it was terrible, he could transfer to another team in a few months, keeping his senior title and salary.Perry was the team’s technical director. “I’ve been laying out the TPM architecture for years,” Perry explained, “and you are going to be part of implementing my vision.” That vision was an Internal Framework called “Total Process Management”, which, as the name implied, was a flexible business rules engine that would manage all of their business processes, from HR, to supply chain, to marketing, it would do everything. “We’re bringing the latest technologies to bear, it’ll be based on RESTful microservices with a distributed backend. But we need to staff up to achieve this, so we’re going to be doing a lot of interviews over the next few months, you and me.”Alex knew he could apply for another internal transfer after six months. He already saw this was a disaster, the only question was how disastrous would it be?While the code Perry had him writing was an overcomplicated mess of trendy ideas badly implemented, the worst part was doing the interviews. Perry sat in on every phase of the interview, and had Opinions™ about everything the candidate had on their resume.“You used Angular for that?” he demanded from one candidate, sneering, and drawing a bright red “X” on their resume. He criticized another for using a relational database when they could have used MongoDB. One interview ended early when the candidate admitted that they didn’t spend their nights and weekends hacking at personal projects.The worst part, for Alex, was his role in the technical screens. He’d read about the failures of white-board programming, the uselessness of asking trivia questions: “How do you reverse a linked-list?” wasn’t exactly a great interview question. He’d planned out a set of questions he thought would be better, and even some hands-on coding, but Perry nixed that.“I want you to build a test with an answer key,” Perry said. “Because at some point, we may want to have non-technical people doing a first-pass screening as our team grows and more people want to join it. Use that in the technical portion of the interview.”Interviews turned into days, days turned into weeks, weeks into months, and eventually Perry brought in Jack. Jack had worked at Google (as an intern), and Perry loved that. In fact, through the whole interview, Perry and Jack got on like a house on fire, smiling, laughing, happily bashing the same technologies and waxing rhapsodic over the joys of using Riak (Mongo was so last year, they were junking all of their database access to use Riak now).Eventually, Perry left and it was Alex’s turn to recite his test, and compare the results against his answer key. “What’s a linked-list?” he asked, dying on the inside.“It’s a navigation widget on websites.”Alex blinked, but continued. “How does a linked-list differ from a doubly-linked-list?”“A doubly-linked list has a pop-up menu so you can have more links in the list,” Jack said.For the first time since he’d written his test, Alex was actually excited to see the results. Jack wasn’t just wrong, he was finding incredibly new ways to be wrong. He claimed a binary-tree was a kind of legacy hard-drive. Or RAM, perhaps, it wasn’t really clear from his answer. Design Patterns were templates you could use… in Photoshop.Alex thanked Jack for his time, sent him on his way, and then went to compare notes with Perry.Perry was positively beaming. “I think we found a really great candidate,” he said. “Jack’s sharp as a tack, and is definitely a culture fit. What did you think?”“Well,” Alex started, and then stopped. Perry was difficult to handle, so Alex decided that he should be as diplomatic as possible. “It started pretty well, but when we started talking about data-structures- he was really weak. It’s a bad sign. We should pass.”“That’s probably not a big deal,” Perry said, “I don’t care if he knows Oracle or not. We use unstructured data.” [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.

We live in a brave new world. Microsoft, over the past few years has emphasized, more and more, a cross-platform, open-source approach. So, for example, if you were developing something in .NET today, it’s not unreasonable that you might want to parse a PList file- the OSX/NextStep/GNUStep configuration file format.But let’s rewind, oh, say, five years. An Anonymous reader found a third-party library in their .NET application. It never passed through any review or acquisition process- it was simply dropped in by another developer. Despite being a .NET library, it uses PLists as its configuration format- despite .NET offering a perfectly good in-built format. Of course, this C# code isn’t what we’d call good code, and thus one is left with an impression that someone hastily ported an Objective-C library without really thinking about what they were doing.For example, perhaps you have an object that you want to convert to a binary PList file. Do you, perhaps, use overriding and polymorphism to create methods which can handle this? Do you perhaps use generics? Or do you ignore all of the benefits of a type system and use a case statement and compare against the type of an object as a string?

There are certain tropes that show up in our articles, and judging from our comments section, our readers are well aware of them. For example, if a manager in a story says, “You’re going to love working with $X, they’re very smart,” it’s a pretty clear sign that the character in question is not very smart, and is almost certainly sure to be TRWTF in the story.Part of this is narrative convenience- we try and keep our articles “coffee-break length”, and dropping a few obvious signals in there helps keep it concise. Most of it, however, really boils down to the fact that reality is full of certain patterns. The world is full of people who aren’t half as smart as they think they are. There are legions of PHBs ready to micromanage even if they haven’t a clue what they’re doing. And there are a lot of employers that can make a terrible job sound really great for the duration of the interview process.Let’s focus on that last bit: finding a new job is hard. Finding a good job is even harder. At its worst, you end up suffering your way through a horror story that ends up on this site (so hey, Internet “fame”, it’s not all bad, right?). Maybe you just end up trading hours of your life for a paycheck, doing work that you don’t hate but you don’t love. If you’re really lucky, you land something that you really care about doing, and you get paid exactly what you’re worth.And let’s not even get into the job search process- it’s stressful and eats enough time to be a job in itself. You have to dance around recruiters who just want the commission and don’t care if the job’s a fit for anyone involved. You chuck your resume on job sites, which might as well be a black hole. You can end up investing countless hours into a company’s interview process only to get an offer that isn’t sufficient, or to discover that the company culture isn’t what you were looking for.Which brings us to our newest sponsor, Hired. Hired flips the script on the traditional job site. Once you fill out a simple application, employers start applying to interview you, instead of you applying for an interview. Whether you’re looking for a full-time or a contract gig, whether you’re looking for engineering, development, design, product management or data-science- Hired will match you up with top employers.And “top” doesn’t mean “gigantic” or “corporate”. Sure, there’s companies like Facebook on there. But in their pool of over 6,000 employers, they have everything from titans of industry to small startups, spread across 17 major cities in North America, Europe, Asia, & Australia.Okay, sure, there are lots of companies you might work for there, but what does this “apply to interview you” stuff mean? It sounds like marketing copy that Remy just pasted into this article to make the sponsor happy, and you’re right- but it’s also so much more.Once you have filled out Hired’s application, employers who are interested in your profile will send you a personalized interview request which includes salary information up front. Hired’s going to provide a “talent advocate” who can provide unbiased career advice to help you put the best foot forward. And Hired solves one of the worst problems of the job search: they hide your profile from current and past employers, so your boss will never find out you’re searching for a new job until you’re ready to tell them.And most important: you’ll never pay a dime for this service. So try it out and plan your next career change. [Advertisement] Otter, ProGet, BuildMaster – robust, powerful, scalable, and reliable additions to your existing DevOps toolchain.

A true story, recounted from personal experience by our own Snoofle.Many decades ago, DefCon Inc, a defense contractor working for the US military was attempting to get awarded a new contract to build some widget needed for combat. As part of their proposal, they wished to demonstrate that they had the available staff to dedicate to the project. Toward this end, they hired more than 1,000 assorted programmers, project leads, managers and so forth. The military folks that were evaluating the various proposals saw a slew of new employees that were completely unfamiliar with the relevant processes, procedures and requirements, and awarded the contract to another firm. In response, the contractor laid off all 1,000 folks.A few months later, another such contract came up for grabs. Again, they hired 1,000 folks to show that they had the staff. A few months later, that contract was also awarded to another contractor, and again, all 1,000 folks were laid off.This repeated a few times over two years.After all of this, the base of available employees was wise to the very short repeating hire/fire cycle, and the contractor was unable to attract anyone beyond folks fresh out of school. Finally, some C-level executive realized that all of these people just out of school were far cheaper than the experienced developers that were on staff and those that they had previously hired and fired for the potential projects, and so issued an edict that all in-house senior staff was to be cycled into cheap young employees. It took two years, but it happened.Now that their payroll was drastically reduced, and they had royally pissed off the potential pool of experienced developers, they could increase their permanent headcount without increasing their long term payroll costs - by hiring only young, inexperienced developers - which enabled them to finally get awarded a contract.Unfortunately, all those junior developers had very little experience, and there was nobody at the firm who had been through the war to guide them. As a result, their two year contract yielded a flaky project that frequently crashed, acted unpredictably and could not be modified. When you're dealing with a system that can shoot at and blow things up, these are not desirable or tolerable attributes.At some point, some high level exec realized what had happened, and forced the company to stick a crowbar into its pocket and hire some highly paid consultants. Unfortunately, the HPCs remembered the hire/fire cycle and wanted nothing to do with the place. After some time, this led to substantial sweetening of the pot until a few experienced folks finally agreed to come on board as full time employees. This happened in New Jersey.After management got the new folks up to speed on the project, the new folks said Hold on; there's a gaping hole in the middle of this project! Management replied that this part of the project was classified and could only be viewed by folks with secret clearances, and from the facility in California. OK, so relevant clearances were applied for and granted, and the senior folks were assigned to go to the CA facility for two weeks.Before agreeing to go, the developers wanted some information as to how they'd be able to access this stuff after being familiarized with it since it could only be accessed from CA, and they all lived and worked in NJ. They were told that they'd be advised of the details when they got to CA.OK, they all fly to the Left Coast, get settled in their hotels and go to the office.At this point, they were informed about all of the problems that had to be fixed. On Thursday of the second week, it was determined that there was about two years of work to do all of the retrofitting that needed to be done. Again, the developers all asked How will we access this stuff from NJ? The managers replied that it had to be done locally, and that they would all be located locally for the next two years. Starting Monday.Wait; they don't get the opportunity to discuss it with their spouses? How it might affect the kids to have one parent away 90+% of the time? Would they be willing to live in hotels and airports for two years? Why the F*** didn't they just hire talent at the CA location instead of NJ?It turns out that because the contractor is based in NJ, the personnel they hired needed to be based there as well. Of course, had any of this been mentioned before people were hired, most (if not all) of the folks they hired wouldn't have accepted the jobs. If they had known, none of the folks would have even gotten on the plane to go for the briefing and ramp-up required to familiarize themselves with the project.Needless to say, Thursday afternoon was spent with managers barking demands about sacrificing for the company, and developers saying WTF?! Thursday evening was spent with countless phone calls home. Friday morning was spent with everyone resigning and heading for the airport to go home.The representatives of the military acted as decent folks and were very understanding as to why people wouldn't just leave their homes and families for two years. They were far less sensitive when it came to holding the contractor to their promise of an on-site experienced staff to do the work.In the end, the contractor was fired and a new one was hired to clean up the mess. [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.

I once built a system with the job of tracking various laboratory instruments, and sending out notifications when they needed to be calibrated. The rules for when different instruments triggered notifications, and when notifications should be sent, and so on, were very complicated.An Anonymous reader has a similar problem. They’re tracking “Events”- like seminars and conferences. These multi-day events often have an end date, but some of them are actually open ended events. They need to, given an event, be able to tell you how much it costs. And our Anonymous reader’s co-worker came up with this solution to that problem:

"Good to see Santander finally embracing modern technology!" writes Sam B.

Every programming language embodies in it a philosophy about how problems should be solved. C reduces all problems to manipulations of memory addresses. Java turns every problem into a set of interacting objects. JavaScript summons Shub-Niggurath, the black goat of the woods with a thousand young, to eat the eyes of developers.Just following the logic of a language can send you a long way to getting good results. Popular languages were designed by smart people, who work through many of the problems you might encounter when building a program with their tools. That doesn’t mean that you can’t take things a bit too far and misapply that philosophy, though.Take this code, sent to us by “Kogad”. Their co-worker understood that objects and interfaces were fundamental to Java programming, so when presented with the challenge of three conditional statements, they created this:

On his first day at his new job, Sebastian wasn't particularly excited. He'd been around the block enough times to have grown a thick skin of indifference and pessimism. This job was destined to be like any other, full of annoying coworkers, poorly thought out requirements, legacy codebases full of spaghetti. But it paid well, and he was tired of his old group, weary in his soul of the same faces he'd grown accustomed to. So he prepared himself for a new flavor of the same office politics and menial tasks.It didn't faze him much when he walked into the IT office to pick up his credentials and heard the telltale buzzing and clicking of old Packard Bell servers. He simply adjusted his expectations for his own developer machine downward a few notches and walked back to his new office. Yes, this job came with a private office, and pay to match. For that, he could put up with a lot of BS.His login worked on the first try, which was pleasantly surprising. He expected Windows XP; when Vista loaded, he wasn't sure if he should be pleased that the OS was newer, or horrified that it was Vista. He could pretend it was 7 for a while at least, once he finished getting admin privileges and nerfing UAC. It'll take more than that to scare me off, he thought to himself as he fired up Outlook.Already, he had mail: a few welcome messages with new employee information, as well as his first assignment from his manager. Impressed with the efficiency in assigning work, if nothing else, he opened the message from his new boss.That first email went a little something like this:

Today, Aaron L. shares the tale of an innocent little network mapping program that killed itself with its own thoroughness:

Every industry has information that needs to be moved back and forth between disparate systems. If you've lived a wholesome life, those systems are just different applications on the same platform. If you've strayed from the Holy Path, those systems are written using different languages on different platforms running different operating systems on different hardware with different endian-ness. Imagine some Java app on Safari under some version of Mac OS needing to talk to some version of .NET under some version of Windows needing to talk to some EBCIDIC-speaking version of COBOL running on some mainframe.Long before anyone envisioned the above nightmare, we used to work with SGML, which devolved into XML, which was supposed to be a trivial tolerable way to define the format and fields contained in a document, with parsers on every platform, so that information could be exchanged without either end needing to know anything more than the DTD and/or schema for purposes of validation and parsing.In a hopelessful attempt at making this somewhat easier, wrapper libraries were written on top of XML.Sadly, they failed.In the health care industry, some open-source folks created the (H)ealthcare (API), or HAPI project, which is basically an object oriented parser for text-based healthcare industry messages. Unfortunately, it appears they suffered from Don't-Know-When-To-Stop-Syndromeâ„¢.Rather than implementing a generic parser that simply splits a delimited or fixed-format string into a list of text-field-values, the latest version implements 1205 different parsers, each for its own top-level data structure. Most top level structures have dozens of sub-structures. Each parser has one or more accessor methods for each field. Sometimes, a field can be a single instance, or a list of instances, in which case you must programmatically figure out which accessor to use.That's an API with approximately 15,000 method calls! WTF were these developers thinking?For example, the class: EHC_E15_PAYMENT_REMITTANCE_DETAIL_INFO can have zero or more product service sections. So right away, I'm thinking some sort of array or list. Thus, instead of something like:

"All I wanted to do was to unsubscribe from Credit Sesame emails, but instead I got more than I bargained for," writes Shawn A.

After his chilling encounter in the company’s IT Cave, new hire George spent some time getting his development workstation set up. Sadly, his earlier hope that the PC in his office was a short-term placeholder until something better comes in was dashed to pieces. This PC was a small-form-factor budget system, relying on an old dual-core processor, 2 GB RAM, a 5400 RPM “green” disk drive, and integrated graphics with a single output port, to which was connected an aging 17" LCD monitor with a failing backlight.George got to work installing software packages from a network drive, presumably clicking itself to death in the dark IT office. With a PC nearly ten years behind the curve, George had plenty of time, several days, in fact, to drink coffee while exploring the building. His unease from the encounter with the IT guy eventually faded as he met other employees who seemed as normal as he, discovering conference rooms with normal-looking Scrum boards, and offices and cubicles that would not appear out-of-place in any modern, successful software company. A friendly member of the Marketing Department even gave him some swag: logo’d pens and stress balls and notepads. Perhaps the unusual IT guy and his dark, precarious office was just an anomaly to an otherwise excellent organization.A week into his new job, George finally had his system set up enough to look around at the software products he’d be working on. During his interview, he’d been told everything was “superbly” documented.A coworker emailed him links to their developer documentation which was hosted on an internal server somewhere. George followed the link, and his web browser sat on a loading page for way too long. As he waited, and waited, and waited for the page to load, he almost thought he could hear the clicking and clunking of failing disk drives from whichever ancient pile of failing hardware served as the company’s documentation server, but eventually a SharePoint page presented itself on his screen.The “Developer Documentation” was unexpectedly short. In fact, George read through it faster than it took to load, feeling a sense of dread once he realized what it actually was: three pages of buzzword-laden marketing material! He read about how “superb” the application is and how it has helped millions of companies “leverage new synergies for key wins”. Nowhere could he find a simple, developer-centric description of the application. When he pressed for more documentation, his coworkers shrugged. “That is the documentation,” they explained. “The bosses say it’s good enough and it’s a waste of time to write more.”George’s sense of dread continued to increase.And so he did all he could. He checked out the application from source control and went spelunking.On his first run, he noticed the application’s text did not look right. Characters were glitched in various ways, with bad kerning, inconsistent alignment, and missing/extra pixels, though it was still generally readable with some effort.Thinking he was missing a dependency, he asked his coworkers for their opinion. “No, it normally does that,” they explained with a shrug. “Most of the time.”“Do we have unit tests for this?” he asked, but deep down in his gut he knew he wouldn’t like the answer.“Testing programs are in the design and planning stage,” they responded, even though the application had been on the market for eight years now. “The bosses don’t like to spend too much time on testing.”He still had no direction on what tasks to perform, so George took it upon himself to dig into the font issue, if nothing else to learn more about the codebase. He downloaded a few third-party font test programs from some prominent tech companies and they all agreed that the application had nearly 1,300 basic font rendering errors.His sense of dread was starting to overwhelm him as he considered his future. How could an application possibly have millions of sales and installs with nearly-unreadable fonts? And how could it possibly be maintained with no testing and no documentation?He wrote a memo explaining some of his findings and forwarded it to several coworkers, and asking various questions about it before putting too much effort into fixes that could cause issues unforseeable by a newbie who was not familiar with the history behind the application’s overly-complex font-handling codebase.Later that day, he received a long email directly from the company president. In tirade form, it explained that George was wasting time, there can’t possibly be that many bugs, and if anything like this happens again the time would be deducted from his paycheck. It ended with the president explaining that George was obviously a f***up who would never amount to anything at the company, but he was willing to give him another chance.George didn’t want another chance. As he walked past the IT Office on his way to the HR Office to announce his resignation, he briefly wondered how much damage his foam stress ball could do to already-failing disk drives if he were to chuck it through the door into the darkness within.[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!

In the early 2000s, it was a time of darkness, a world of fear, it was the age of XML. As someone who was just entering the industry at the time, you couldn’t type three lines of code without a PHB asking, “Have you considered using XML for this?” Since this was 2002, “this” was likely trying to find a way to emulate the marquee tag in JavaScript, the answer was usually, “No,” at which point you’d be reminded that we should be using XML for everything, so throw it out and start over in XML.One of the key selling points of the grand power of XML was the idea of schemas. These magical little files allowed you to use XML to specify the structure of some other XML, and then validate various XML documents against that schema. Combined with the ability to use namespaces, this was truly the One Format to Rule Them All™.The real magic, of course, was that since XML was a text based format with a clear (if complicated) parsing mechanism, it could be produced and consumed by any system, including those pesky legacy mainframes that were sure to be replaced any year now. Vendor after vendor came up with new and interesting ways to bolt XML onto your mainframe, so that you could wire modern applications up to those legacy back ends, and when you wanted to replace that legacy backend (they’re going away, any year now! Really!), you could slap a modern backend behind the same XML interface.I bring up this history lesson because John B works for a “very large, government-type” organization. He maintains an XML data-feed that passes around location data. I strongly suspect that the schema for that XML data-feed was generated based off of an older flat-file dataset from a legacy system. Why? Well, let’s look at a sample file.

Git is a divisive piece of technology. There's a number of people who insist that it's the best of all possible version controls, often citing the fact that a complete repo copy is on everyone's computers in case of emergency. There are also a lot of horror stories of people screwing up commands and ending up neck-deep in tutorials, desperately trying to undo what they did. Recently, I was involved in a discussion about the merits of Mercurial. The usual git fans stopped by to ridicule the lack of history-rewriting in Mercurial, insisting that it's a necessary part of any version control. Which reminded me of this reader submission ...Toni worked at a certain company that worked on inventory systems, and was also a defense contractor. Her manager quit out of protest; the new boss—whose name was Alexander, but he insisted on being called "Lex"—was assigned to the team from upon high. Lex was a dopey corporate puppet who liked to talk about Bob Dole a lot. The best the team could hope for was that he'd stay out of their way, making vague promises about the future but not actually accomplishing anything. After all, they had done just fine without a boss for eight months.What they didn't know? Lex had been given the keys to the kingdom: their server git repository, and everything in it.One fateful morning, Toni woke up at 4:00 AM to an SMS saying that the code repository at work had been accessed by "a new member of the compliance team."... What? she wondered, groggily. There was no new member on the "compliance team." That wasn't even a real department name! Damn it, we've been hacked.She rushed to the office, wide awake at this point, praying for no cops with speed guns on the way there.Did someone break in? she wondered. Or worse, hack into the local code repository from one of the ports the IT guys kept forgetting to close? Surely a randomly generated password longer than a bible couldn't have been cracked, right?By 8:00 AM, she hadn't found any sign of intrusion. She was asleep at her desk from exhaustion when her co-worker, Clarissa, came in. Clarissa had just wiped her MacBook Pro clean the night before due to a botched OS X update. She had also gotten a text message, but had assumed it was Toni, as she'd been working late the night before.Clarissa was able to discover what Toni had overlooked: to their horror, two new people, with names 20 characters long, had been "invited" into the team, and the team had been "renamed" to Compliance.That was when they both got an email from Lex. I thought you could use some help! :)That "help" came in the form of two dimwits from the Chennai, India branch, recently acquired by merger a year before. Through Slack, they admitted to the existing team members that they had never used a version control system before.Toni was already seeing red at this point, but the day was just beginning to reveal the depths of insanity that were in store for them.The two new team members had decided that the color of the web-based inventory front-end wasn't "good enough." Now, this had just gone through a redesign; the colors matched the official design guideline, and had been agreed on by numerous stakeholders. Not only did the newbies change the colors, they decided to deploy those changes to the main Internet-facing servers without going through QA.Toni was still processing that little gem when she heard the fires of hell erupt from Clarissa's cubicle.Clarissa told Toni that their "friends" had pushed code to master, bypassing QA, while also tinkering with her custom branches. As if that wasn't bad enough, they'd used an editor that had converted all the source code files on her branch to Windows format, which screwed up all the line endings. Immediately, this caused conflicts with the existing frameworks, and one of their parsers no longer worked.In a fit of brillance, the two new helpers had decided a force push would do the trick. Surely it couldn't be their color tweak breaking things, right? Apparently, they'd figured out that it was. Shortly after, they'd copied over the files from master, pasted them in the working folder, and force pushed with a fake name, erasing all history on said branch in a terrible attempt to cover their tracks.Remember how Clarissa had wiped her MacBook the night before? If Toni hadn't cloned the entire repository to her ThinkPad for Thanksgiving tinkering, Clarissa would've lost four to eight months of work.They received word that the interim manager, on vacation in Tampa, had hopped on a plane after getting the same SMS they did. He could've flown in with his own two arms given the level of pissed-off he was when he slammed open the office door. Lex walked in with coffee to see the door nearly fly off the hinges.It turned out that the website had been inoperable for eight hours. With worldwide clients, this was a bad, bad thing. After the interim manager finished steamrolling Lex with expletives, he told the team that, due to US regulations, using foreign workers without security clearances could bring up to $10K of fines per infraction.Salespeople barged in behind him with questions about why the interface had changed without any notification. The QA team followed the salespeople, also demanding answers.Lex turned the color of wax paper. "Well, I guess I should remove the other twenty guys I just added to the repository, then."Lex is no longer with the company. [Advertisement] Universal Package Manager - ProGet easily integrates with your favorite Continuous Integration and Build Tools, acting as the central hub to all your essential components. Learn more today!

We’ve passed Christmas and made our way through a Steam sale with our wallets mostly intact, and now most of us have a pile of games that we’ll probably never actually play.Game programming is hard. Setting aside the “cultural” problems in the industry- endless crunches, compensation tied to review scores, conflicts between publishers and studios, and a veneer of glamour over unglamorous work- the actual work of developing a game is a hard job.Building a game engine is even harder. Not only do you have to build highly performant code, you have to build a system flexible enough so that game developers can build a game on top of it. You need to provide a set of high-level abstractions that make it easy for them to build a game, and this is where the problems come in.For example, I went through a brief period of playing Frozen Cortex, an interesting approach at a turn-based sports game. I was stunned at how badly it performs, though. Weirdly, it’s not during gameplay that performance stinks, but when staring at the menus. I was puzzling over this for some time, when Anonymous sent us a message.You see, Frozen Cortex is build on the Torque engine, and our anonymous submitter is working on a different game that also uses the Torque engine. And they’ve encountered a few… special warts.First, take a look at this code:

While looking at our most popular CodeSODs this year, I noticed we had two popular ones that both involved the ternary operator. So, what the heck, this one's a twofer. Originally, "As the World Ternaries" and, "Returnary". -- Remy As the World TernariesAh, 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:

Instead of our standard workplace fare, this story is a bit different, because TRWTF is the Windows Registry. --RemyWhat, again? Michael stared at the Explorer window in disbelief. The free disk space bar was glowing red, and the text underneath reported that his half-terabyte system partition had a measly few gigs left before filling up.When it had first happened, he hadn't thought twice about it. In fact, he'd been rather glad; at least he'd had the motivation to finally discard all the games and software he would never use again. But when the disk space ran out again the next month, and again the month after, he started getting more and more worried. Was he really using that much space, or was something else going on?Curious, he decided to finally investigate the issue. A cursory look at his hard drive with WinDirStat confirmed his suspicions. With over 80 percent of his hard drive space labelled as "unknown", something was definitely amiss. He kept searching, manually scouring through his folders and files, until finally he managed to pinpoint the culprit: an innocuously named "C:\Windows\System32\Config" folder filled with hundreds of thousands of files, taking up 420 gigabytes in size.A quick trip to Google and a bit of playing with Process Monitor revealed the answer to the mystery. As it turned out, every modification to Windows Registry—the oft-derided database of all the Windows and Windows application settings—generated a transaction log file to ensure the data integrity, prevent corruption, and allow rollback of changes. Usually those small 512KB files weren't much of an issue. They got deleted after a clean reboot, and most software only modified the registry during installation or after a configuration change.However, some applications and drivers—among them, Nvidia's 3D service—didn't play nice with the registry, shuffling the values around every few seconds or minutes. That, together with Michael's habit of not turning the computer off too often, resulted in cluttering the disk with more and more files until it filled up completely.The solution, luckily, was rather simple. Michael purged the folder of all but the most recent log files, then uninstalled all the unnecessary bloatware from Nvidia, hoping it was the last thing he'd be deleting for a long while.[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!

This week, we're reviewing the best WTFs of the year. In this installment, overreactions from management are their own WTF. --RemyAn investment bank had just completed development on a new digital retailing platform. Daniel was assigned to a cross-functional automated test team, gearing up to test the platform's web application—or at least trying to. Charlie, a veteran manual tester from QA, had been vocal in his opposition."Automated tests need to be tested themselves, which means the testers need to test the tests, so automation doesn't save anything. If anything, it creates more work! Besides, we should always be striving to recreate the user experience as closely as possible!"Daniel and the other developers insisted that manual testing was valuable, but automation needed to happen too. The conflict marched up the org chart, culminating in a meeting with Charlie's boss, Daniel's boss, their bosses, their bosses' bosses, all the way up to where these branches of the organization finally joined.The verdict was handed down. Charlie was appointed the leader on testing the web application, running through the same test cases in a manual fashion to catch any problems that fell through the cracks.The team—developers, QA, and a tech lead—all abandoned their cubes to huddle together in a large conference room. Everything went smoothly until one afternoon, when Charlie piped up with the nervousness of one staring down a cobra poised to lash out."Fellas? I don't know how I did it, but I hacked into the website somehow. I see all of the code."The people seated closest to him glanced up from their work to trade frowns."What do you mean?" Daniel asked, glancing across the table at Charlie."I'm in the browser, and I can see all of the code!" Charlie explained. "I've hacked into the website. I see stuff like, 'div class equal sign—'"In other words, the HTML source. Those who were listening in burst into relieved laughter, prompting everyone else in the room to quit their work and pay attention to the faux emergency.The far more patient tech lead bit her bottom lip to hide her grin. "Charlie, it sounds like you opened the developer tools in Chrome by accident. Press F12, it'll go away."Charlie hunted down the key and pecked it with a single loud stroke. "OK, it's gone," he said as though he’d just diverted a nuclear strike. His gaze swept over the room with a mix of urgency and confusion. "I'm still really concerned. That shouldn't happen!""It's supposed to do that," Daniel explained. "Go to any website you want, you can do that on any of them.""What?!" Charlie flipped to a different browser tab, then pressed F12 again. "What?! No!"Another burst of laughter drowned out his concern."Check out the leet haxxor here," one of the developers cracked."Step away from the computer, Charlie, before you hack the whole Internet!" another developer commanded, pointing a finger-gun at the hapless tester."Charlie, it's just—" Daniel tried to say."We can't keep using this browser!" Charlie declared. "I'm raising a defect for this!""All browsers have something like that for debugging purposes," Daniel explained. "It's not just Chrome."But as the giggles continued around him, Daniel's plea seemed to fall on deaf ears. Charlie tabbed over to their bug tracker and took to some furious hunting and pecking.Daniel shook his head. Let Charlie log his defect if it made him feel better. Surely no one would take it seriously.Unfortunately, QA heads and project leads took "security threats" very seriously. The conflict escalated up through bosses, bosses' bosses, and eventually, the verdict was handed down. To avoid exposing code to users, further web development and testing involving Chrome was suspended company-wide. [Advertisement] Application Release Automation – build complex release pipelines all managed from one central dashboard, accessibility for the whole team. Download and learn more today!

As we review this year's greatest hits, let's revisit the latest incarnation of the dreaded "Inner Platform Effect". --RemyJake 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: