DevDisasters
Hired Help for the Holidays
To accommodate an influx of year-end work, Guillaume's employer does what many stores do -- hire on temporary help. However, when you're desperate, beggars can't always be choosers.
It was an annual event on which you could almost always count.
As November drew to a close, the local companies that Guillaume's employer -- a small, five-man IT consulting firm -- serviced would find themselves suddenly up to their eyeballs in new work. Their clients always had money left in their budgets and, under pressure of possibly getting budgets renewed for next year at a lesser amount, switched into use-it-or-lose-it overdrive, making tons of requests for new features and changes that could wait until next year, but heck, we have the money now, so why not?
Not being a group that would turn away piles of cash, they were happy to accept the influx of work, but at the same time, they were nowhere near being staffed for such a large up-tick. Their solution was similar in many ways to that of the big-box retailers: hire on a few extra temporary workers to help.
Now, these guys weren't terrible. They were mostly a motley crew of students and recent grads, literate in C#, and more interested in having beer money than a resume-building experience. And they were good enough to write code that worked, though not always perfectly. So, when Guillaume received a message from one of the firm's clients stating, "We are seeing tons of weird problems in Stage. Exception-somethings everywhere! Do NOT install in Production!" he did what he did every year.
He rolled up his sleeves and assisted in fixing a few bugs.
Guillaume started out by reproducing the issue. As it turned out, the client wasn't kidding. Everywhere Guillaume looked, the application was throwing time-outs and other exceptions all over the place.
Figuring that any spot was as good as any, he jumped in and looked at one of the database calls:
DataSet dsTaskDetails = workhoursbll.ReturnTotalWorkedHours(idFT);
if (dsTaskDetails.Tables.Count > 0 & dsTaskDetails.Tables[0].Rows.Count > 0)
Guillaume thought to himself, "That's good, they check that the dataset does indeed have tables before reading the first one." But then he noticed that, no matter if there was a table or not, the second statement would always run.
Initially, he was puzzled. After all, the code looked reasonable. But soon, it hit him in the face. That's a &, not a &&. Throughout the code, any time a change was made, they were using the binary "and," not the Boolean "and."
Guillaume tried to explain to the team that it's not the same thing; that, yes, in most cases the result of the expression would be the same, but in this case they wanted the if statement to stop evaluating if the first part wasn't met. No matter how hard he tried, though, they kept perpetuating the same errors, as if they just couldn't understand the difference between & and &&.
Defeated, Guillaume just told them to forget about it and to always use &&. Before deploying to stage, he would run a replace-all to fix the changed code, all the while thinking that January couldn't come soon enough.
About the Author
Mark Bowytz is a contributor to the popular Web site The Daily WTF. He has more than a decade of IT experience and is currently a systems analyst for PPG Industries.