IT Commandment: Thou shalt not fear change

Fear of change blocks many technology decisions and leads many technologists to fight against technology they probably shouldn't.


I've been wracking my brain for a commandment which would fit with the theme this week, and I figured that the commandment "Thou Shalt Recognize the Inherent Superiority of Microsoft Software" might be a tad too partisan, particularly coming from guy who works for Microsoft in its IPTV division (queue maniacal laughter here).

"Thou shalt not fear change" might seem like a mild, and somewhat obvious, commandment, particularly in an industry typified by rapid change. Unfortunately, it isn't from a practical standpoint, something which is understandable given the investment every one of us puts into keeping our IT skills sharp. It is expensive both in terms of time and money to learn a new technology framework. Likewise, it's simply not an option to become an expert in all technologies. Granted, certain skills are very portable across technology domains. However, becoming a master in the intricacies of Java takes time, and leaves you less opportunity to become a master in the intricacies of Oracle database tuning, or Windows programming.

This economic reality can sometimes overpower the natural love of technology which made technologists choose their profession in the first place, engendering a conservatism which can block change. I've faced it more times than I can count, and applies to technologists favoring any platform. I've fought with Oracle technology experts who think that Oracle tools should be applied in all situations, Unix experts who treat the incursion of Windows into their environment like a body defending itself against infection, and Windows experts who view the growth of open source with fear normally reserved to attack by chainsaw wielding asylum escapees.

The fear of change isn't just confined to new technology. Many of us grew accustomed to the overheated job market of the 1990s, with its fast wage growth, job security, and headhunter queries filling our inbox. That market was driven by a telecommunications revolution set in motion by the creation of a global Internet, a side benefit of which was telecommunications links which enabled ever closer integration between IT centers around the world. That created competition from sectors that programmers in rich nations didn't expect, such as developing nations like India and China who charged far less than local programmers.

In the boom years when IT resouces were in short supply, nobody noticed. But when the boom turned to bust, fear set in, and former fans of free markets became closed-border, anti-market fanatics within months. Those foreign programmers were taking "our" jobs, and we have to stop them lest the American economy pop like an overinflated balloon.

As I've discussed before, however, foreign outsourcing isn't the jobs catastrophe people make it out to be. That seems less controversial today now that IT markets have picked up. A defense of international outsourcing would meet with less negative response today than at the start of 2004, simply because markets have digested the ramifications of outsourcing and realized that it's an addition to the IT resourcing toolkit, not a wholesale replacement. Outsourcing lowers costs for certain types of tasks, leaving more money for the new development tasks that local developers do best.

None of this is meant to imply that there isn't room for a principled defense of a position you think is right. Fans of Oracle tools, Unix or Windows are free to defend why they think their favored technology is best suited to the task. Local programmers are free to describe why outsourcing a particular new development project to India is a bad idea (as I've noted, new product development is a poor candidate for outsourcing).

It's important, however, to keep an open mind and embrace change when it's clear that that change is for the general good (even if it entails some work on your part). That may sound obvious, but then again, if you think about the sort of things that tend to find their way into historical lists of "commandments," they usually are obvious.

The trick is adhering to them.

Our IT Commandments:
  1. Thou shalt not outsource mission critical functions
  2. Thou shalt not pretend
  3. Thou shalt honor and empower thy (Unix) sysadmins
  4. Thou shalt leave the ideology to someone else
  5. Thou shalt not condemn departments doing their own IT
  6. Thou shalt put thy users first, above all else
  7. Thou shalt give something back to the community
  8. Thou shalt not use nonsecure protocols on thy network
  9. Thou shalt free thy content
  10. Thou shalt not ignore security risks when choosing platforms
  11. Thou shalt not fear change
  12. Thou shalt document all thy works
  13. Thou shalt loosely couple