As you, dear readers know, I have strong opinions on vestigial features in products. In the same way, I’m a strong believer in dumping and changing features that customers don’t care about: maintaining features that few people use is a night-mare and massive money-suck.
Somewhat counter-intutivly, then, I enjoyed this part of a longer quote from SalesForce.com CEO Marc Benioff:
Once we had the API really working well, then customers really started to hammer me on customization. They would say, ‘Why can’t I change this tab name, why can’t I change this field name, I want to be able to do this, and I want to be able to that.’ Well, [we would say] the problem is that the tab name is through the whole documentation. It’s in the singular, it’s in the plural. It’s not just in one language, it’s in twelve. And then customers would say, ‘Yeah. So what?’
I say it’s somewhat counter-intutive that I’d like that quote because it indicates a high-degree of extra features and customization. Programmers hate those two words. Benioff’s mock-response to the customer says why: whenever you change something, there’s a cascading effect of other stuff you have to change, not least of which is the docs.
So, a tiny change of a tab name entails a lot of work. But that’s only because the software vendor wants to maintain continuity in their software: they want all the parts of the software to “make sense” in relation to each other. One part of the software shouldn’t cause another part of the software to seem weird or funny.
Sidebar: Ad Continuity Attacks
As you might be thinking, or have lived through, this point is one of the best ways to waste hours discussing how to implement a feature. Since continuity can be highly judgmental, it’s a good arguing point. See security, usability, and performance for the other best ways to waste lots of time when talking about software.
“How much money does continuity make me?”
The point is, to avoid doing a change in software, we (the software makers) often say, “well, if we do that, it’ll have a cascading effect where this other thing won’t work, the docs won’t make sense, and all manner of other continuity problems will occur.”
While the above is an anecdote, I’d wager that in most cases, enterprise customers wouldn’t care about bad continuity: they’d rather have software that makes them more money than software that has good continuity. This type of thinking is part of what feeds the notion of good enough software.
Of course, things are a little different in consumer software. But then again, which one of Microsoft and Apple has the best continuity in their software?
(And check out the comments for some SalesForce.com backlash.)