Forums
We've all seen folks reinvent the wheel. Some folks reinvent booleans. Others don't know when to stop. Some treat time as though it were malleable. Still others have all sorts of trouble finding dates.
However, Nathan encountered some code where folks seemed even more determined than usual not to use the built-in features of the language.
"Maybe this isn't actually placeholder text after all," writes Philip, "but rather, SingleHop's hosting deal is only intended for ancient Romans and scholarly individuals who learned how to speak their language."
The field of dentistry is more than x-rays and implements of torture. Half the job of any office is simply dragging patients in for cleanings and check-ups. That’s where technology comes into play.
Henrik’s employer made patient management software for dentist offices. Selling IT solutions to businesses with no IT staff was challenging, but Henrik’s software had a “nag bomb” feature. It could call, text, and email patients, reminding them of upcoming visits as well as strongly encouraging them to make appointments on a regular basis. Once dentists saw the number of missed appointments drop and the number of scheduled appointments rise, they fell in love with the software. Coupled with a centralized web gateway which allowed patients to “self-service” their appointments, you had a winning product.
I think I need a root canal. I definitely need a long, slow root canal.
One morning, Henrik arrived to the office a bit early, and was finishing a cigarette when Otto, the service desk manager, ran from the building like his head was on fire. “We’ve been hacked! We’ve been hacked! God help us, we’ve been hacked!”
Josh's team has an offshore group that "helps" with development tasks. Since they often provide code that doesn't do what it's supposed to do, they've started mandating unit test coverage. So, for the first round, they did do exactly what Josh's team asked - the offshore group provided 75% unit test coverage across all classes...and 0 assertions.
So, Josh's team explained what assertions were, and how they worked, and why they're important, and specifically that there needed to be more of them.
One of J.W.'s clients called him in to help diagnose and fix some reliability problems with the deployment system. The client was a small shop of about ten developers, one dual-role QA/manager, one SA who controlled the QA and production machines, and the requisite bean counters.
Upon arrival, J.W. was proudly shown the home-grown system that the manager had cobbled together. The developers would fill out a wiki page template for each release. The template had a section for:
Ever since Nathan had been partnered with the Siberian application development team, he couldn't help wondering if they'd been sent there as punishment. He supposed the long winters got boring, and coming up with "clever" solutions was the only thing keeping the developers sane, so Nathan was used to cutting the far-flung team some slack. Usually.
One day a simple task crossed Nathan's desk: there were two systems on two servers, let's call them Aardvark and Barracuda, that had similar databases. Nathan was asked to compare the subscriber lists stored in each. Since the servers were isolated from each other, he couldn't join across them. Instead, he planned to pull a simple plaintext dump of each and diff them. On Aardvark, this was easy:
"If time flies when you're having fun, especially when you're on the Internet, then this was the best cruise ever!" Mark F. wrote.
Mike knew he had a problem. His shareware planetarium software, Kepler, was flying off the shelves at software stores across the US. It was in such demand that he had to buy a second Amiga just to write more installation floppies. However, Kepler came with a glaring hole in functionality: no one could take screenshots.
"I just wish AmigaOS shipped with a screenshot API," Mike complained to his business partner, Seamus. "Every developer I know wants to grab screenshots. Every user I talk to says the same thing. How many teachers have written us, saying how they want to copy a star chart onto some floppies for their students?"
Dave was recently asked to write up documentation for a newly inherited system in preparation for a big rewrite. As is standard industry practice, the original developer no longer works for the company, leaving Dave high and dry if he runs into any problems.
What Dave found was an incredibly over-engineered codebase with patterns applied for their own sake and copious amounts of comments that failed to convey anything important about "why" the code did anything.
Leigh didn’t have anything to do with automating operations at their NOC, although he was mostly glad it had been done. The system was a bit of a mess, with home-grown programs and scripts sitting atop purchased monitoring packages and a CMDB. It was cumbersome, sometimes spit out incomprehensible and nonsense errors, but it mostly worked, and it saved them a huge amount of time.
It was also critical to their operations. Without these tools, without the scripts and the custom database back end, without the intermediary applications and the nice little stop-light dashboard that the managers could see if they hit refresh five times, nothing could get done. Unfortunately, this utopia covered up a dark underbelly.
We’re going to need a meeting
The operations team were the end users of the software, but they mostly relied on the development team to build it and maintain it. The development team relied on the database team. Once, Leigh needed them to expand the size of a single text field in the database from 25 characters to 50 characters. The development team had no problem updating their applications, but the database team wasn’t ready to start changing column sizes right away. Burt, the head of the database team had to start with a 1-hour meeting with his entire team to discuss the implications. Then he had to have another meeting with the development and operations managers. Then Leigh needed to sit down with the DBAs and justify the extra 25 characters (“That’s a 100% increase in the size of the field!” Burt proclaimed). After 200 man hours, the field was changed.
When teams of enterprise software developers are cloistered away from the real world for long enough, an attitude of monasticism prevails. The fragile and fleeting concerns of mortal time fall away, and the developer's mind awakens to the greater, eternal truths that wait unsullied in everlasting Empyrean majesty. Into such a team Cory came, and, under the rigorous guidance of Brother Architect, he learned that only adherence to the Database Schema Commandments could free his soul to bask in the light of the divine.
And, lo, the First Commandment was: Thou shalt name each table having a foreign-key relationship with another table such that the name of the table having the primary key is included in the related table's name.
Ever since the first Free Sticker Week ended back in February '07, I've been sending out WTF Stickers (and, now mini-buttons) to anyone that mailed me a SASE or a small souvenir. More recently, I've been sending out the coveted TDWTF Mugs for truly awesome souvenirs. Nothing specific; per the instructions page, "anything will do." Well, here goes anything, yet again! (previous: On-ramp to the Information Superhighway).
"I sent you a box of MRE's a while back" wrote Mathew Burden (Apsley, Ontario), "they were not the best tasting and, as much as I enjoyed the video of you eating them and being disgusted, I thought I should send you some of the more enjoyable selecitons. I have also included a variety of computer related junk to round out the box of souvenirs."
In the early part of this century, it was quite common for small companies to stray into the infrastructure business and run their own servers. The company where Tatiana's dad worked was no exception. The infrastructure in this case was mainly a couple of old Linux boxes, one acting as the Web server and the other as the email server. To be fair, the email server was 'newer', in that an older one had recently been replaced. Imagine for a moment what the specs for an 'old' server in 2000 that was too slow to support an email server must have looked like. I imagine a 186 chip and 8K of RAM with a cassette tape for persistence, but that could just be me.
At the time, Tatiana was a university student with a working knowledge of Unix. Where, in this case, 'working' is defined as the level of UNIX learned while completing university-level computer courses. Still, when the system administrator at her dad's company left and her dad asked if she would be willing to help out if an emergency arose, Tatiana agreed.
Jan W. works in the Operations group for one of the biggest Internet access and hosting providers in Germany. As such, when you have to support as many customers as they do, there's a LOT of complex moving parts that go into keeping the environments up and running smoothly. So, to help distribute the workload, and to keep everyone sane, Operations' development needs are handled by a separate group.
Any new changes that are sent over arrive bundled up in a convenient Debian package so that QA can quickly bless everything before it's installed on any production machine.
Aikh was the new hire on the local bank’s data warehousing/business intelligence team. His manager threw him right into the hurricane: a project with the neediest, whiniest and most demanding business unit. Said business hated their unreliable batch process for archiving reports, and the manual slog of connect > find/create directory > upload > pray. They hoped the DW team would code to the rescue.
Eager to impress, Aikh sketched out a simple, automated client/server solution. The business quickly approved his design and estimates. To mentor and keep the project on-track, Aikh’s manager assigned Dean, a more senior developer, to help out.
What do you mean, “steam powered hammer?”
“I could really use a good library to transfer files via secure shell,” Aikh told Dean during their initial meeting.
When Peter was training one of ShellTech's new developers, he didn't think much of a question the greenhorn asked him.
"What happens if there's an error in a catch block?"
"It tried to open a popup," Ara wrote, "I wonder if it was going to say 'get Message Error(Buyer)!'?"
Being the consummate IT professional, John took pride in his ability to automate the more regular and mundane aspects of his job. While not everything bent to his scripting will, with the appropriate cmdlets, plug-ins and modules, there were few areas that were beyond his (automated) reach.
But even then, there were still some regularly executed processes that had not yet been touched. Following the crucial "if it's not broke, don't fix it" mantra, John was willing to let these pieces of antiquity continue to have their day until necessity demanded a change. The key being, naturally, if it's "not broke".
Guillaume's employer, BastilleCo, believed in an egalitarian workplace. Managers and executives sat at the same desks as other employees, and they often took lunch together. This made BastilleCo an excellent workplace, even in a progressive nation like France.
However, BastilleCo's defect was to treat its data like it treats its employees. There existed the typical messiness of bad legacy code -- single-letter variables, globally-scoped functions, and so on. But not only was there no executive/employee segregation, but there was no data segregation either. In fact, there was a single table, where everything in BastilleCo's flagship application was stored:
TLDR; We made a game! It's called Release!, and it's currently on Kickstarter.
##
“I didn’t buy ten cylinders of CO2! Why is PCard telling me I did?”
There were a pile of tickets in Adam’s queue, slightly larger than the proverbial molehill, but nowhere near mountain status either. Several employees saw incorrect charges on their purchasing cards, including one of the VPs. The first suspicion was fraud, but these charges looked legitimate: plane tickets to cities where the company had plants, raw materials purchases from vendors the plants usually did business with, etc. Since a VP was impacted, this confusion needed to be resolved ASAP, which meant Adam was pulling long hours to fix it.
“PCard” was the name for the purchasing card application. The purpose of the tool was to allow managers and executives validate the purchases made on the purchasing cards, and determine if they really belonged there or should have had a purhase order. It was one of Adam’s nuisance products, simply because it mostly worked fine- but minor issues were viewed as “my hair’s on fire” class emergencies. The only silver lining was that the application was considered “mature”, which meant that in three months, support would move to a much cheaper offshore team.
May 14
Stuart: Oooh Sheldon, I'm afraid you couldn't be more wrong.
Sheldon: More wrong? Wrong is an absolute state and not subject to gradation.
Stuart: Of course it is. It's a little wrong to say a tomato is a vegetable;
it's very wrong to say it's a suspension bridge.
-- BBT
Kristian works in a shop with a bunch of superstar developers who always seem to find interesting ways to solve what most folks might otherwise consider to be trivial design issues. One particularly brightly shining piece of engineering involved a home-grown enum table in their database. Apparently, true, false and perhaps even FILE_NOT_FOUND weren't enough for these developers. No, they needed something that could handle gradations of right and wrong; true and false. They needed something that could handle situations where something was really true or really false. Something that was a bit more than boolean...