There is an argument I hear on almost every project, just in different costumes. The client says: "Let's make the system flexible so we can configure anything later." The programmer says: "Let's build a universal solution, it might come in handy." And everyone nods, because flexibility sounds like an unconditional good. Who would object to a system that can do more?
I would. Not always, but very often. Because flexibility is not free. Every "universal" solution adds a layer of abstraction that complicates life for developers, users and eventually the budget. Too often we sacrifice simplicity to an imaginary flexibility "for the future", a future that never comes.
A Swiss army knife with a hundred blades
Imagine a Swiss army knife with a hundred blades: saws, screwdrivers, openers, a magnifier, a toothpick, a corkscrew, scissors and eighty more attachments of unknown purpose. It is heavy, awkward to hold, and to find the right blade you have to open half of them. And when you need to drive a nail, it turns out a hammer is better after all. Simple, heavy, with one function. But it has mastered that function perfectly.
Software systems that try to do everything are like that knife. A form builder that can build any form, yet putting together a simple questionnaire takes an hour. A CRM that can be configured for any business, but it takes a dedicated specialist half a year to do so. A rules engine where business logic is defined in the interface, and later nobody can understand why an order went to the wrong manager.
Hence a simple observation: universal systems often lose to specialised ones. Not because they are badly made, but because every user pays for every "configure anything" option every day, even if he never needs it.
The price of flexibility
How exactly is the price paid? First, in development. A flexible solution is always more complex than a simple one. Instead of writing "if the order exceeds amount X, give a discount", you have to build a rules mechanism, an interface for configuring rules, storage, validation, conflict handling between rules. The work multiplies.
Second, in maintenance. The more behaviours a system has, the more combinations need testing and the more places a bug can hide. One setting combined with another produces a result nobody thought of.
Third, in understanding. A new employee can understand a simple system in a day. A flexible system configured five different times by five different administrators cannot be fully understood by anyone. And when something breaks, archaeology begins.
That is why I call excessive flexibility technical debt that you take out at huge interest right now. Ordinary technical debt postpones work until later. Excessive flexibility, on the contrary, makes you pay immediately for capabilities that may never be needed.
The principle: flexibility where things change
Does this mean flexibility is not needed at all? Of course not. The question is where exactly it is needed. The rule I follow: do not make the system more flexible than the current business plan requires. Flexibility is needed where changes really happen often, and where you have already seen those changes rather than imagined them.
For example, if a company's prices change every week and marketing keeps launching new promotions, a mechanism for configuring discounts will pay off. But if the order structure has not changed for five years, there is no need to make it configurable "just in case". If it is ever needed, you will rework it. That will be cheaper than maintaining flexibility nobody uses for years.
Programmers have a good rule for this with a funny name, YAGNI: "you aren't gonna need it". Do not build what might be useful in the future. Build what is needed now, but in a way that is easy to change. The last part matters: simplicity does not mean sloppiness. Simple, clean, understandable code is exactly what is easiest to change when the real need arrives.
What to sacrifice
Every system is a compromise. You cannot have maximum flexibility, maximum simplicity, maximum speed and minimum price at the same time. Something has to be sacrificed, and it is important to make that choice consciously instead of letting it happen by itself.
My usual advice to clients: sacrifice flexibility where the business is stable and keep it where the business is alive. Sacrifice universality so that the main scenario works perfectly. Let the system do one main thing very well rather than a hundred things mediocrely. If a hundred-and-first thing is needed later, add it when it becomes clear what exactly it should be.
How we solve it
At Ingello we found an interesting way out of this argument. Instead of building one flexible system for every case, we made the process of building systems flexible. Fractal generates a simple system for each client, tailored to his processes, from a formal description. If the processes change, the description changes and the system is regenerated. The user gets a hammer, not a Swiss army knife. And the flexibility lives at the generator level, where we pay for it once, instead of the client paying every day.
If you are choosing or ordering a system right now, ask one question about every "flexible" feature: what exactly are we going to change, and how often did that happen over the past year? If the answer is "nothing yet, but what if", it is a candidate for sacrifice. Your users will have an easier time, and so will your budget.
