Less (Complexity) Is More (Flexibility)

Whenever I consider purchasing something for myself, I always think about the complexity it would add to my life. Buying more stuff can lead to short-term gratification, but also to long-term maintenance headaches.

The same can be said of information technology. In fact, complexity is pervasive in our industry.

A few years ago, I had dinner with some Microsoft executives and opined that the company should produce secure, reliable products with fewer features and lower cost. Who really wants an outline reformatted by Word's Outline Wizard? Why must we endure patches necessitated by too much code supporting too many seldom-used features? They responded that most people use 95% of the features in Office, adding that the average user wants new features over everything else. To make their point, they released Vista.

I have chosen to do battle with complexity. But there are several ways that complexity can crop up.

Every commercial software product we buy adds to the interfaces of our systems. All those interfaces make recovery from downtime more difficult and increase support costs. Recently, a clinician commented that one of our new purchases surprised her because it added complexity, fractured workflow and inconvenienced many users for the benefit of a few. That's what I want to avoid.

One tactic is to use the fewest vendors possible -- one or two storage vendors, one desktop vendor, one network vendor and just a few app vendors. The more vendors, the greater the integration effort, the more burdensome the maintenance, and the higher the cost.

When we build software, users often plead for all sorts of bells and whistles. But for each new custom feature, we add maintenance costs, training requirements and potential bugs that could compromise stability and reliability. I've been involved in many development projects that became so complex that the software had to be rewritten to ensure usability. So my goal with in-house apps is to keep them simple. That also makes it easier to use them across the enterprise.

It's tempting to customize commercial packages as a way to get buy-in from stakeholders. Yet, in my decade as a CIO, I've found that stakeholders come and go, and when they leave, all the customizations they designed are often retired. In fact, many upgrade projects include retiring all customizations. Customization just adds complexity. And I've found that when users really understand customization's implications for workflow, cost and future upgrades, they're not so enthusiastic.

Related:
1 2 Page 1
Page 1 of 2
7 inconvenient truths about the hybrid work trend
Shop Tech Products at Amazon