The Daily WTF: Curious Perversions in Information Technology

Classic WTF: Color Me Stupid

by snoofle in Feature Articles on 2022-05-30

It's a holiday in the US today, so we're flipping back through the archives to remember a classic WTF. These colors don't run, because they'll trip over their own shoelaces. Original. --Remy

Andy's company develops solutions for "Industrial" handheld devices. To make deployment and updates easier, they each run a thin client so only the server is different from project to project. This client was written by a long-gone employee in the early nineties, and had barely changed since because it "just worked". Updating it was discouraged for fear of breaking backward-compatibility.

Andy's new project was the first chance he'd had to use it, so he asked a colleague if there was some code that could be used to interface with it. What Andy received was essentially a giant method which responded to the client by cycling through a switch-statement to decide what to paint next based on the current state of the client. Andy took the initiative to create a library for making servers for these things a bit less spaghetti-like, and to encourage this new-fangled concept of code-reuse.

15 comments - Last comment @ 2022-06-11

Best of 2019: Temporal Obfuscation

by snoofle in Best of… on 2019-12-26

It's the holiday season, and we use this opportunity to take a week and reflect on the best stories of the year. Here, we reach back to January for a tale of variable names and convention. --Remy

We've all been inflicted with completely overdesigned overly generalized systems created by ~~architects~~ managers who didn't know how to scope things, or when to stop.

We've all encountered premature optimization, and the subtle horrors that can spawn therefrom.

14 comments - Last comment @ 2020-02-16

The Master is Simplicity

by snoofle in Editor's Soapbox on 2019-05-08

When I was in college, as part of the general course requirements we had to take Probability and Statistics. The first time around I found it to be an impenetrable concept beyond my grasp, and I flunked. Since it was a requirement, I took it again and barely skated by. Joy; I had cleared the hurdle!

By that time, it had become clear to me that I was going into a field that required a whole lot more understanding of P&S than I had acquired. Since I wanted to be properly prepared, I signed up for a free summer school course to try it once more.

50 comments - Last comment @ 2019-05-13

Beyond Brillant

by snoofle in Feature Articles on 2019-02-26

We've all had cow-orker's who couldn't do their jobs. Some people have even had the privilege of working with Paula.

Jarad should be so lucky.

47 comments - Last comment @ 2019-04-08

Temporal Obfuscation

by snoofle in Feature Articles on 2019-01-30

We've all been inflicted with completely overdesigned overly generalized systems created by ~~architects~~ managers who didn't know how to scope things, or when to stop.

We've all encountered premature optimization, and the subtle horrors that can spawn therefrom.

53 comments - Last comment @ 2019-02-08

2018: The Wizard Algorithm

by snoofle in Best of… on 2018-12-31

NIH syndrome causes untold suffering in the world, but for just a few pennies a day, you can help. Or maybe not, but not-invented-here meets password requirements in this story from June. --Remy

Password requirements can be complicated. Some minimum and maximum number of characters, alpha and numeric characters, special characters, upper and lower case, change frequency, uniqueness over the last n passwords and different rules for different systems. It's enough to make you revert to a PostIt in your desk drawer to keep track of it all. Some companies have brillant employees who feel that they can do better, and so they create a way to figure out the password for any given computer - so you need to neither remember nor even know it.

Kendall Mfg. Co. (estab. 1827) (3092720143)

History does not show who created the wizard algorithm, or when, or what they were smoking at the time.

13 comments - Last comment @ 2019-01-03

Assumptions are the Mother of all Bugs

by snoofle in Feature Articles on 2018-12-19

A long time ago in my "C" programming days, I learned that when you code up anything that depends on any sort of external data, be it a file, database or socket, you should be paranoid and do it defensively. After all, you can't control those things and there's no guarantee that they will always work the way you hope. Sometimes you care about every possible error code; sometimes just success or failure. The point is to check the result of what you tried to do.

Fast forward through several years of C++ and ten years into Java, and our boss calls us into the office.

The Command Controller application is failing and nobody knows why. It runs fine for a while and then it starts throwing what appear to be random exceptions. The problem is happening on almost every single command that it's receiving, but only in production. We can not reproduce the issue in any of the other environments (DR, pre-prod, QA or Dev). The team that wrote it is dumbfounded and has asked for help. We have a pretty good reputation at solving tough issues, so you guys need to drop everything and figure this out.

40 comments - Last comment @ 2021-01-22

Politics Rules! Common Sense Drools!

by snoofle in Feature Articles on 2018-12-13

As programmers, we all need to fix bugs. As experienced programmers, we recognize that sometimes, the ability to fix one bug depends upon first fixing another bug. Managers, on the other hand, don't always get that simple concept.

At the beginning of my career, I worked for Initrode where I wrote software to run a test-station that diagnosed assorted electronic components of jet fighters. Initrode acted as a government-supplier of the test station to another government contractor (LUserCorp) that used the station to write the test sequences to diagnose electrical faults. If the test station hardware malfunctioned, or there were bugs in the software that made the electronics tests fail to work properly, then LUserCorp could use that as an excuse for time and cost overruns. If that happened, then the government would penalize Initrode to recoup those costs.

34 comments - Last comment @ 2019-01-10