The Daily WTF: Curious Perversions in Information Technology

Hangin' On

by snoofle in CodeSOD on 2013-03-27

Don T. was tasked with adding the ability to process transactions with new reference data to their flagship product. After some thought, Don decided that he would create a DAO to load the new reference data from the database, and store it in another sub-cache in the singleton master-cache of the application. Further, he would grab a handle to that sub-cache and pass it around to anything that needed it. The actual processing would be done by a remote web service. There would be approximately 100 megabytes of new reference data. He wrote and tested the code. QA tested and blessed the code. It was deployed.

Within an hour, the application died with an OutOfMemoryError.

87 comments - Last comment @ 2013-04-04

Try More Random

by snoofle in CodeSOD on 2013-03-21

All of Christian R.'s fellow employees were so overloaded with criticality-1 tasks like replacing icons, fixing spelling mistakes and such that their company decided that it would be prudent to outsource new work to Experts. Management reasoned that choosing highly trained experts would ensure that the job would be done right the first time. The solution would be cost effective, efficient and make them look wise.

One particular new task was to enable two devices to be paired. This would be accomplished by having one device display a number. The user would enter the number on the other device: the two devices would be paired and the user would be logged in on both devices. Underneath the covers, both devices talked to a common server. Once paired, the devices could talk to each other (through the server).

79 comments - Last comment @ 2013-03-29

Less is More

by snoofle in Feature Articles on 2013-03-14

Pratik K. left work on very late on Friday with plans for an awesome weekend. He had earned it. Each application that was part of the new release had been tested in the test database, both individually and as part of an end-to-end drill that included both vertical and horizontal functional and stress testing. His code was bullet proof. All the signoffs had been acquired. The DBAs were ready. The SAs were ready. He could heave a sigh of relief, let go and have some fun. And so on Saturday night, out he went. Drink he did. Late he came home. He got the call at 5AM Sunday morning. Something was horribly, horribly wrong.

The business users had kicked off what they thought would be a 15 minute job early Saturday afternoon. When they came back several hours later, all the applications were hung. The users couldn't access the database. After everything had been so thoroughly tested, how could such a catastrophic failure have happened? What had gone wrong? The customers were already expecting the release to be installed for their use by business-open on Monday morning. This absolutely had to be fixed now!

147 comments - Last comment @ 2013-03-22

Trust Me

by snoofle in CodeSOD on 2013-03-07

Pritesh C. took a position working for an Architect's Architect who could out-design anything to out-do and out-perform any other system. Everything this guy ever designed and coded had more features, capabilities and brute-force performance than any similar widget ever designed by anyone else, anywhere, ever.

Way back when the system was first being designed, the Architect's Architect decreed that communication with the system was to be via JMS messaging. Additionally, there would be two queues; one for normal and one for high priority messages. Applications requiring the services of this new application would send normal priority messages for batch processing, and high priority messages for direct user-interaction. The application would monitor both queues, but let the high priority messages jump to the head of the line for faster response. Also, due to the system it was to replace being notoriously buggy and unreliable, this system had to be bullet proof. It simply could not go down.

80 comments - Last comment @ 2016-12-03

War of the Worlds

by snoofle in Feature Articles on 2013-03-04

Laptops Rule! At Cheryl C's company, most of the work was done, and all of the data was stored on Linux servers, but everyone used laptops to access the network and by extension, their Linux servers. Most of the time this worked out well. However, when something went wrong... support was handled by two different organizations: one in her company and one on The Other Side. Specifically, the company on the other side of the merger. Two behemoths had merged into one mammoth colossus of Jurassic proportions.

For the past 18 months, all sorts of efforts had been ongoing to divide the responsibilities to eliminate the redundancies. Managers met. Managers fought. Managers decided that it was redundant to have two PC support organizations, two network support organizations and two Linux support organizations, so they decreed that Cheryl's company would support the PC world and the other company would support the Linux world and the network. And never the twain would meet.

77 comments - Last comment @ 2013-03-13