Category: life in information technology

Project timelines

I find it very difficult to estimate project timelines. Things usually take longer than I expect, and I never seem to learn. When someone asks me for a project timeline, I usually tell them that it will take somewhere between two hours and eighteen months.

As a recent example, I wanted to add a skip-to-main-content feature to a web application, because the application was growing a large block of navigation links at the top of every page. I figured this problem would have a widely-accepted solution, and that this would be a ten-minute task.

A web search quickly disabused me of that assumption. Lots of people solve this problem in different ways. I was looking for something that would

  1. work in most or all modern browsers
  2. hide the skip link until the keyboard user TABs to it
  3. not require JavaScript
  4. (most importantly) manage focus such that using the TAB key again advances focus to the next focusable element.

Here’s the implementation I ended up using. It’s still not perfect, because it won’t work in Firefox on OS X (not without some help, anyway).

So with evaluating search engine results, trying several different things, and then testing on a bunch of browsers, this ten-minute task took all morning one day.

At times like this I’m reminded of The Money Pit, a 1986 film with Tom Hanks and Shelley Long about a couple who buy a house and hire a bunch of contractors to renovate it. Every time they ask the foreman how much longer the work will take, he says, “Two weeks” (typically with derisive laughter).

So if you’re writing about someone who works in technology and need some day-to-day flavor for her, have her deal with a money pit assignment and an impatient customer.

Advertisement

Scanner hell

Here are a couple of “life in IT” horror stories, both involving desktop scanners. This is to give some idea of what it’s like when things go wrong while working in information technology. These particular misadventures were more frustrating that terrifying.

While my main responsibilities at work involve programming, I’ve ended up helping out with our imaging system. This means that I set up desktop scanners and configure desktop software to interface with the document management software running on one of our servers. I’ve probably done this kind of thing several dozen times. Although it can be time-consuming, it usually goes pretty smoothly.

Last week it didn’t go smoothly.

It was a brand new scanner and a brand new computer. I installed the scanner drivers off the installation CD, told the installer to download and apply the latest driver updates, hooked up the scanner, and configured the software to allow the user to scan pages (things like transcripts, release forms, etc.) into the imaging system. Like I’ve always done, I enabled the image processing feature to do things like deskew the images (that helps if the paper feeds into the scanner a little bit crooked). Every time I tried scanning a page into the imaging system, the desktop software would crash.

I un-installed the drivers, re-installed the drivers, reconfigured the desktop software, and the same thing happened. So I called technical support at the imaging system software company. A very patient technician made a remote connection to the PC so that he could try fixing it. For two hours I watched him do the same things I’d done with the same result.

He finally tried configuring the software without enabling the image processing feature. I saw him skip that step and almost said something about it, but I was tired and didn’t say anything. And of course that time it worked. Then I asked him to enable the feature, we tried it again, and the software was back to crashing. Disabling the feature again made the software start working again. So we left that feature disabled and called it “good enough.”

So as near as we could determine, the only thing wrong was enabling a helpful feature that I’ve used for years.

The other scanner nightmare was a few years ago. This one was a flatbad scanner–the type where you open a lid, put a single sheet of paper on a glass pane, close the lid, and the scanner moves a lamp back and forth under the page, taking a picture of it.

This was an older scanner that had been in storage for a while. That fact turned out to be significant.

I installed the drivers, hooked up the scanner, and tried to scan a page. I could see the lamp come on, and I could hear it trying to move. It made a delightful kuh-KUNK noise, and it was clear that the lamp wasn’t moving back and forth like it should.

This episode also involved a long phone call to the software vendor. In retrospect I probably should have called the scanner manufacturer, but it wasn’t clear to me where the problem was. The help desk at the software vendor has lots of experience with scanners, and I think they must have a room that’s nothing but scanner after scanner sitting on shelves, because they came up with a scanner just like the one I was struggling with–same manufacturer and model.

After an hour or two, the two technicians on the call were finally able to reproduce the problem I was having. I could hear them chuckling as one of them said, “Pick up the scanner and look on the bottom. Do you see a black slider switch with a couple of little padlock icons? And is the switch in the LOCKED position?”

Some helpful soul had locked the scanner when they put it in storage. So I moved the little switch, and was done setting up the scanner a few minutes later.

This is what happens when they put a programmer in charge of things with moving parts. It always ends in tears.

Security audits: what they’re like

In the previous post we saw that data breaches in higher education can affect a large number of people, and that state legislatures and university administrations really want this problem to go away. (Spoiler: it’s not going away.)

One result of this is more and more information security audits at universities. Auditors start by reading the university’s policies pertaining to information resources, and then they look to see if the university is following its own policies. The auditors interview people all over the university about the details of their processes, and they portscan networks looking for out-of-date software and poorly-configured servers. They inevitably find fault with the policies and/or some discrepancy between what’s written in policy and what’s actually happening. The auditors write up their findings in a report, and they submit the report to high-level administrators. The administrators read the report and send it (along with some harshly-worded threats) down to the next level of management, and this process repeats until the report finally reaches someone who can actually do something about it (the hapless front-line pukes who administer networks and servers).

Reactions frequently include one or more of the following:

  • Why did the auditors have to tell all of my bosses about this? Why couldn’t they just tell me so that I could fix it (quietly)?
  • This is a purely theoretical vulnerability that couldn’t possibly affect us, and I don’t want to fix it.
  • This is a false positive, and I don’t want to fix it.
  • I could fix this, but I’m afraid that it would break something else, so I don’t want to fix it
  • Correcting this is too difficult, and I don’t want to fix it.
  • Well we’ve had this condition for a long time, and nothing bad has happened, so I don’t want to fix it.
  • I’m a new employee, and I’ve inherited all this stuff that someone else left in this sad state, and I don’t want to fix it.
  • The auditors are jerks, and they couldn’t find anything really wrong, so they’re picking on this unimportant little thing, and I don’t want to fix it.

Administrators and auditors have little sympathy for these reactions (however legitimate they may be), and these audits are becoming increasingly adversarial. People at all levels of the organization lose their jobs over these things.

So if you’re writing about a character who works in IT, and you want to increase the tension this character is experiencing, put her through an audit.

Security audits: why they happen

This post is to give an idea of one of the less glamorous parts of working in information technology. Everybody answers to somebody, and sometimes that somebody wants to inspect your work.

Disclaimer: I’m speaking from my own experience, which is in higher education at a public university, and that university is a member of a larger university system. My own chain of commands looks something like this:

  1. manager of my section in IT
  2. chief information officer of the university
  3. president of the university
  4. chancellor of the university system
  5. board of regents of the university system (who are appointed by the governor)

And somewhere between #4 and #5 there’s an office of internal audit.

Although my university usually does pretty well, higher education in general has at times had a poor record of information security. The office of inadequate security has plenty of announcements involving higher education institutions.

When an organization experiences a data breach, they frequently don’t discover it themselves. Notification sometimes comes in the form of a phone call from the Federal Bureau of Investigation. The university administrators have to notify the entire university community, and the university typically has to pay for credit monitoring for everyone affected. That can add up quickly, because a higher education data breach can potentially affect a lot of people: students and their families, alumni, staff and faculty (past and present), job applicants, even donors. Larger universities mean larger numbers of people.

Imagine that you’re on the board of regents, and you’re addressing a bunch of donors. Some freaked-out-looking assistant hands you the phone, and it’s the feds telling you that they’ve discovered people selling the names, dates of birth, and social security numbers of thousands of students currently attending the university for which you are at this very moment trying to convince these donors (who are staring at you wondering why you’re talking on the phone and not to them) to cough up money for a new sports facility. Awkward.

So when this kind of thing happens, breach victims (understandably) tend to complain to their elected leaders. State legislatures have taken notice and are increasingly putting the screws to state agencies to get their digital affairs in order.

In the next post we’ll see what security audits are like (and how they affect people who work in IT).