I’ve done several posts featuring what I call “Peterisms”, which are basically aphorisms I’ve adopted that encapsulate hard-earned IT lessons. Let’s turn it around this time, and talk about two sayings that sound equally folksy-sensible, and that I hear again and again, but which I feel are actually dangerous to apply to information technology work. And, of course, I’ll discuss why that’s so.

• If it ain’t broke, don’t fix it

• A camel is a horse designed by a committee

So, not all aphorisms are created equal. If you’re in IT, I advise that you avoid the attitudes and philosophies contained in these two.

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.

More pithy sayings that (at least in my view) I reuse in an attempt to succinctly express key concepts and lessons. Or, perhaps in many cases, to annoy my staff via tireless repetition. I have several dozen of these sayings, most likely (I haven’t actually counted), and for many of them I can no longer remember their origin. The ones this time around, though, are attributable. You are free to draw conclusions or insights about my cultural values from the breadth of sources represented here. Aside from the theme of wildly disparate cultural derivation, though, these apothegms have another common thread to them: they tend to come to mind as you go through the standard back-and-forth negotiations with business stakeholders about features, projects, workload.

• Don’t let best get in the way of better.

The person I heard this aphorism from originally almost certainly didn’t invent it, but nonetheless, I can never read or say these words without hearing the soft Mississippi drawl of Jim Barksdale.

Engineering anything (software, hardware, bridges, machines) is all about meaningful and careful compromise. For a number of solid practical reasons (time and expense being chief among them), no one in any branch of engineering gets to pull out all the stops and insist on the ideal in all aspects of constructing a product — indeed, I’d argue that much of the thrill of good engineering actually consists of working within limits and achieving maximum effect despite the barriers. Nonetheless, I’ve frequently seen IT professionals fall into the trap of trying to maximize all things, reduce all risk of failure, allow for all contingencies: and that way lies almost certain failure.

Equally, business stakeholders can err on the side of insisting on the ideal. Sometimes it’s because they figure that if they don’t ask for everything up front, they’ll never get it. Other times, it’s feeling that there’s absolutely no utility to a partial implementation of what they want. That stance, too, is self-defeating: it leads to “big bang”-like projects being spawned and undertaken (with a high rate of failure), rather than working iteratively through successive versions and feature releases to get what is needed. For particularly glaring examples of stakeholders feeling that only absolute perfection is worthwhile, take a look at the bulk of the messages left on Apple message board sites after any product release, no matter how stunning that release was. Fault-finding, carping, general dissatisfaction abound — and this is from the fan base!  Another way I’ve heard this aphorism expressed is that “the perfect is the enemy of the good.”

• The reasonable man adapts himself to the world; the unreasonable man persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. (George Bernard Shaw)

Aside from the now-dated gender specificity of the above quote, it’s a gem. Being too reasonable and adaptive can lead to complacency and failure to push the envelope. Too much unreasonableness, however, and you’re not going to be successful — your expectations (like the above-mentioned Apple fans) will be so high that you’ll push all chances for success out the window. Note the contradiction of this saying with the previous one, however.

• Don’t make pie crust promises (easily made, easily broken). (Mary Poppins)

A classic way that IT often shoots itself in the foot is to overpromise, usually in response to fervent desires, needs, and hopes (or perhaps a little of Shaw’s “unreasonable man” behavior) on the part of stakeholders. Here’s one that I see time and again: “OK, we’ll get that feature into the very next release, just a week after launch,” usually offered up as a negotiating concession with stakeholders when there’s a late-breaking requirement or the need to descope things to hit a launch deadline. Of course, at that point the “very next release” hasn’t truly been planned yet, and there are probably dozens of features and fixes vying for inclusion, none of which have been soberly prioritized against one another by stakeholders. To promise anyone anything specific on feature inclusion, much less to state a specific short-term time frame, is almost a guaranteed way of disappointing people. There’s no substitute for planning, even amidst the kind of heated discussion that usually happens late in a project.

So, there’s a common theme to these (i.e., they all pertain to the negotiations process on projects), but there’s no single common “answer” that they collectively provide, other than to underscore that it’s important to look at things from both IT and shareholder perspectives: be unreasonable in pushing for progress, yet don’t let a desire for perfection get in the way of generally improving things; and for heaven’s sake, make sure you don’t overpromise. It’s a mixed world out there, and that will never change.

One habit I’ve picked up as a CTO/CIO, a habit that usually comes out in the many meetings that make up my work week, is that of leading through aphorism. Over the years, I’ve accumulated a number of pithy sayings that, like the proverbial picture being worth a thousand words, succinctly express key concepts and lessons that I’ve learned throughout my career. And I pass those on, sometimes repeatedly. My staff in more than a few of my jobs have started to call these sayings “Peterisms”, although I certainly can’t claim that I’ve invented most of them. So for a light-hearted end-of-year blog entry, in what may become a recurring flavor of post, here’s a few of them, with some discussion about what they connote in my personal Darmok-like management code.

• Don’t tell them no—tell them what it will take to say yes.

IT personnel are frequently in the position of having to say no — in response to an unrealistic expectation, a potential breach of security, a violation of established policy. I’ve learned to emphasize the other side of that, though: rather than simply saying “no” to the request, it’s useful to outline potential ways of getting to what the person wants. Sometimes, carefully handled, that’s a reductio ad absurbum approach, through which the requester realizes themselves that they’ve asked for something completely infeasible. But in any case, it’s a good self-discipline for IT itself (remember my strong view that IT is a service organization), in that it forces us to examine what measures might actually enable the achievement of the request. Would more funding help? More personnel? Stopping work on other high-priority projects? Working overtime (yet again)? In the end, actively looking for “ways to get to yes” helps everyone establish the company’s true priorities and understand the others’ point of view.

• When the only tool you have is a hammer, everything looks like a nail

We’re all subject to this kind of laziness and complacency: the tools we’ve gotten used to are the tools we tend to use in every situation possible. I worked with a FORTRAN programmer in the late ’80s (no joke) who was so fluent and capable in that arena that he resisted using all manner of new tools, from spreadsheets to scripting languages. At another company I worked for recently, the entire web site architecture (as well as nearly all tools) for a high-volume site was built on Tcl, which is not exactly leading-edge scalable technology. Clearly, every company needs to settle on standards and toolsets — my argument, however, is that you need to work actively on avoiding establishing a monoculture. I’ll have further posts in the new year about appropriately diversifying an organization’s tools.

• You can’t fit 8 pounds of manure into a five-pound bag

This one’s a personal favorite, perhaps the one I trot out most frequently. As you might guess, it argues for “right-sizing” IT’s efforts to what’s achievable with available resources. The trouble is, it’s fairly common for an idealistic and energetic corporate management group to want to push forward on multiple fronts simultaneously. Indeed, doing so may be necessary to maintain market competitiveness for the company’s offerings. Alas, it’s considerably easier to dream up and spawn a project than it is to actually bring that project to fruition. Executives should perhaps be called “idea-tives” instead, because we tend to minimize how long it takes to execute the many ideas we dream up. Meanwhile, we’ve moved on to the next big idea, forgetting that the wheels are still churning throughout the organization on executing our last big idea. And (see above), we don’t tend to want to hear “no.”

Again, as I’ve stated before, the most important role of management is the proper allocation of resources. Finite resources, that is, spread across many areas of demand. In essence, that allocation is a zero-sum game: when you add a project to the plate, you need to remove a project. Just as you do with planned expenditures when you have a fixed budget. Educating the entire organization on this basic, unavoidable fiscal-like project discipline is one of the major ongoing challenges (as in uphill battles) of the CTO/CIO.