I noted last time, once again, that “IT is hard. In fact, it’s so hard that it seems most people have to learn certain core lessons by themselves.  It seems like everyone needs to burn his or her own hand on the hot stove.”  I went through some examples of this sort of “hot stove” lessons particular to management; this time, let’s talk about similar “hot stove” lessons/myths I’ve observed in other IT areas, most notably development and operations.

• Source code control and release management. One of the traits of a superlative programmer is his or her ability to maintain a complete logical model of the system/program in their head.  The really good ones are in fact really good at this.  Unfortunately, their consummate skill ironically leads to them sometimes resisting tools that help out with some of the logistical pitfalls that arise as system complexity increases.  Source code control is the most important such tool.  Programmers have even told me, “I can just keep track of what I’ve changed and what’s where.”  In a way, I suppose this is a species of the (typically male) trait of refusing to ask for directions—it’s a reluctance to embrace appropriate tools that are designed to avoid common screw-ups and to facilitate overall team success.  Suddenly, though, complexity mushrooms: releases overlap and patches are made in the heat of the moment, and without impeccable source code control and release management, bugs reappear, QA takes longer, and so on.  Typically, I’ve seen this “hot stove” lesson not really get learned by an organization until the source code control failure causes a notable customer-facing issue with a major release.

[Read more…]

Regular readers here have certainly noticed the recurring nature of many of my posts: “things about IT that should be obvious, but clearly aren’t.”  Each week, as I set about writing on my chosen topic, it often strikes me that what I have to say is anything but new or radical; rather, it seems to embody fundamental, well-known practices and underpinnings that should be, if not incredibly obvious, at least quite familiar to anyone who’s spent much time in or around IT.  Yet, as I reflect on my actual experiences, I realize anew that I’ve spent much of my career working up and down the executive and worker chain to absorb and impart these basic principles again and again.

So here comes more of the same.  In fact, this dual post encapsulates a lot of what I’ve written about on this blog for the last year: lessons learned and lessons still learnable about IT for the people who work in it and the people who have to deal with it.  In other words, I should hasten to say, these are not only IT management lessons, but lessons related to development, operations, QA, and project management: in other words, the whole spectrum. 

As I’ve observed before, IT is hard. In fact, it’s so hard that it seems most people have to learn certain core lessons by themselves.  It seems like everyone needs to burn his or her own hand on the hot stove.  So here are some of the glowing redhot stove elements that I’ve watched make fingers (including mine, for I’m not immune either from learning some things the hard way) sizzle over the years.  I’ll start here in part I with lessons particular to management, and next time will cover similar lessons/myths relating to other IT areas.

[Read more…]