For Your Security
by in Error'd on 2007-08-31Josh D. appreciates having the convenience of online shopping with all the security of email:
Josh D. appreciates having the convenience of online shopping with all the security of email:
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.
"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.
After searching for a bug for quite some time, Kai Meierhofer came across the BEA bug tracker page, where one can specify how useful the bug was. Talk about service!
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.
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?”
G.M. learned an important lesson about Killing while installing the German edition of Windows XP. Apparently, holding shift and clicking the close button of the installation window might just cause you to lose some date...
If only C.E.'s Jury Summons letter had a VBScript error on it …
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.
Peter B. was an out-of-work PHP developer looking for contract work in early 2005. A recruiter he'd worked with in the past emailed him some information regarding a possible position. Reading the job description, Peter thought he'd be a good fit, so he submitted his resume and got a response via email a few days later.
The hiring manager described their typical process; Peter would have to answer a screening question to determine his skill level, and if his answer was satisfactory, they'd schedule a face-to-face interview. With a little trepidation, Peter said he was ready for the question. He was concerned that it could be about a complex topic that he wasn't very familiar with. A few hours later, an email arrived with the subject "SCREENING QUESTION," flagged with high importance.
Glen sent this in and I am grateful!! This is apparently a hidden feature of some software that ships with certain Asus motherboards.
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…
Today's snippet comes from an issue that Brian discovered in the production code of a large telecomunication company's call center software. It attempts to solve a fairly simple problem: get the handle to a specified window and, if it can't be found, try again for MAX_SECONDS. However, there was a bit of an issue with the default wait time...
I hope that WorseThanFailure is James E.'s favorite internet.
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.
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.
When Lex submitted a large snippet of code from an older ASP/VBScript application that he had inherited, I was considering extracting the following single line and publishing it as a Representative Line...
set rsCSS = db1.execute("select * from tblCSSClasses")
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...
As Stephen A.'s client was walking him through their ASP.NET site, Stephen noticed a rather odd URL scheme. Instead of using the standard Query String -- i.e., http://their.site/Products/?ID=2 -- theirs used some form of URL-rewriting utilizing the "@" symbol in the request name: http://their.site/Products/@ID=2.aspx. Not being an expert on Search Engine Optimization, Stephan had just assumed it had something to do with that.
A few weeks later, when Stephan finally had a chance to take a look at the code, he noticed something rather different...
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.
Despite what our teachers may have said, there is such a thing as a stupid question. And generally, newbies are the ones asking ‘em. I know I sure did (thankfully, under a pseudonym). But unlike the mean-old folks who would often answer my questions (“RTFM, idiot!”), I don’t believe in picking on those trying to learn. In fact, today, it’s time to pick on someone trying to teach…
Gonzalo Larralde pointed me to discussion on a coding messageboard where a poster asked a fairly simple, naïve question: “How do I create a multithreaded application using PHP. i want to write scripts that run parallelly.” As I’ve discussed before (see Pounding A Nail: Old Shoe or Glass Bottle?), my response would have been an explanation of what’s fundamentally wrong with such a question. Another poster, however, had a different answer…
Huh huh huh watch whut I'm gunna write in Scrabble huh huh.
(submitted by Adrian)
Everyone knows that global variables are a Bad Thing. It's not too clear why they're bad, but it probably has something to do with speed. Think about it. You never know where a Global could be (it could be across the Globe, after all!). But a Local variable -- it's always right there, nearby.
Serge's colleague discovered a way to gain all the benefits of global variables without hampering performance too much ...
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.
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.
"...and that's why Colgate can kill you. And now a word from our sponsor... Colgate?! Ahh, crap."
(submitted by Jim S.)
While reviewing some old JavaScript code in his company's core application, Dan Howard came across this pain.
For some reason, the "developer" decided that he has to Javascript's Eval() for each line of code. Some in a try/catch... others without...
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.
You're special, reader. You're probably a developer and since you read this site you probably care about writing code that won't ultimately wind up being featured here. And you're hard for employers to find because you're probably employed and not looking for a job.
Now that I find myself the interviewer rather than the interviewee, it's really clear that good developers are hard to find. Even harder when you're a small company sitting under the shadow of big huge corporations that swallow up all the local developer talent. Such was the situation Brent R. found himself in.
Andrew K. discovered that the Skype updater is probably not using the right time conversion function...
Dave works as a programmer in a small IT department within a large division of a gigantic company. Unlike his company’s Central IT, his division’s IT department doesn’t seem to hire regular programmers. Instead, they take people from within the division that have programming acclimations and stick them on the programming team. Combine this with the lack of a real development process, testing, or even user feedback, and a lot of interesting programs end up in production.
Instead of sharing a line of code to represent his department’s applications, Dave decided to send in the entire contents of a single file (“please.txt”) that was found amongst a number of other text files and executables within one application’s deployment folder...
CodeRookie evidently isn't just a clever name.
(submitted by Scott)
After running this site for a little more than three years, it’s rare that I’ll come across a snippet of code that leaves me speechless. Today’s snippet comes from a large Java application that Byron recently started working on and is … well, I’ll just let the code do the talking…
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.
Today’s first snippet comes from some work that was submitted to Yndy from a new coder for his company’s code review. The second snippet is the revision to that code.
Yndy’s company’s coding standards are pretty straightforward. One states “variable names shall differ by more than one character.” It’s pretty reasonable: who wants to accidentally use “day” instead of “days” when both are declared in scope? Another is just as reasonable: inline comments should be added at the point of variable declaration to make the code more understandable. Apparently, neither rule made sense to Yndy’s coder…
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.