The top 20 IT mistakes to avoid

8. Mishandling change management

Free IT resource Hear how top CIOs turn change into a competitive advantage. Sponsored by HP Free IT resource Attend the SOA Executive Forum: Breaking SOA Bottlenecks SOAExecForum.com/may2007 Sponsored by InfoWorld DOWNLOAD PDF Click here to download InfoWorld's special report Top 20 IT mistakes

The former CTO of a computer equipment manufacturer describes one situation in which a talented, but perhaps overly ambitious, systems administrator decided to make seemingly simple changes to a set of critical servers during routine maintenance.

While this individual was making the changes, all of which had been agreed on and planned in advance, he decided on his own to upgrade BIND (Berkeley Internet Name Domain), the open source server software that powers mission-critical local DNS for many companies.

A few hours later, the entire business was at a standstill, as all DNS functions failed. Reversing the “one small change” took hours, and millions of dollars in revenue were likely lost as a result. The lesson is that even talented employees can cause major problems when they don’t follow change management procedures.

Remember, change management is cultural. It all starts at the top: If IT management cuts corners, so will IT staff.

9. Mismanaging software development

In his seminal book The Mythical Man-Month, Frederick Brooks posited that planning software-development projects based on per-unit “man-months” ultimately does not work due to the unique nature of software development.

Even if the building of software could be broken into easily managed, interchangeable time units, the vast productivity difference between the best coders and merely average ones means IT managers might get their best work out of fewer, but more talented, programmers doing their work in less time.

Henri Asseily, CTO of BizRate, tells us via e-mail, “The right individual will always create better and faster core software than a group of people [will]. Everyone in every industry talks the usual talk of, ‘We invest in people,’ or, ‘Our people are our greatest asset,’ but nowhere is it more important than in IT. Simply put, a great programmer is 100 times more valuable than a regular programmer.”

The mythical man-month has been part of software lore since Brooks’ book came out 30 years ago, but many IT managers still plan projects and staff them based on this disproved paradigm. Holding on to this method might lead a naïve IT manager to staff a project with the right number of people for a defined amount of work, but CTOs such as Asseily insist that getting quality people is most important.

“IT managers should devote most of their free time to [finding] the best people. Almost nothing else matters, really,” Asseily says.

10. Letting engineers do their own QA

Not allowing engineers to do their own QA is an axiom of software development, but for small software development teams, there is always the temptation to cut corners. In fact, sometimes management colludes with developers to enable the practice. One CTO relates a situation in which a software development project was running significantly behind schedule and the lead developer had begun to do his own QA to try to speed up the release process. To make matters worse, the lead developer had planned a vacation that was approaching rapidly. A day before the vacation commenced, the developer pronounced all outstanding bugs resolved, and the system was released into production. By the time the developer arrived at his tropical destination, the system was crashing to the point of being unusable. Many of the existing bugs had not been corrected because the developer had not tested thoroughly or formally. Allowing engineers to perform their own QA is akin to allowing  defendants to be the judges and juries for their own trials.

11. Developing Web apps for IE only

Despite the fact that mission-critical applications continue their march onto the Web browser and that Windows continues to dominate the corporate desktop, Web developers should avoid the temptation to develop applications only for bug-ridden IE. IT shops that insist on using IE for Web applications should be prepared to deal with malicious code attacks such as JS.Scob.

First discovered in June 2004, JS.Scob was distributed via compromised IIS Web servers. The code itself quietly redirects customers of compromised sites to sites controlled by a Russian hacking group. There, unwitting IE users download a Trojan horse program that captures keystrokes and personal data. Although this might not sound like a threat to corporate IT, keep in mind that employees often use the same passwords across corporate and personal assets.

Many enterprises may not be able to avoid using IE. But if you make sure your key Web applications don’t depend on IE-only functionality, you’ll have an easier time switching to an alternative, such as Mozilla Firefox, if ongoing IE security holes become too burdensome and risky for your IT environment.