The Daily WTF

Banks. They take your money and lend it to others. They lend money deposited by other people to you, either as a car loan, mortgage, or for credit card purchases. For this privilege, you give them all of your personal information, including your social security number. Implicit in that exchange is the fact that the bank should keep your personal information confidential. Security is important. One might think that such a concept would be important to banks. One would be wrong.To be fair, the high ranking people at the banks probably believe that all of their customer information should be - and is - secure and protected. Unfortunately, there are multiple layers of middle and lower management (that we all know all too well) that might not comprehend that point.The other thing that banks do is nightly batch processing to keep assorted records updated, generate TPS reports, issue bills, update financial inventory, credit usage and so forth. Since customers tend to hit ATMs at all hours of the day and night, you want your systems-update processing to be able to occur while the system is live. To that end, date and timestamp ranges of transactions to be processed for a given business period usually come into play in some form. The point is that you shield your ongoing transactions from reconciliation activity by excluding it from the reconciliations. The beat business goes on.Randy worked at a major bank in the Pittsburgh, PA area. Considering that it's a major bank, it seemed odd that their customer facing website was often down for more than an hour at a time during business hours. When he started in 2016, it took about a month to get permissions to get the development tools he needed installed. Hmmm, perhaps they are vigilant about controlling access to their environments, even development; possibly a good, if bureaucratic sign. Once set up, he was assigned to work on their Web Banking app which was written not in MVC but in ASP.NET WebForms. OK, maybe they're slow to adopt newer technologies because they want someone else to beta test them. Caution can be a good sign.As part of doing his work, Randy sent SOAP messages to the mainframe to retrieve test data for developmental testing. One day, he deduced that the test social security number was that of his boss. He verified this by asking his boss what he had for lunch that day. Sure enough, there were debit card charges for it in the test environment. Uh oh.That's right; live data in the test environment. Anyone with even novice skills could have gotten social security, routing and account numbers for every customer of the bank! Rather than fight with the, ahem, highly knowledgeable individuals that thought that this was a good setup - and potentially be blamed for any breaches, Randy chose to jump ship and head for saner pastures.Interestingly, I went to their website, which states that their business hours are M-F 8AM-8PM and Sat 9AM-3PM. At 1:15 on a clear, dry Saturday when the bank should have been open for business, I called the bank posing as a potential customer to ask why their website is often down for more than an hour at a time almost every single night. The auto attendant said to try back during business hours.Hmmm... [Advertisement] ProGet can centralize your organization's software applications and components to provide uniform access to developers and servers. Check it out!

Tim B. had been tasked with updating an older internal application implemented in Java. Its primary purpose was to read in and display files containing a series of XY points—around 100,000 points per file on average—which would then be rendered as a line chart. It was notoriously slow, taking 1-2 minutes to process each file, but otherwise remained fairly stable.Except that lately, some newer files were failing during the loading process. Tim quickly identified the problem—date formats had changed—and fixed the necessary code. Since the code that read in the XY points happened to reside in the same class, Tim asked his boss whether he could take a crack at killing two birds with one stone. With her approval, he dug in to figure out why the loading process was so slow.

So here's a thing that keeps me up at night: we get a lot of submissions about programmers who cannot seem to think like users. There's a type of programmer who has never not known how computers worked, whose theory of computers in their mind has been so accurate for so long that they can't look at things in a different way. Many times, they close themselves off from users, insisting that if the user had a problem with using the software, they just don't know how computers work and need to educate themselves. Rather than focus on what would make the software more usable, they program what is easiest for the computer to do, and call it a day.The same is sometimes true of security concerns. Rather than focus on what would be secure, on what the best practices are in the industry, these programmers hammer out something easy and straightforward and consider it good enough. Today's submitter, Rick, recently ran across just such a "security system."Rick was shopping at a small online retailer, and found some items he liked. He got through the "fill in all your personal information and hope they have good security" stage of the online check-out process and placed his order. At no time was he asked if he wanted an account—which is good, because he never signs up for accounts at small independent retailers, preferring for his card information not to be stored at all. He was asked to fill in his email, which is common enough; a receipt and shipping updates are usually sent to the email associated with the order.Sure enough, Rick received an email from the retailer moments later. Only this wasn't a receipt. It was, in fact, confirmation of a new account creation ... complete with a password in plain text.Rick was understandably alarmed. He headed back to the site immediately to change the password to a longer, more secure one-off he could store in a password manager and never, ever have emailed to him in plaintext. But once on the site, he could find no sign of a login button or secure area. So at this point, he had an insecure password he couldn't appear to use, for an account he didn't even want in the first place.Rick sent an email, worried about this state of affairs. The reply came fairly rapidly, from someone who was likely the sole tech department for the company: this was by design. All Rick had to do next time he purchased any goods was to enter the password on the checkout screen, and it would remember his delivery address for him.As Rick put it:

In software development, there are three kinds of problems: small, big and subtle. The small ones are usually fairly simple to track down; a misspelled label, a math error, etc. The large ones usually take longer to find; a race condition that you just can't reproduce, an external system randomly feeding you garbage, and so forth.The subtle problems are an entirely different beast. It can be as simple as somebody entering 4321 instead of 432l (432L), or similar with 'i', 'l', '1', '0' and 'O'. It can be an interchanged comma and period. It can be something more complex, such as an unsupported third party library that throws back errors for undefined conditions, but randomly provides so little information as to be useful to neither user nor developer.Brujo B encountered such a beast back in 2003 in a sub-equatorial bank that had been especially fond of VB6. This bank had tried to implement standards. In particular, they wanted all of their error messages to appear consistently for their users. To this end, they put a great deal of time and effort into building a library to display error messages in a consistent format. Specifically:

It feels as though disc-based media have always been with us, but the 1990s were when researchers first began harvesting these iridescent creatures from the wild in earnest, pressing data upon them to create the beast known as CD-ROM. Click-and-point adventure games, encyclopedias, choppy full-motion video ... in some cases, ambition far outweighed capability. Advances in technology made the media cheaper and more accessible, often for the worst. There are some US households that still burn America Online 7.0 CDs for fuel.But we’re not here to delve into the late-90s CD marketing glut. We’re nestling comfortably into the mid-90s, when Internet was too slow and unreliable for anyone to upload installers onto a customer portal and call it a day. Software had to go out on physical media, and it had to be as bug-free as possible before shipping.Chris, a developer fresh out of college, worked on product catalog database applications that were mailed to customers on CDs. It was a small shop with no Tech Support department, so he and the other developers had to take turns fielding calls from customers having issues with the admittedly awful VB4 installer. It was supposed to launch automatically, but if the auto-play feature was disabled in Windows 95, or the customer canceled the installer pop-up without bothering to read it, Chris or one of his colleagues was likely to hear about it.And then came the caller who had no clue what Chris meant when he suggested, "Why don't we open up the CD through the file system and launch the installer manually?"These were the days before remote desktop tools, and the caller wasn't the savviest computer user. Talking him through minimizing his open programs, double-clicking on My Computer, and browsing into the CD drive took Chris over half an hour."There's nothing here," the caller said.So close to the finish line, and yet so far. Chris stifled his exasperation. "What do you mean?""I opened the CD like you said, and it's completely empty."This was new. Chris frowned. "You're definitely looking at the right drive? The one with the shiny little disc icon?""Yes, that's the one. It's empty."Chris' frown deepened. "Then I guess you got a bad copy of the CD. I'm sorry about that! Let me copy down your name and address, and I'll get a new one sent out to you."The customer provided his mailing address accordingly. Chris finished scribbling it onto a Post-it square. "OK, lemme read that back to—""The shiny side is supposed to be turned upwards, right?" the customer blurted. "Like a gramophone record?"Chris froze, then slapped the mute button before his laughter spilled out over the line. After composing himself, he returned to the call as the model of professionalism. "Actually, it should be shiny-side down.""Really? Huh. The little icon's lying, then.""Yeah, I guess it is," Chris replied. "Unfortunately, that's on Microsoft to fix. Let's turn the disc over and try again." [Advertisement] Incrementally adopt DevOps best practices with BuildMaster, ProGet and Otter, creating a robust, secure, scalable, and reliable DevOps toolchain.

Every year, Initrode Global was faced with further and further budget shortages in their IT department. This wasn't because the company was doing poorly—on the contrary, the company overall was doing quite well, hitting record sales every quarter. The only way to spin that into a smaller budget was to dream bigger. Thus, every quarter, the budget demanded greater and greater increases in sales, and the exceptional growth was measured against the desired phenomenal growth and found wanting.IT, being a cost center, was always hit by budget cuts the hardest. What did they need money for? The lights were still on, the mainframes still churning; any additional funds would only encourage them to take wild risks and break things.One of the things people were worried about breaking were the thin clients. These had been purchased some years ago from Smyrt, who had been acquired the previous year by Hell Computers. There would be no tech support or patching, not from Hell. The IT department was on their own to ensure the clients kept running.Unfortunately, the things seemed to have a will of their own—and that will did not include remaining up for weeks on end. Every once in a while, when booting Linux on the thin clients, the Thin Film Transistor screen would turn dark as soon as the X server started. They would remain dark after that; however, when the helpdesk SSH'd into the system, the screen would of course render perfectly on their end. So there was nothing to do to troubleshoot except lug a thin client to their work area and test workarounds from there.The worst part of this kind of troubleshooting is when the problem is an intermittent one. The only way they could think to reproduce the problem was to spend hours in front of the client, turning it off and back on again. In the face of budget cuts, the already understaffed desk had no manpower to do something so trivial and dull.Tedium is the mother of invention. Many of the most ingenious pieces of automation were put in place when an enterprising programmer was faced with performing a mind-numbing task over and over for the foreseeable future. Such is the case in this instance. Lacking the support staff to power cycle the machine over and over, the staff instead built a robot.A webcam was found in the back room, dusty and abandoned, the last vestige of a proposed work-from-home solution that never quite came to fruition years before. A sticker of transparent rubber someone found in their desk was placed over the metal rim of the camera so it wouldn't leave any scratches on the glass of the TFT screen. The webcam was placed up close against one strategically chosen corner of the screen, and attached to a Raspberry Pi someone brought from home.The Pi was programmed to run a bash script, which in turn called a CLI image-grabbing tool and then applied some ImageMagick filters to determine the brightness value of the patch of screen it could see. This brightness value was compared against a known list of brightnesses to determine which state the machine was in: the boot menu, the Linux kernel messages scrolling past, the colorful login screen, or the solid black screen representing the problem. When the Pi detected a login screen, it would run a scripted reboot on the thin client using SSH and a keypair. If, instead, the screen remained dark for a long period of time, it would send an IM through the company messaging solution to alert the staff that they could begin their testing, then exit.We've seen machines with the ability to manipulate physical servers. Now, we have machines seeing and evaluating the world in front of them. How long before we reach peak Skynet potential here at TDWTF? And what would the robot revolution look like, with founding members such as these? [Advertisement] Incrementally adopt DevOps best practices with BuildMaster, ProGet and Otter, creating a robust, secure, scalable, and reliable DevOps toolchain.

Steven worked for a company that sold “big iron” to big companies, for big bucks. These companies didn’t just want the machines, though, they wanted support. They wanted lots of support. With so many systems, processing so many transactions, installed at so many customer sites, Steven’s company needed a better way to analyze when things went squirrelly.Thus was born a suite of applications called “DICS”- the Diagnostic Investigation Console System. It was, at its core, a processing pipeline. On one end, it would reach out to a customer’s site and download log files. The log files would pass through a series of analytic steps, and eventually reports would come out the other end. Steven mostly worked on the reporting side of things.

We've all seen code that ignores errors. We've all seen code that simply rethrows an exception. We've all seen code that wraps one exception for another. The submitter, Mr. O, took exception to this exceptionally exceptional exception handling code.I was particularly amused by the OutOfMemoryException handler that allocates another exception object, and if it fails, another layer of exception trapping catches that and attempts to allocate yet another exception object. if that fails, it doesn't even try. So that makes this an exceptionally unexceptional exception handler?! (ouch, my head hurts)It contains a modest amount of fairly straightforward code to read config files and write assorted XML documents. And it handles exceptions in all of the above ways.You might note that the exception handling code was unformatted, unaligned and substantially larger than the code it is attempting to protect. To help you out, I've stripped out the fairly straightforward code being protected, and formatted the exception handling code to make it easier to see this exceptional piece of code (you may need to go full-screen to get the full impact).After all, it's not like exceptions can contain explanatory text, or stack context information...

A few years ago I was hired as an architect to help design some massive changes to a melange of existing systems so a northern foreign bank could meet some new regulatory requirements. As a development team, they gave me one junior developer with almost a year of experience. There were very few requirements and most of it would be guesswork to fill in the blanks. OK, typical Wall Street BS.The junior developer was, well, junior, but bright, and he remembered what you taught him, so there was a chance we could succeed.The setup was that what little requirements there were would come from the Almighty Project Architect down to me and a few of my peers. We would design our respective pieces in as generic a way as possible, and then oversee and help with the coding.One day, my boss+1 has my boss have the junior guy develop a web service; something the guy had never done before. Since I was busy, it was deemed unnecessary to tell me about it. The guy Googled a bit and put something together. However, he was unsure of how the response was sent back to the browser (e.g.: what sort of line endings to use) and admitted he had questions. Our boss said not to worry about it and had him install it on the dev server so boss+1 could demo it to users.Demo time came, and the resulting output lines needed an extra newline between them to make the output look nice.The boss+1 was incensed and started telling the users and other teams that our work was crap, inferior and not to be trusted.WTF?!When this got back to me, I went to have a chat with him about a) going behind my back and leaving me entirely out of the loop, b) having a junior developer do something in an unfamiliar technology and then deploying it without having someone more experienced even look at it, c) running his mouth with unjustified caustic comments ... to the world.He was not amused and informed us that the work should be perfect every time! I pointed out that while everyone strives for just that, that it was an unreasonable response, and doesn't do much to foster team morale or cooperation.This went back and forth for a while until I decided that this idiot simply wasn't worth my time.A few days later, I hear one of my peers having the same conversation with our boss+1. A few days later, someone else. Each time, the architect had been bypassed and some junior developer missed something; it was always some ridiculous trivial facet of the implementation.I got together with my peers and discussed possibly instituting mandatory testing - by US - to prevent them from bypassing us to get junior developers to do stuff and then having it thrown into a user-visible environment. We agreed, and were promptly overruled by boss+1. Apparently, all programmers, even juniors, were expected to produce perfect code (even without requirements) every time, without exception, and anyone who couldn't cut it should be exposed as incompetent.We just shot each other the expected Are you f'g kidding me? looks.After a few weeks of this, we had all had enough of the abuse and went to boss+2, who was totally disinterested.We all found other jobs, and made sure to bring the better junior devs with us. [Advertisement] Easily create complex server configurations and orchestrations using both the intuitive, drag-and-drop editor and the text/script editor. Find out more and download today!

We Sell Bonds!The quaint, brick-faced downtown office building was exactly the sort of place Alexis wanted her first real programming job to be. She took a moment to just soak in the big picture. The building's façade oozed history, and culture. The busy downtown crowd flowed around her like a tranquil stream. And this was where she landed right out of college-- if this interview went well.Alexis went inside, got a really groovy start-up vibe from the place. The lobby slash waiting room slash employee lounge slash kitchen slash receptionist desk was jam packed full of boxes of paperwork waiting to be unpacked and filed (once a filing cabinet was bought). The walls, still the color of unpainted drywall, accented with spats of plaster and glue-tape. Everything was permeated with chaotic beginnings and untapped potential.Her interviewer, Mr. Chen, the CEO of the company, lead her into the main conference room, which she suspected was the main conference room by virtue of being the only conference room. The faux-wood table, though moderately sized, still barely left room for herself and the five interviewers, crammed into a mish-mash of conference-room chairs, office chairs and one barstool. At least this room's walls had seen a coat of paint-- if only a single coat. Framed artwork sat on the ground, leaned up gently against the wall. She shared the artwork's anticipation-- waiting for the last coat of paint and touch-ups to dry, to hang proudly for all to see, fulfilling their destiny as the company grew and evolved around them."Thank you for coming in," said Mr. Chen as he sat at the head of the conference table."Thank you for having me," Alexis replied, sitting opposite him, flanked by the five other interviewers. She was glad she'd decided to play cautious and wear her formal 'Interview Suit'. She fit right in with the suits and ties everyone else was wearing. "I really dig the office space. How long have you been here?""Five years," Mr. Chen answered.Her contextual awareness barely had time to register the whiplash of unpainted walls and unhung pictures in a long occupied office-- not that she had time to process that thought anyways."Let the interview begin now," Mr. Chen said abruptly. "Tell me your qualifications.""I-- uh, okay," Alexis sat up straight and opened her leather folder, "Does everyone have a copy of my resume? I printed extra in case-- ""We are a green company," Mr. Chen stated.Alexis froze for a moment, her hand inches from the stack of resumes. She folded her hands over her own copy, smiled, and recovered. "Okay. My qualifications..." She filled them in on the usual details-- college education, GPA, co-op jobs, known languages and frameworks, contributions to open source projects. It was as natural as any practice interview she'd ever had. Smile. Talk clearly. Make eye contact with each member of the interview team for an appropriate length of time before looking at the next person.Though doing so made her acutely aware that she had no idea who the other people were. They'd never been introduced. They were just-- there.As soon as she'd finished her last qualification point, Mr. Chen spoke. "Are you familiar with the bonds market?"She'd done some cursory Wikipedia research before her interview, but admitted, "An introductory familiarity.""You are not expected to know it," Mr. Chen said, "The bond market is complicated. Very complicated. Even experienced brokers who know about futures contracts, forward contractions, options, swaps and warrants often have no idea how bonds work. But their customers still want to buy a bond. The brokers are our customers, and allowing them to buy bonds is the sole purpose of 'We Sell Bonds!'."Though Mr. Chen had a distinctly dry and matter-of-fact way of speaking, she could viscerally HEAR the exclamation point in the company's name."Very interesting," Alexis said. Always be sure to compliment the interviewer at some point. "What sort of programming projects would I be working on?""The system is very complicated," Mr. Chen retorted. "Benny is our programmer."One of the suited individuals to her left nodded, and she smiled back at him. At least now she knew one other person's name."He will train you before you may modify the system. It is very important the system be working properly, and any development must be done carefully. At least six months of training. But the system gathers lots of data, from markets, and from our customers. That data must be imported into the system. That will be part of your duties."Again, Alexis found herself sitting behind a default smile while her brain processed. The ad she'd answered had clearly been for a junior developer. It had asked for developer skills, listed must-know programming languages, and even been titled 'Junior Developer'. Without breaking the smile, she asked, "What would you say the ratio of data handling to programming would be?""I would say close to one hundred percent."Alexis' heart sank, and she curled her toes to keep any physical sign of her disappointment showing. She mentally looked to her sliver-linings view. Sure, it was data entry-- but she'd still be hands-on with a complicated financial system. She'd get training. Six months of training, which would be a breeze compared to full-time college. And if there really was that much data entry, then the job would be perfect for a fresh mind. There'd be TONS of room for introducing automation and efficiency. What more could a junior developer want?"That sounds great," Alexis said, enthusiastic as ever."Good," Mr. Chen said. "The job starts on Monday."Her whiplash systems had already long gone offline from overload. Was that a job offer?"That-- sounds great!" Alexis repeated."Good. Nadine will email your paperwork. Email it back promptly."And now Alexis knew a second person's name. "I look forward to meeting the whole company," she said aloud."You have," Mr. Chen replied, gesturing to the others at the table. "We will return to work now. Good day."Alexis found herself back on the sidewalk outside the quaint brick-faced downtown office building, gainfully employed and not sure if she actually understood what the heck had just happened. But that was a problem for Monday.#Alexis arrived fifteen minutes early for her first day at the quaint brick-faced downtown office-- no, make that HER quaint brick-faced downtown office.Fourteen minutes later, Mr. Chen unlocked the front-door from the inside, and let her in."You're early," he stated, locking the door behind her."The early bird gets the worm," she clichéd."You don't need to be early if you are punctual. Follow."Mr. Chen lead her through the lobby, and once again into the main boardroom. As before, five people sat around the conference table. Alexis figured there'd be formalities and paperwork to file before she got a desk. HER desk! The whole company (all six of them-- though now it was seven) were here to greet her. And, for some reason, they'd brought their laptops."You will sit beside Benny," Mr. Chen said, taking his seat."I-- huh?"Next to Benny, there was an empty chair, and an unoccupied laptop. Alexis slunk around the other chairs, careful not to knock over the framed posters that were still propped against the wall, and sat beside the lead programmer."Morning meeting before getting down to work, huh?" she said, smiling at him.Benny gave her a sideways glance. "We are working."Alexis wasn't sure what he meant-- and then she noticed, for the first time, that everyone was heads down, looking at their screens, typing away. This wasn't just a boardroom. This was her desk. This was everyone's desk.Over the morning, Benny gave her his split attention-- interspersing his work with muttering instructions to her; how to log in, where the data files were, how to install Excel. He would only talk to her in-between steps of his task; never interrupting a step to give her attention. Sometimes she just sat there and watched him watch a progress bar. She gathered he was upgrading a server's instance of SQL Server from version "way too old" to version "still way too old, but not as much".After lunch (also eaten at the shared desk), Benny actually looked at her."Time for your first task," he said, giving her a sheet of paper. "We have a new financial institution buying bonds from us. They will use our Single SignOn Solution. You will need to create these accounts."She took the sheet of paper, a simple printed table with first name, last name, company name, username and password.Alexis was recently enough out of college that "Advanced Security Practices 401" was still fresh in her mind-- and seeing a plaintext password made her bones nearly crawl out of her skin."I-- um-- are there supposed to be passwords here?"Benny nodded. "Yes. To facilitate single sign-on, usernames and passwords in 'We Sell Bonds!' website must exactly match those used in the broker's own system. Their company signs up for 'We Sell Bonds!', and they are provided with a website skinned to look like their own. The company's employees are given a seamless experience. Most don't even know they are on a different site."Her skin gnawed on her bones to keep them in place. "But, if the passwords here are in plaintext, that is their real, actual password?"Benny gave her the same nod. "They must be. Otherwise we could not log in to test their account."That either made perfect sense, or had dumbfounded all the sense out of Alexis, so she just said "Ok." The rest of the day was spent creating accounts through an ASP interface, then logging into the site to test them.When she arrived at the quaint brick-faced office building the next day, there was a large stack of papers at her spot at the communal desk. Benny said, "Mr. Chen was happy with your data entry yesterday."Mr. Chen, who was seated at the head of the shared desk, didn't look up from his laptop screen. "You are allowed to enter this data too.""Thank you?" Alexis settled in, and got to work. For every record she entered, a different way of optimizing this system would flitter through her mind. A better entry form, maybe auto-focus the first field? How about an XML dump on a USB disk? Or a SOAP service that could interface directly with the database? There could be a whole validation layer to check the data and pre-emptively catch data errors.Data errors like the one she was looking at right now. She waited patiently for Benny to complete whatever step of his task he was on, and showed him the offending records."I don't see the problem," Benny said, shortly."John Smith and Jon Smith both have the same username, jsmith" she said, not sure how to make it more clear."Yes, they do," Benny confirmed."They can't both have the same username.""They can!" Mr. Chen's sudden interjection startled her-- though she wasn't sure if it was because of the sharpness of his tone, or because she hadn't actually heard him speak for a day and a half. "Do you not see that they have different passwords?""Uh," Alexis checked, "They do. But the username is still the same."There was no response. Mr. Chen was already looking back at his screen. Benny was looking at her expectantly."So users are differentiated by their-- password?" she said, trying to grasp what the implications of that would be. "What if someone changes their password to be-- ""Users don't change passwords," Benny replied. "That would break single sign-on. If a user changes their password in their home system, their company will submit a change request to us to modify the password on 'We Sell Bonds!'."Alexis blinked-- this time certain that this made no sense, and she was actually dumbfounded. But Benny must have taken her silence as 'question answered', and immediately started his next task. It made no sense, but she was still a junior developer, fresh out of school; full of ideas but short on experience. Maybe-- yeah, maybe there was a reason to do it this one. One that made sense once she learned to stop thinking so academically. That must be it.She dutifully entered two records for jsmith and kept working on the pile.#Friday. The end of her first real work week. Such a long, long week of data entry, interspersed by being allowed to witness a small piece of the system as Benny worked on his upgrades. At least she knew now which version of SQL Server was in use; and that Benny avoided the braces-verses-no-braces argument by just using vbscript which was "pure and brace-free"; and that stored procedures were allowed because raw SQL was too advanced to trust to human hands.Alexis stood in front of the quaint brick-faced office building. It was familiar enough now, after even just a week, that she could see the discoloured mortar, and cracked bricks near the foundation, and the smatterings of dirt and debris that came with being on a busy downtown street.She went into the office, and sat down at the desk. Another stack of papers for her to enter, just like the day before, just like every day this week. Though something was different. In the middle of the table, there was a box of donuts from the local bakery."Well, that's nice," she said as she sat down. "Happy Friday?"Everyone looked up at her at the same time."No," Mr. Chen stated, "Friday is not a celebration; please do not detract from Benny's success."She felt like she wanted to apologize, but she didn't know why. "What's the occasion, Benny?""He has completed the upgrade of the database. We celebrate his success."That seemed reasonable enough. Mr. Chen opened the box. There was an assortment of donuts. Seven donuts. Exactly seven donuts. Not a dozen. Not half a dozen. Seven. Who buys seven donuts?Mr. Chen selected one, and then the box was passed around. Alexis didn't know much about her coworkers (a fact that, upon thinking about it, was not normal)-- but she did know enough about their positions to recognize the box being passed around in order of seniority. She took the last one, a plain cake donut.Of course."Well," she said, making a silver lining out of a plain donut, "Congratulations, Benny. Cheers to you.""Thank you," he said, "I was finally able to successfully update the server for the first time last night.""Nice. When do we roll it out to the live website?"Benny looked at her a blankly. "The website is live.""Yeah, I know," Alexis said, swallowing the last bit of donut. It landed hard on the weird feeling she had in her stomach. "But, y'know-- you upgraded whatever environment you were experimenting on, right? So now that that's done, are you, like-- going to upgrade the live, production server over the weekend or something-- like, off hours?""I have upgraded the live, production server. That is our server. That is where we do all the work."Alexis became acutely aware that the weird feeling in her stomach was a perfectly normal and natural reaction to thinking about doing work directly on a live, production server that served hundreds of customers handling millions of dollars."Oh."Mr. Chen finished his donut and said, "Benny is a proper, careful worker. There is no need to waste resources on many environments when one can just do the job correctly in the first place. Again, good work, Benny, and now the day begins."Everyone turned to their laptops, and so did Alexis, reflectively. She started in on the first stack of papers to enter into the database-- the live, production database she was interfacing directly with-- when she heard a sound she'd never heard before.A phone rang.The man beside Mr. Chen-- Trevor, she thought his name was, stood up and excused himself to the lobby to answer the phone. He returned after a few moments, and put a piece of paper on top of her pile."That request should be queued at the bottom of her pile," Mr. Chen said as soon as Trevor's hand was off the paper."I believe this may be a case of priority," Trevor replied. He had a nice voice. Why hadn't she heard her co-worker's voice after a week of working here? "A user cannot log in."She glanced down at the paper. There was a username and password jotted down. When she looked back up at Mr. Chen, he waved her to proceed. Alexis pulled up "We Sell Bonds!" home page, and tried to log in as "a.sanders"The logged-in page popped up. "Huh, seems to be working now.""No," Trevor said, "You should be logged in as Andrew Sanders from Initech Bonds and Holdings, not Andrew Sanders from Fiduciary Interests.""But I am logged in as a.sanders from Initiech, see?" she brought up the account details to show Trevor."No, I tried it myself. I will show you." Trevor took her laptop, repeated the login steps. "There.""Huh." Alexis stared at the account information for Andrew Sanders from Fiduciary Interests. "Maybe one of us is typing in the wrong password?"Alexis tried again, and Trevor tried-- and this time got the results reversed. They tried a new browser session, and both got Initech. Then try tried different browsers and Trevor got Initech twice in a row. They copy and pasted usernames and passwords to and from Notepad. No matter what they tried, they couldn't consistently reproduce which Andrew Sanders they got.As Alexis tried over and over to come up with something or anything to explain it, Benny was frantically running through code, adding Response.Write("<!-- some debugging message -->") anywhere he could think might help.By this point the whole company was watching them. While that shouldn't be noteworthy since the entire company was in the same room, being paid attention to by this particular group of coworkers was extremely noticeable.And of all the looks that fell on her, the most disconcerting was Mr. Chen's gaze."Determine the cause of this disruption to our website," he said flatly."I don't get it," Alexis said, "This doesn't make any sense. We should be able to determine what's causing this bug, but-- um-- hang on."Determine-- the word tugged at her, begging to be noticed. Or begging her to notice something. Something she'd seen on Benny's screen. A SQL query. It reminded her of a term from one of her Database Management exams. Deterministic. Yes, of course!"Benny, go back to that query you had on screen!" she exclaimed! "Yes, that one!"As she pointed at Benny's screen, Mr. Chen was already on his feet, heading over. A perfect chance for her to finally prove her worth as a developer."That query, right there, for getting the user record. It's using a view and-- may I?" she took over Benny's laptop, focused on the SQL Management Studio, but excitedly talking aloud as she went."Programmability... views... VIEW_ALL_USERS... aha! Check it out."

Technology improves over time. Storage capacity increases. Spinning platters are replaced with memory chips. CPUs and memory get faster. Moore's Law. Compilers and languages get better. More language features become available. But do these changes actually improve things? Fifty years ago, meteorologists used the best mainframes of the time, and got the weather wrong more than they got it right. Today, they have a global network of satellites and supercomputers, yet they're wrong more than they're right (we just had a snowstorm in NJ that was forecast as 2-4", but got 16" before drifting).As with most other languages, FORTRAN also added structure, better flow control and so forth. The problem with languages undergoing such a massive improvement is that occasionally, coding styles live for a very long time.Imagine a programmer who learned to code using FORTRAN IV (variable names up to 6 characters, integers implicitly start with "I" through "N" and reals start with any other letter - unless explicitly declared, flow control via GOTO, etc) writing a program in 2000 (using a then-current compiler but with FORTRAN IV style). Now imagine some PhD candidate coming along in 2017 to maintain and enhance this FORTRAN IV-style code with the latest FORTRAN compiler.A.B.was working at a university with just such a scientific software project as part of earning a PhD. These are just a couple of the things that caused a few head-desk moments.Include statements. The first variant only allows code to be included. The second allows preprocessor directives (like #define).

I once inherited an application which had a bug in it. Okay, I’ve inherited a lot of applications like that. In this case, though, I didn’t know that there was a bug, until months later, when I sat next to a user and was shocked to discover that they had evolved a complex work-around to bypass the bug which took about twice as long, but actually worked.“Why didn’t you open a ticket? This shouldn’t be like this.”“Enh… it’s fine. And I hate dealing with tickets.”In their defense, our ticketing system at that office was a godawful nightmare, and nobody liked dealing with it.The fact is, awful ticket tracking aside, 99% of users don’t report problems in software. Adding logging can only help so much- eventually you have a giant haystack filled with needles you don’t even know are there. You have no way to see what your users are experiencing out in the wild.But what if you could? What if you could build, test and deploy software with a real-time feedback loop on any problems the users were experiencing?Our new sponsor, Raygun, gives you a window into the real user-experience for your software. With a few minutes of setup, all the errors, crashes, and performance issues will be identified for you, all in one tool.You're probably using software and services today that relies on Raygun to identify when users have a poor experiences: Domino's Pizza, Coca-Cola, Microsoft and Unity all use it, along with many others.Now’s the time to sign up. In a few minutes, you can have a build of your app with Raygun integration, and you’ll be surprised at how many issues it can identify. There’s nothing to lose with a 14-day free trial, and there are pricing options available that fit any team size. [Advertisement] Otter allows you to easily create and configure 1,000's of servers, all while maintaining ease-of-use, and granular visibility down to a single server. Find out more and download today!

Oh, PHP. It's the butt of any number of jokes in the programming community. Those who do PHP often lie and pretend they don't, just to avoid the social stigma. Today's submitter not only works in PHP, but they also freelance: the bottom of the bottom of the development hierarchy.Last year, Ilya was working on a Joomla upgrade as well as adjusting several components on a big, obscure website. As he was poking around in the custom code, he found today's submission. You see, the website is in Italian. At the top of the page, it shows not only the date, but also the saint of the day. This is a Catholic thing: every day of the year has a patron saint, and in certain cultures, you might even be named for the saint whose day you were born on. A full list can be found on this Italian Wikipedia page.Every day, the website was supposed to display text like "18 luglio: santi Sinforosa e sette compagni" (July 18: Sinforosa and the Seven Companions). But the code that generated this string had broken. It wasn't Ilya's task to fix it, but he chose to do so anyway, because why not?His first suspect for where this text came from was this mess of Javascript embedded in the head: