IT, States of Denial, and more Peterisms

Yes, I admit it’s an old and hackneyed play on words, but I’ll repeat it anyway: in the course of my career, I’ve worked in IT positions in the fine States of New York, California, and Washington, but I’d have to say that the most frequent state I’ve encountered in IT matters has been the State of Denial.

It seems to be a common trend, up and down the levels of a company, to engage in a bit of willful self-delusion about IT matters, practices, outcomes.  As I thought about this, I realized that several of my key “Peterisms” (these being sayings that come out of my mouth again and again, as already chronicled here and here) have evolved as a response to this persistent theme of “states of denial”.  So let’s talk about three more of those Peterisms in that light.

• Everyone wants to get to heaven; no one wants to do what it takes to get there.

A former boss of mine was especially fond of this one.  With business stakeholders, the saying tends to pertain to things like wanting robust delivery, solid systems, ease of maintenance and flexibility, and high predictability of time frames for development and release.  But then you confront them with the not-so-shiny prerequisites to getting those things: e.g., the need for careful prioritization of desired functionality; the importance of not trying to get everything all at once; the need to hold to plans once they’re formulated, rather than changing the game every week; taking the time to test and carefully document even though those activities sometimes just seem to delay “the real work” of delivering what they want. There are tons of other examples, of course.

With IT staff (developers, operations folks) themselves, the saying pertains to things like wanting to set their own time estimates for completing their tasks; to be protected from “death march” overtime; and to have the freedom to set their own tools, standards, hours.  But then you confront them with, again, the not-so-attractive means to achieve those ends: the importance of actually hitting the estimates they themselves have provided, and the need to reduce the rework that results from people adopting different and undocumented tools and approaches.

Discipline is tough, especially self-discipline.  Across the business, I often see people wanting all the possible upsides and accepting neither the means to those ends, nor the risks or trade-offs that will necessarily ensue from those approaches.

• There’s no substitute for tedium

This one’s an original, one that I love to drone out in an onomatopoetically intentional monotone, but in truth, it’s just a restatement or narrowing of the one above. I can’t tell you how often I’ve seen people whine that something in IT is hard work or boring: going item-by-item through bug lists or feature/function estimates, for example.  I’ve probably spent literally years of my life, if you placed all the sessions end-to-end, sitting in groups meticulously going through bug lists in preparation for a software release or update.  People are often tempted to cut corners in these situations, but every time I’ve seen that attempted, the released software ended up with inexcusable issues that should have been caught and fixed prior to going live.  Functional prioritization is similar: people often want to take a power-determined “I’ll just be the one to decide” approach to it, but that’s usually done in tunnel vision, without a full look at the competing functions that would merit potentially higher prioritization than what tends to be picked through such a seat-of-the-pants approach.

There indeed may be no real substitute for this sort of tedium, but that’s still not an excuse or justification for liking it: you’re still obligated to do everything you can to reduce the amount of tedious overhead you go through, in a “continuous improvement” manner.  In the case of bug lists, for example, you want to make sure that you insist on testers entering accurate, pithy bug descriptions so that you don’t spend precious minutes repeatedly “rediscovering” what the real issue is before you can decide how large an impact the bug has.  You want to make sure you get adequate (neither understated nor overstated) assessments of each bug’s severity, so that you can operate in rapid triage mode.

• If you want to make an omelette, you’ve got to break some eggs.

I actually stopped using this one for a while, ever since I heard it was attributed to Stalin.  Fortunately, it now appears that attribution was untrue (was it Taft? Robespierre? Chamberlain?), so I can use it again in clear conscience.

Just as the main point of the first two sayings is “nothing comes without a bit of hard work,” the point of this saying, at least in terms of how I use it around IT situations, is that nothing comes without some downsides or impacts.  Changing a system to be more functional may make it less usable or elegant. Automating a process may offend or threaten people who are responsible for the way the current process is manually handled.  Downsides.  All of these must be carefully analyzed, openly discussed, and courses of action deliberately chosen while taking their impact into account. The alternative?  Denial: thinking that there’s a Shangri-La alternative out there that has no downside, where there won’t be any negative impacts, and where there is no risk.

When it comes to IT, whatever your role, you need to be ready and willing to accept that it’s going to entail some hard and often tedious work.  And you need to be mindful of the ever-presence of downsides to whatever alternatives you painstakingly choose.  Otherwise, you’re destined to be one of those people existing in a State of Denial.  And nobody wants that.