Best of 2016: Tern Around…by in Best of… on 2016-12-30
As the World Ternaries
For example, you might use the ternary operator to validate the inputs of a function or handle a flag.
For example, you might use the ternary operator to validate the inputs of a function or handle a flag.
What, 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.
An 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.
Jake eagerly stepped into his new job, grateful for more experience and new challenges, craving to learn new software stacks and see what his new company had to teach him about the world of software.
Mike had a different perspective on wiring and cable management- because he worked at a factory which made wires and cables. It was the early–90s, and he was in charge of babysitting a couple of VAXes and their massive, 85lb hard drives. It was an easy job: the users knew the system and needed very little support, the VAXes were practically unstoppable, and the backup battery system could keep the entire thing running for over an hour.
The computers supported HR and accounting, which meant as the year ticked towards its end, Mike had to prep the system for its heaviest period of use- the year end closing processes. Through the last weeks of December, his users would be rushing to get their reports done and filed so they could take off early and enjoy the holidays.
’Twas the night before go-live, and all throughout git,
Not a coder was coding, no single commit;
The release was planned by DevOps with care,
In hopes that userbase would soon be there.
The PMs were nestled all snug with their charts,
While dreams of big bonuses danced in their hearts;
My team in the team room, and I with donuts,
Cracked wise about our PM being a putz;
On occasion, we've all faced a situation where we need to check to see if some internal application process has succeeded, or gotten stuck. There are many ways to accomplish this; some better than others. In the old days, folks used loops to count CPU cycles. Of course, as CPUs got faster, this didn't scale all that well. Now you can use myriad combinations of event handlers, semaphores, thread safe flags and threads. Or you can just use the time tested method of hard coding a sleep.
Of course, this requires that you have a decent idea of how long something will take to complete. It also assumes that you know something about the delays that can reasonably be expected in the execution environment.
A little more than five years ago, we published a plug-in that allowed you to submit code directly from Visual Studio to The Daily WTF. However, in the years since, that style of extension was deprecated in Visual Studio, and the SubmitToWTF API was lost in the latest site redesign.
The loss was felt by many users. Without the plug-in, submitting bad code requires first printing it out, putting it on a wooden table, taking a picture of it... then printing out the picture, scanning it, then uploading as a PDF to the Submit Your WTF form.
The 90s were a weird decade, and not just because of a strange obsession with flannel. Computers were just becoming a mass-market phenomenon, and nobody really quite grasped what that was going to mean. When I entered college in the late 90s, the campus was still littered with dumb terminals wired up to the VAX. Just a few years before, they’d installed the latest thing in networking- 100Base-TX Ethernet- to all of the dorm rooms and most of the classrooms. They loved their brand new network, and didn’t want punk kids messing it up, so you couldn’t just connect your computer to the network (you probably didn’t have a network card anyway). Instead, they had an outside vendor set up an office in a storage room on campus. You had to lug your tower over there, they’d take your computer for a week or two, and then give it back to you with a new NIC, a bunch of crapware, and a note which said your computer was cleared to use the network. You could then take that note over to the IT offices, and they’d put in a work order to activate the network port in your dorm room, and give you an Ethernet cable. Oh, and this entire process cost $200.
Eventually, they wised up, kicked the outside vendor off campus, and CS majors like myself got to make a couple of bucks installing NICs into freshmen’s computers. I think many of us might have had that sort of experience. Sabrina did a similar turn in her teens, helping a small ISP get people connected via modem or ADSL, but encountered a few… special edge cases.
Hannes has inherited a legacy project. Like most legacy projects, it has no real documentation, the code is a disorganized mess, and making any change runs a non-zero risk of completely knocking over the house of cards.
What few comments the code has tells us things like this:
The number of customers that might purchase your software has a detectable impact on how you develop that software. If you’re making a smartphone time-killing game, for example, there are potentially hundreds of millions of customers for that game. This drives software in two directions- you have your mounds of shovelware crap that just hope to make a few bucks fleecing suckers, and then you have the tight competition that optimizes the design of the software.
Contrast that to “enterprise” software. If you’re making an ERP, how many potential customers do you have? Thousands? Tens of thousands? And each one of them is going to want something different from your product, so you’ll need to either pile on features or build an Internal Platform that lets them customize it. It doesn’t matter how much money is in this market, or even how many users there are going to be- it’s all about the number of customers that might pay for your product. This, I suspect, is a large part of why enterprise software is terrible, and I think it lays out a corrolary to Remy’s Law of Enterprise Software: the narrower the audience, the worse the software is going to be.
Ada worked in QA in the Netherlands, testing a desktop application for a German bank. The app was simple: a C/C++ app that scanned in paper forms, read them with OCR, and processed their contents. It was constructed, as was the fashion at the time, from a number of separate DLLs, each serving one and only one purpose. It was usually fairly boring work, but it was paying for her education, so it was worth putting up with.
Anyone who’s ever needed to write cross-platform code in C or C++ knows that TRWTF is endianness. Your options are either to use a lot of platform specific preprocessor macros, or to coerce all of your data into your own specific format, for portability.
Adam H’s company took the latter approach, implementing a
ByteWriter class. It was relatively easy to use, with code that looked something like this:
Felix caught a ticket about their OpenId authentication. For some mysterious reason, it had started failing around 30% of the time, specifically because the access token returned by the service was invalid.
Felix had originally written the code, but there was one problem: he wasn’t the last one to touch it. Another development team needed their own versions of the code, organized a bit differently, for infrastructure reasons. Eventually, the whole thing was turned into a drop-in library component that was used by all applications which depended on OpenId. The failures started after they made their changes, so obviously their changes caused the failures.
Lex was an employee at GreyBox in the late 90s, a PC-repair shop inside of a large electronics chain. He had spent the entire morning handling phone calls from customer after customer. Each of the calls was supposed to go to his co-worker Gerald, but Gerald hadn’t been picking up his phone. Each caller complained that Gerald had taken in their computer for repairs and not actually done the repairs.
“I brought my laptop in yesterday,” one caller, a wheezy old man, said, “and the young man behind the counter just took the laptop and said, ‘come back in an hour’. He went into the back room, and when I came back, he looked like he had been drinking. You know, red faced and sweaty. And the laptop smelled funny- like corn chips. And it wasn’t fixed!”
Drew W got called in to track down a bug. Specifically, their application needed to take a customer’s location, and measure the distance to the nearest National Weather Service radar station. It knew the latitude and longitude of each, and needed to find the distance between those points, and it was wrong. It could be off by hundreds or even thousands of miles, especially in more remote locations.
This was the code in question:
George had just escaped from his job, a WTF-laden hellhole where asking for a test database to reproduce an issue resulted in the boss spending hours and hours hand-typing and debugging a fresh SQL script based on an old half-remembered schema.
Initech promised to be a fantastic improvement. “We do things right around here,” his new boss, Harvey, told him after hiring him. “We do clean coding. Our development systems and libraries are fabulous! And each of our programmers get a private office with its own window!” Yay, no more cubicle!
"I get it that some apps need special permissions, but a GUID is the digital equivalent of 'just trust me - I know what I'm doing'," Kenneth M. writes.
Gus had been working at his new job for a month. Most of his tickets had been for front-end work, making it easier and more efficient to manage the various vendors that the company did business with. These were important flags like "company does not accept UPS deliveries" or "company does not accept paper POs". The flags had been previously set via an aging web-based UI that only worked in Internet Explorer 6, but now they were migrating one at a time into the shiny new HTML5 app. It was tiring work, but rewarding.