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 short anecdotal example: I visited my company’s colocation facility a few months after I took on the role of their first CTO. I was immediately horrified, and realized that I should have made the trip much sooner. Cables dangled everywhere around the cluttered cage, and often went nowhere; systems were powered up but unconnected to anything; other systems were unlabeled and unknown as to function or importance. Systems that I knew for certain were no longer operational in terms of our software architecture were still powered up, blinking away fiercely, mysteriously doing something. One could easily see how an overwhelmed, undercompetent staff might increasingly adopt the “if it ain’t broke, don’t fix it” mentality, just to save their skins and keep the wolves at bay.
As with so many things, that situation represented a management failure too. It reflected a willingness, whether explicit or implicit, to live on borrowed time, hoping to stave off as long as possible the certain-to-come outage that would then take much longer to resolve. It showed a willingness to tolerate unnecessary inefficiency and risk. It embodied an ongoing refusal to insist on (and prioritize) the necessary hard work to keep the clutter out of the equation.
On the software development side, the philosophy of “if it ain’t broke, don’t fix it” allows similar cruft to accumulate in software. Elements that should be eliminated or refactored as architectures have expanded over time simply get ignored and retained. Again, cables go everywhere and nowhere, metaphorically; it’s just a lot less visible than it is in a server cage. The risks entered into and the productivity drag caused by these shoddy practices build up a sort of soggy mulch pile, over time, that essentially freezes a dev group in its tracks.
So don’t get too cavalier about changing things (I’m also a firm believer in change control), but also don’t succumb to the complacency reflected in this aphorism.
- A camel is a horse designed by a committee
For information technology, the usefulness of insisting on the primacy of the individual, as an approach to making key decisions on systems-in-the-large, actually runs counter to my practical experience of what works. An individual operating in a vacuum, even if extremely brilliant, informed, and motivated, tends to have occasional or frequent biases, tunnel vision, and pride of ownership. He misses errors and issues that the scrutiny of multiple eyeballs, not to mention the careful discussion of pros and cons, can easily catch.
An example of the usefulness of committees is the Project Portfolio Management (PPM) process I’ve described frequently here on this blog. Having a sole individual, even the CEO, decide on project inclusion simply isn’t viable over the long run in many corporate cultures–it creates classic problems of lack of buy-in and participation, for example. On the other hand, instituting a suitably chartered and well-facilitated steering committee, composed of senior individuals from the major business areas of the company, forces everyone to put on their “big company hat” as they consider priorities, rather than doggedly insisting on their own department’s parochial perspective. When that’s done well, everyone moves forward with a common understanding and solid commitment, one that’s much less likely when there’s an on-high fiat from a single person.
As for software design? Well, Wikipedia’s article on design by committee claims that “Often, when software is designed by a committee, the original motivation, specifications and technical criteria take a backseat and poor choices may be made merely to appease the egos of several individual committee members.” That can admittedly occur, but I’ve also seen poor software designed by talented individuals, who can’t understand that others may not find particular interface elements or features to be as intuitive as they do. Committee involvement in design is no panacea for that problem, but there’s also no reason to eliminate the usefulness of multiple sources of feedback. As with all things, balance is key. Don’t just adopt a philosophy of “consensus” no matter what. As with a PPM steering committee, you should put effort into designing an effective committee and process, and allow for quick “tie-breaking” authority and action as needed.
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.