I was once told a story about a software company that existed in the '90s and worked, among other things, on a GUI library that was meant to be so deeply configurable and customizable as no other GUI library in the world.
If they had a slider being built, they wanted the slider to work not just linearly from value A to B, but they wanted the developers to be able to assign a function (not necessarily linear) to the slider, so that when the user moves the slider, the resulting value comes from the function.
And the same with any other control they wanted to built. There was so much complexity involved that the company had never actually shipped the library.
This example is on the high end spectrum of making a product configurable. Let's take a look at a simplified picture of the spectrum.
There is a limit on how much flexibility we can provide through adding on more and more configuration options. Somewhere there, on the verge of the no-go area we could picture some complex systems such as the big ERP systems or telecommunication systems. Everything we perceive as fairly usable, even if difficult, goes on the left from there. The forbidden area is where we don't want to be with our product.
- the complexity of how the product can be used increases beyond realistic boundaries. The users don't want to use the system, because it feels so complex, or they remain stuck with some fixed configuration and will never dare to change it.
- the complexity of testing that we have to do to make sure all the variants work correctly increases geometrically. The time it takes to execute the tests may get to an unacceptable level.
- the reasoning about [potential] bugs and customer raised issues becomes very difficult and time consuming
Some products and systems inherently have the tendency to employ complex configuration options just because they themselves are complex. So where does the unnecessary complexity (the bad cholesterol) comes from? One particular source of this may be not knowing the customer and customer needs well enough. Please consider this short conversation:
- I'm wondering whether we can leave it fixed, but I'm not sure if this fixed value would be OK for all the different customers that we have. How do you think?
- I'm not sure. We don't have any hard data about this and I guess some customers may want different values for this setting. I guess it'd be safer to make it configurable. You know, just in case.
- OK.
Sounds familiar?
That's very likely a decision process where the lack of knowledge or data about the customers urged the decision-makers to make one more step towards the unneeded complexity, "just in case they need it".
One of the key reasons the new configurations are foisted upon a product is that some of the stakeholders do not have enough understanding of i) product testing and ii) user experience. In good faith, a stakeholder may try to push for the addition of new config options, because, for example, the notion of "geometric test case explosion" is so remote to them.
An important part of Product Owner / Product Manager duties is to explain all of the consequences of expanding product configuration to the stakeholders and, if necessary, push back against unneeded or harmful complexity. There rarely anybody else who can skillfully do that.