The Daily WTF: Curious Perversions in Information Technology

The Biggest Boon-Dongle in the World

by snoofle in Feature Articles on 2013-01-31

Telecommunications manufacturing is a cut-throat business. Features, functionality and hardware need to be added and continuously improved at a frenetic pace in order to stay one step ahead of the competition. Engineers must constantly increase their skills to leverage the latest advances in technology to design and build the best product possible at the lowest cost. Slip up just a little, and it can be a death knell for your company.

To save costs, Dog and Bone Corporation (DNB) had eased up on their latest-and-greatest push. Budgets shrank. Progress on adding new features slowed. Hardware upgrades failed to happen. Meetings to justify every little thing began to become the main task in everyone's day. Competitors leapfrogged. Interest waned. Unfortunately, this caused their flagship private telephone exchange (DBX) product to start to stagnate and made some of the engineers begin to feel that their skills were getting to be a little out of date. Engineering-eyes began to wander.

77 comments - Last comment @ 2013-12-27

Too Much Sleep

by snoofle in Best of the Sidebar on 2013-01-22

I've frequently posted about my attempts to speed up our system being thwarted by sleepy management decisions about application performance. Our application is essentially: query data, crunch data and save results. Each of those tasks took approximately 1/3 of the run time. A large part of my job is to make the application run more quickly. Every time I fixed something, something else would break, not because I coded something incorrectly, but because of the fragility of our application, other associated applications and the database. For instance...

Sleep for the database

We run four instances of our application. We also perform about 30 load-data queries. Most of them query tables with 3+ billion rows. If all four instances of the app do queries at the same time and each query is run in its own thread, that's 120 parallel queries just from our application server instances. The database simply could not keep up. The original developer created five threads for thirty parallel queries. Then, to add insult to injury, he added sleeps after each query (in each thread) to give the database a chance to catch up. Part of the problem turned out to be that the DBAs only allocated 512M of temp space for all users. They refused to fix it.

Sleep to cool the cpu's

72 comments - Last comment @ 2013-01-29

A Forest of Trees

by snoofle in CodeSOD on 2013-01-15

Our system was written by neophyte troglodytes who didn't follow standards of any kind. They coded whatever they wanted, however they wanted, whenever they wanted, wherever they wanted. Usually via copy/paste/plagiarize.

In particular, we have a class called Tree. More accurately, there are 18 (yes, that's e-i-g-h-t-e-e-n) Tree classes; one each for: char, byte, short, int, long, float, double, Character, Byte, Short, Integer, Long, Float, Double, String, BigInteger, BigDecimal and Object[]. One might think: Hey! Let's use generics: Tree<T>. Nope! Each one is needlessly just a little bit different. Some implement the same methods with different types. Some have methods with completely different implementations to do the same thing. Some use completely different names for the same methods. Sometimes, the methods are identically named, and the parameters are the kind that can be auto-up-cast (e.g.: short -> int):

64 comments - Last comment @ 2013-01-17

Color Me Stupid

by snoofle in Feature Articles on 2013-01-08

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.

106 comments - Last comment @ 2016-04-21