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.