Recent Feature Articles

Aug 2007

The Cost of High Security

by in Feature Articles on

A few years back, I was “between jobs” (voluntarily, for the record!) and thought I’d try one of those generic “.NET developer needed for three-month contract” jobs. As I learned at the interview, the client was a Certain Federal Agency, and this Certain Federal Agency required that all contractors have clearance at the “Confidential” level. But not to worry: although my then-clearance level was at the “Hoi Polloi” level, the Certain Federal Agency was happy to bring people on board now (as they needed people “right away”) and have them “wait a little bit” while the clearance request went through. Sounded reasonable enough to me, so I took the job.

Three months later, having accomplished little more than mastering the Rubik’s cube and memorizing the forty-eight pages of “non-sensitive” documentation, I was asked to extend my contract another three months. My security clearance (which would allow me, among other things, to log in to the domain and finally see the core application), was “right around the corner.” I hesitantly agreed and signed up for another three months.


Really, Really Custom Software

by in Feature Articles on

"Tim was a hardware engineer for a large technology company," wrote in Brent, "and was responsible for analyzing cable signals. He purchased a tool to analyze these signals from a different company, call them Initech."

"From the start, Tim noticed curious feature about Initech's tool and its corresponding hardware. For example, the documentation described how to connect probes to the hardware, but Initech had accidently reversed the labeling such that plus connected to minus and minus connected to plus. Oops.


If Only I'd Been More Explicit

by in Feature Articles on

As software developers, we automatically know what our clients want. Even if during the requirements gathering phase the client tells you they want you to zig, you know that they actually want you to zag.

(Hopefully) obvious sarcasm aside, getting requirements and building software that the client wants is a common point of failure in our industry. I've worked with developers that were dilligent enough to read the business requirements, but ultimately disagreed with them and went ahead to built crap that no one ever wanted. David A. understands the importance of building things that users want, and was delighted when his prototype was well-received.


Mixed Messages

by in Feature Articles on

As a software & electrical engineer, a major part of Nick Johnson’s job is figuring out why some aspect of the complex controlling hardware & software that’s used by industrial-sized equipment isn’t working exactly as it should. Personally, I couldn’t imagine debugging such a beast. Sure, there are plenty of sensors and log files, but they only paint a partial picture: who’s to say the recording equipment isn’t flawed, too?

Thankfully, there are plenty of folks like Nick who actually enjoy the challenge. One of Nick’s most recent assignments was figuring out why the timing on an automated sorting device kept getting thrown off. After several days of analysis, Nick finally isolated the problem to an incorrect speed variation on a particular motor that was responsible for pushing a rod back and forth. The question that remained, of course, was “why?”


Privately Public

by in Feature Articles on

Learning programming is like learning anything else. You have to start at the basics. Much like you won't be able to ride a bike without first being able to identify what a bike is and how you make it go, you'll need to know some of the essentials before whipping up your first "hello world."

Amro had a little programming experience under his belt, but not enough knowledge to test out of an early C++ course. Still, he was in good shape compared to the rest of the class, knowing the difference between public, private, protected, classes, structs, pointers, etc.


The Josh Workaround

by in Feature Articles on

A few years back, Brian T took a position in the “Installations and Upgrades” department at a certain enterprise software company. Being that they were an enterprise software provider, installation and upgrades of their software could only be performed by highly-paid technicians. It was Brian’s job to support the technicians and provide them with scripts to help them do their job.

To get accustomed to the tools he’d be working with, Brian opened up the primary upgrade script. He was surprised to see the following at the top…


Good Thing we Tested It

by in Feature Articles on

AJ got his start at a very small, clientless, and ultimately doomed software company, and it was there that he met Jerry. By the time AJ came to the company, Jerry was off the dev team and in more of a sales role. Still, he'd been on the dev team for years and his code remained throughout the system.

Jerry fell into the common trap of writing code in one language the way he wrote code in another. You know, like when you made the switch from VBScript to VB.NET? Well, Jerry's Assembly background didn't prepare him much for C++, and it showed. AJ became intimately familiar with Jerry's confusing code after having to maintain it for years.


Securing The Server Room, Part II

by in Feature Articles on

A few months back, G.R.G. shared a story about the “Secured” Server Room at a certain university he once worked at. Like so many WTF’s, there’s a fun follow-up to this story. Brief recap: the dedicated air conditioning unit for the “ultra-secure” data center had died and none of the elite group of key holders could be reached to open the door; fortunately, G.R.G. was able to unlock it with his trusty Bic pen and let the maintenance guy in to fix the problem.

All the servers, all the research grants, G.R.G. thought while basking in his Bic-powered breaking-and-entering skills, I could take them, they’d be mine, mine, mine! As G.R.G. briefly pondered upgrading to burglary, the Maintenance Guy hastily worked to vent the sweltering air from the room. A few minute later, with the aide of a giant floor fan, the temperature dropped to a much more suitable level.


The Cool Cam

by in Feature Articles on

Brand G. got his start in the game industry working at MicroProse, famous for classics such as Civilization, the X-COM series, Masters of Orion, Pirates, and Dark Earth (one of my personal favorites). MicroProse was also known for its military simulation games, such as Gunship, Pacific Air War, M-1 Tank Platoon, and Falcon 4.0. Brand was brought on to work on such a simulation, European Air War.

European Air War was doomed. It was four years in development and not even close to being ready to ship. In Brand's first month at MicroProse, the whole programming team on European Air War quit, sensing that their project was on the verge of cancellation. Not only that, but everyone had grown tired enduring the stress of the weekly "why-shouldn't-we-cancel-this-project" meetings with the executives. In these meetings, they'd have to choose their words carefully when answering the executives' tough questions about the budget as well as major bugs in the system such as...

  • Why are the planes flying backwards sometimes?
    Well, uhh, a little known thing about Nazi technology developed in World War I...
  • Why do the wings come off the plane whenever you fire the guns?
    Uhh, err...
  • Why does the plane bounce up and out of the earth's atmosphere when you crash into the ground?
    Umm, in high-speed collisions like that it's not totally unreasonable that a plane's velocity torque rotary girder viscosity...

Please, Don't Log In!

by in Feature Articles on

I’ve always found it disheartening to see bad, custom enterprise software. In virtually every case of enterprise software failure, a company had an opportunity to build an effective system that would help employees be as productive as possible, yet ended up with a monstrous application of rapidly decaying quality that everyone – from the day-to-day users to the maintenance programmers – has come to despise. Worse still, there’s little the business can do: they’ve already invested in building the application and simply can’t justify rebuilding another one.

Fortunately, victims of such applications do have one reprieve: complaining. And as editor of this site, I read a lot of that. Not that I mind, of course: please, send in your own stories of woe! In fact, many submitters – including N.A.Z, who forwarded an email from a developer of his company’s enterprise system – find it cathartic simply to share their WTF's here or on the Side Bar.


The Other Kind of RPG

by in Feature Articles on

Several months back, I featured an arcane programming language called MUMPS. Most of you had never seen before nor, presumably, would want to ever see again. Despite having about as much utility in modern software development as a sextant in modern navigation, MUMPS (or M (or Cache)) is still wildly popular in several markets and shows no sign of going anywhere anytime soon. And to make matters worse, MUMPS isn’t one of kind. There are several other ancient languages like it that just refuse to die. Today, we’ll learn about one of these languages named RPG.

Many years back, Jacobus took a “Programmer, Language Unspecified” job at certain company with a “large team of programmers.” A language is a language, right? Not when that language is RPG. And unlike “Bryan” from the MUMPS article, Jacobus remains an RPG developer to this day.


The Pie T Department

by in Feature Articles on

Many years ago, Dan B. worked at a large accounting firm that had several small, satellite offices spread throughout the world. The offices shared data -- mostly email -- via a dial-up based file synch operation that would run several times throughout the day. Since these offices were so small, they didn't need IT support on staff; instead, they'd rely on the IT staff at the central office for help.

The file synching had been going well for months, but the process began failing when attempting to synch with one of the Australian offices. Dan tried to diagnose the problem on his end, but determined that it had to be a problem with the remote server in Australia. It was going completely offline every few days and had to be manually restarted. Unable to convince his boss that a trip to the outback was needed, he had no choice but to work with the office's secretary, Sydney, to fix the problem.


The Big Purple Boxes

by in Feature Articles on

These days, networking is easy. Lay down some CAT-5, wire in a few switches, install a router, configure a the clients, and that’s that. Everything plugs in and just works. But back in the day, things worked a bit differently. Namely, there were choices. Lots and lots of choices.

You had to pick your cable (10BASE-T? Type-1? DIN?), your topology (Token Ring? Ethernet?), your protocol (AppleTalk? TCP/IP? IPX/SPX?), and just about everything else. If you were lucky, everything else on the network worked the same way. But usually though, you’d have to figure out how to make the incompatible networks and computers talk to each other. That’s what G.R.G. used to do many years back.


Zac the Logo Maniac

by in Feature Articles on

Today’s story is from longtime WTF contributor, G.R.G....

Long ago, I needed a little spare cash, so I decided to look for an extra consulting gig. A friend of a friend pointed me towards the University’s job board. Apparently, there was a consultant programmer job posted.


Cold. Hard. Credit Report.

by in Feature Articles on

If you really think about it, the fact that anything on a computer works is amazing. At a low level, magnets read and write ones and zeros on ridiculously fast rotating platters, and then are assembled into files, which then is stored in memory, which is then passed through a video card and converted into some format that can be displayed on a screen. Throw in networked computers and the potential for signal loss over long distances and the probability that something at some point in the process will fail, and the potential for failure increases exponentially. Maybe I'm alone, but I'm in awe of the fact that my computer doesn't just randomly catch fire and explode.

Of course, we can find and predict many errors, and even alert users that their software or hardware has failed (as long as either the monitor or a speaker is still working). Without any indication of where an error is happening, though, it gets harder to diagnose. Russ recently got to witness a complex issue being diagnosed and resolved firsthand.