Feature Articles

To the outside observer, Christopher M's work environment might appear to be a potential breeding ground for WTFs. They supported an "enterprise-level" product and, when a developer noticed a bug, the development manager expected him to just go in and fix it. No change controls, no QA oversight — those were far too time consuming and added little value. Almost anywhere else, this set up would result in chaos, but Chris and his four fellow coders were experts, and they were able to navigate the lack of process.

ee... ee... ee... ee... ee... .........  "Good morning, Janet!" ee... ee... ee... ee... ee...

Bruno was working on a PHP-based hotel reservation system and, thanks to the odd bug here and there, seldom had the time to look into the "feature requests" queue. But the good news was that the system was getting more and more stable with each release, and the really good news was that Bruno would be getting some help from a newly hired developer named Greg. Bruno even picked out the perfect first task for the new guy.

Not too long ago, the CTO at Dudley H.'s company had a startling revelation: there should never, ever be a need for technical support. If a client has an issue using one of their products, then the problem is most certainly in the product. Maybe the UI is a little confusing. Maybe it's not documented enough. Maybe the documentation isn't clear enough. Whatever the case, every client issue means that someone — be it the developer, tester, or helpdesk technician — didn't do their job properly and should strive to improve themselves.

Jerry wasn't the sort of guy who would normally vent frustration out loud at work, yet here he was - cursing into the air at two individuals in particular - the first round of explitives being directed at the toolbag, somewhere, who had botched months of server backups by reusing the same set of tapes for months and the other being a long ago departed developer whose name he was continually being subjected to in the comments of the rotten shell script he was now stepping through.

Today's What The Ad? is courtesy of John D.. The general theme: business ads that wouldn't appeal to a typical business, even then.

In 1968, when David Foskey finally had the opportunity to stand face-to-face with a Honeywell 8200, his expression was nothing short of awestruck. Technically, the 8200 didn’t have a face, it had a window that overlooked a room. And not just any room, but a room the size of a freakin' basketball court. In fact, Honeywell recommended that no less than six thousand square feet be dedicated to the 8200; any less and the sorters, collators, processors, storage devices, and computer operators would be a bit too cramped.

Please show your support for The Daily WTF by checking out the companies that have been kind enough to sponsor us. And, in doing so, I’m sure you’ll find some pretty cool products and services built by like-minded developers and IT professionals.

Back in 2006, Steve worked as a developer at mid-sized financial services firm. Like many organizations with central IT operations, departments within Steve’s company had the option to “buy” application development services from IT, or use an outside vendor for their business software needs, provided that the vendor’s software met IT’s security and technical requirements.

Twenty five years ago, when Steve W. worked for a military subcontractor, he'd often roll his eyes when meetings were denoted "CONFIDENTIAL". It's not that he didn't take confidentiality seriously, it's just that everything they did was confidential. By labeling most everything "CONFIDENTIAL", there was no way of knowing when some things – like performance reviews and should-we-fire-so-and-so discussions – were really, really confidential. At least, not until you were actually in the meeting.

As a postgrad in the late '80s, Neil Bowers made some extra book money by acting as a helper in the computing lab. At the time, undergrads were all working on a grindingly slow VAX-11/780, and Neil and his fellow postgrads were posted there for hands-on help. This tended to be focused at the start of the year, when there were groups discovering Unix and programming for the first time.