Top 10 IT Pet Peeves, Part 1

What common mistakes make life harder in the IT trenches? Joe Stanganelli investigates.

Everybody's got pet peeves. That's especially true of those who work in IT, where cleaning up other people's messes and fixing other people's mistakes is often a large part of the job. With that in mind, Enterprise Networking Planet presents the first in a series covering the top 10 IT pet peeves, which I uncovered in conversations with IT pros.

Dave Henry is an IT manager for Accunet Solutions. His official job title is "Virtualization Practice Lead, Storage Practice Lead."

He's also an archaeologist.

"You've had three different administrators in the past three years," Henry recounts telling an amazed customer. Henry was, of course, right.

Henry calls what he did "IT archaeology": digging through layers and patchworks of code collected over the years to determine a network's history.

I asked Henry about his thoughts on what stands in the way of best enabling IT in the enterprise. His immediate response: "Too many administrators [and a] lack of administrator consistency."

Comparebusinessproducts.com sums up the problem well in a blog post detailing the habits of "the terrible network administrator."

"[He] will automatically assume that his predecessor was an excellent administrator, and not bother to find out if programs are up to date, if there are airtight security and password policies in place, if there are detailed records of past attacks and intrusions, and if employee access rights are controlled and monitored on a regular basis."

Just as a new administrator should never make assumptions about the past, so too with the future. Admins must consider how to keeping everything running smoothly, regardless of what happens. Good administration is forward-thinking.

"I try to think about a guy I call Future Dave," says Henry. "Is he gonna be cursing Past Dave, or thanking him?"

9. Poor Infrastructure Maintenance

"Overbuying technology…compensate[s] for poor administration," points out Steve Athanas, IT director for University of Massachusetts - Lowell. "Just because your administrators don't know how to manage spindles and clock cycles and can't make the most use of them doesn't mean you need new servers or storage; it means you need new administrators." (And, perversely, as pointed out above, this in turn can lead to inconsistent administration if handled poorly, which can lead to more poor technology choices, and so on.)

These organizations, says Henry, "[do] not tak[e] best advantage of the storage they've already connected." Indeed, a wily administrator or IT director will look at the resources a company already has when making vendor and infrastructure decisions. For instance, as was pointed out to me recently, a scalable turnkey "cloud-in-a-box" console may suit a company's needs better than an actual cloud solution if the company has already invested in quality storage and other hardware on-premises.

Sometimes, however, the organization's on-premises hardware is a mess.

"[There are] datacenters that don't standardize on hardware specifications," complains Athanas. "This isn't a Best Buy—pick something that you can learn inside and out. You shouldn't have to contact a different company to get parts for each system."

Virtualization, too, is not immune to poor IT planning. According to Henry, organizations don't think enough about their virtual machine resource pools and proper allocation. This can lead to interdepartmental cases of the rich getting richer and the poor getting poorer. Henry therefore advises administrators to set appropriate maximum limits on these pools. This way, all departments can get a slice of the VM pie, and those who genuinely need more can be assured more.

Still, not all IT pet peeves are properly blamed on management. Anybody can shoot themselves in the foot – particularly when they make…

8. No Comment, No Documentation

"It's always important to document your code properly," warns data privacy attorney and former software engineer Alia Luria, "[yet] it is often neglected."

"[F]ailing to document code frequently leads to other engineers having to rewrite pieces of it because they don't understand it," Luria explains. "It also can result in people inadvertently making changes to a piece of code that remove some intended but not immediately obvious functionality."

Henry, for his part, recognizes the importance of process.

"[I] comment my own code for me," he boasts, "not the other guy."

He has, however, been both perpetrator and victim of this IT no-no. Henry talks about a time he spent reviewing some old code of his. Thinking that his programming skills had improved tremendously over the years, Henry was convinced that the code should be written differently.

And so he rewrote it—using the "new tricks" he had learned—and broke the whole thing.

"Past Dave had thought it through," says Henry of his all-too-late realization.