andrusi: (Middy- hacking time!)
Andrusi ([personal profile] andrusi) wrote2011-10-28 08:49 pm

Five Second Delays

One of the first programming projects I worked on at UNC Charlotte, which has been an occasional thorn in my side ever since, was a web application called eAdvising. [shudder]

eAdvising [shudder] was my boss's idea for how to solve something that doesn't initially even sound like a problem: academic advisers spend a lot of time meeting with students! The horror! But actually, about twice a year, it does become pretty horrible. That's because students are required by the university to meet with an adviser and get their proposed schedule for the next semester approved before they're allowed to register for courses--and as such, within the space of a few weeks, every student who isn't in the process of graduating has to meet with an adviser. And there aren't terribly many advisers. So basically, advisers are stuck in their office all day meeting with student after student after student. The majority of students are capable of figuring out what courses they need on their own, so most of the time the adviser's job is basically to rubber-stamp approval, and both the adviser and the student end up feeling like that was a complete waste of their time. What eAdvising [shudder] does is allow this process to take place over the Internet. The student completes an online course plan and submits it, the adviser looks over it at any convenient time and either approves it or requests changes, and any students who do actually need to meet with an adviser have a fighting chance of being able to schedule a meeting at a time that's convenient to them.

eAdvising [shudder] ultimately involved quite a few people, but for the most part it was a collaboration between myself and another programmer, whom I will call Mr. P to preserve his anonymity. I mostly worked on the interface the students saw and the code that made it tick, while Mr. P was mostly responsible for the advisers' side of the application. (There was some crossover when our boss decided some bug or unfinished feature needed to be addressed Right Now, which wasn't uncommon.) Mr. P was not a bad programmer by any means, but he was relatively inexperienced (to be fair, so was I) and rather impulsive, and he had a coding style very different from mine, so it wasn't uncommon for him to do something in the adviser interface that broke or overcomplicated something in the student interface. (Again, to be fair, I'm sure I caused him quite a few headaches as well.)

There was one particular incident that has become something of a running joke in my workplace. One of our recurring issues was that the jqGrid for displaying academic plans didn't always successfully load plans from the MySQL database (that's programmer-ese for "sometimes the student's courses didn't show up"), for reasons we never did quite figure out. So I was very intrigued to come in to work one morning and see an email from him explaining that he'd solved the problem.

I was even more intrigued when I discovered the problem wasn't actually solved.

I poked through the code to find his latest commit, and went from intrigued to just confused. As a comment block helpfully explained, the problem was that the grid was trying to load things too quickly, and so Mr. P had added a delay of five seconds between when the page loaded and when it tried to load the academic plan. But obviously that hadn't worked.

In fact, there was no way it possibly could have worked, because upon closer examination, the delay had been inserted into the wrong branch of an if statement--we were seeing the problem under only one set of circumstances, and his "solution" would only come into play under a different set of circumstances. I asked him about this, and he confessed that he had been in a hurry and hadn't tested the "fix" thoroughly, and he'd mistaken "the intermittent problem didn't happen to occur after about two tries" for "the intermittent problem will never happen again."

"Andrusi! Why are you telling us this?" Because of the recent privacy debacle over at LiveJournal. If you haven't heard, LJ's latest release (or possibly a subsequent tweak that hasn't been officially documented) appears to have caused a severe security issue: users are now occasionally finding themselves inexplicably logged in to other people's journals, with access to all their locked entries, the ability to post and comment, and so on. LJ has made a post about the issue, in which they claim nobody could edit anybody's things or post as each other and it was only happening for about three minutes and then was fixed. Comments overwhelmingly say this is incorrect (and raise a lot of other points, but not ones I'm talking about here): it was still happening 24 hours later, it may still be happening, and people had full access to other people's accounts.

I can't see this as anything other than a five-second delay. LiveJournal was faced with an intermittent problem that they thought they understood but didn't, and without really thinking through the implications of an intermittent problem, they essentially assumed their fix had worked when it hadn't. Which is fine when you're dealing with a loading failure in a test environment, but for something like a major security breach, this kind of haphazard problem-"solving" is not remotely what anyone needs.

Post a comment in response:

Anonymous( )Anonymous This account has disabled anonymous posting.
OpenID( )OpenID You can comment on this post while signed in with an account from many other sites, once you have confirmed your email address. Sign in using OpenID.
Account name:
If you don't have an account you can create one now.
HTML doesn't work in the subject.


Notice: This account is set to log the IP addresses of everyone who comments.
Links will be displayed as unclickable URLs to help prevent spam.