Flexibility is No Virtue

2012-10-17

Vice is a monster of so frightful mien, As to be hated needs but to be seen; Yet seen too oft, familiar with her face, We first endure, then pity, then embrace.
—Alexander Pope, Essay on Man

If I had a penny for every programmer that I’ve heard, proudly touting the flexibility of what they’ve built, I’d be a wealthy man. I might even be able to afford my teenagers’ car insurance. :-)

As a young coder, I took the implied excellence of flexibility for granted; after all, who wouldn’t want to be flexible?

Now I know better.

If your software can be installed and configured a hundred different ways, this is Not Good. It is a sign that you don’t know who your customer is, or what they want. If your programming language has nine separate functions that provide the same functionality, shame on its designers. If your UI presents users with oodles of choices and calls it a customer focus, go vomit into the nearest garbage can.

I can already hear the protests, so let me pause here to admit that my generalization isn’t true 100% of the time. The Department of Defense spent billions of dollars developing the Osprey, because it really did want Marines to be able to take off and land like a helicopter or a plane, according to changing circumstances. And the DOD was not crazy.

This post is not about that kind of flexibility.

It’s also not about the flexibility in construction that you address with modular designs. The set of objects you can build with legos is unbounded — flexible, if you will. But notice that the blocks themselves are not.

This post is about products that can be deployed and configured in a thousand permutations, when the reasons and the costs for that flexibility are not understood or acknowledged. That kind of flexibility pushes problem-solving onto the customer’s plate (and QA’s plate), and is usually laziness in disguise. Yet we tell ourselves it’s a virtue so often that we start to believe it.

Cement as a poster child

When you pour cement to make a driveway, you value the pliable nature of the material just long enough to get it to fit your form. Ninety minutes of flexibility must be followed by decades of perfect rigidity, or you’ll never buy from that cement maker again. You couldn’t care less that the cement you purchased could be made to fit the shape of your neighbor’s sidewalk, or of the basketball court at the park.

Think about that for a minute.

In the long run, does a customer value the ability of a “flexible” product to meet the needs of any configuration other than the one she needs? No! (It is possible that she will configure a single product in multiple ways on different hardware or at different points in time, but this is the exception that proves the rule. Even when reconfiguration is important, the customer will view it as a necessary evil that increases cost and bother — not as a delightful business enhancer.)

As with cement, once a customer gets things configured correctly, he is guaranteed to prefer “set it and forget it” to an experience where he can experience the wonders of your product’s flexibility over and over again.

The cost of flexibility

The MV-22 Osprey makes a great cautionary tale. It took much longer to test, and was far more expensive to develop, than originally expected.

Flexible software is no different.

But suppose, just suppose, we were perfect estimators, and we could tally up exactly how many dollars and hours we would spend on releasing something flexible… Suppose we did the analysis, even including a savvy assessment of opportunity cost, and decided it was worth it…

We still wouldn’t be counting the cost accurately.

Besides the cost of developing and testing the Osprey, and the cost of purchasing models as they roll off the assembly line, the Department of Defense incurs an ongoing cost to the Osprey’s users in terms of extra training time, more limited deployment theaters, less skill transfer for pilots and maintenance crews when they retire to civilian life, and so forth.

Again, flexible software is no different.

Rational self-interest and the invisible hand

If you want to sell into a varied market, you have to tolerate variety. Dev teams that make flexible products are attacking that problem, and they are behaving in a mostly rational fashion.

Does that sound like I’m contradicting myself?

I don’t think so. It all hinges on understanding whose interests are being served by flexibility.

Flexibility serves the self-interest of the ISV. In most cases, customers would be delighted if products shipped pre-configured for exactly their needs, with no flexibility at all. They’d gladly accept a pre-fitted driveway, delivered by an invisible hand.

In other words, flexibility in a product’s configuration is a necessary evil.

If it’s necessary at all…

Theoretically, products could ship with smart defaults (so they’d require little tweaking), and could adjust themselves to unique needs with little effort on the part of customers. In some cases, they could even make these changes automatically and instantaneously, on deployment. Think about how much less doc we’d have to write, and how much less support we’d have to provide, if we didn’t buy into the flexibility approach…

I know I’m being idealistic. But it seems to me that we should acknowledge who’s benefitting from flexibility, and what it’s costing. We should make easy and correct fit, rather than flexibility, the ideal for our customers, and do what we can to achieve it. We may always be stuck making things flexible for our own internal purposes, but that should be our problem, not the customer’s.

Action Item

Study the "Swiss Army Knife" and "Cover Your Assets" antipatterns. These antipatterns are often associated with an incorrect admiration for flexibility. Look for places in your world where these antipatterns are used.

Comments

The Power of Simplicity « Codecraft, 2013-02-15:

[...] And all the planning that built those features? They’re symptoms of a problem, not solutions. Nobody really wants a shopping cart framework with 10,000 configuration options; they want to sell in a way that delights and engages customers. (Okay, I guess some software [...]
David H, 2015-09-09:

Wow you hit on another hot-button topic for me. Super-configurable flexibility really benefits most the ISV salesperson who gets paid when the deal is signed, not when the customer is happy nor when the company makes a profit. It's about attempting (vainly) to be all things to everyone. "It is a sign that you don’t know who your customer is, or what they want." -> Nailed it.
Daniel Hardman, 2015-09-22:

The more time goes by, the more I see this phenomenon everywhere. I don't think it's necessarily wrong to *start out* building in a lot of configurability; we might need it while we learn what's the right set of tradeoffs in the early days of our products. But once we have some experience in the field, we will eliminate some of the configuration options, in favor of "hardened" features. By then we should know that "give" in those places is counterproductive.
David H, 2015-09-23:

Have you ever seen configuration options removed from a product in real life? Maybe it can be done. I think it would help if it was explicitly stated up front, internally and externally "this product is in Beta and some configuration options will be removed in the future as we gain experience", or something to that effect.
Daniel Hardman, 2015-09-23:

>>Have you ever seen configuration options removed @David: it's a very astute question. The short answer is: "almost never". But at least I can hedge with "almost"... :-) You've made some wheels turn in my head about why it should be so hard to eliminated config. I'm pondering...