[qznc]

When you design a system, you always have a tradeoff between flexibility and simplicity. Extreme flexibility means over-engineering and complexity. Simplicity means less flexibility, because of a lot assumptions are hard-coded. The best design is the one which hits the sweet spot: As simple as possible, as flexible as necessary. That requires knowing the future, though.

If you want to increase flexibility later, like "remove the constraint that a product could only ever belong to a single size group", it inherently means to hunt down all the places where this assumption has been hard-coded.

Should you err on the side of flexibility or simplicity? Simplicity means the assumption hunt is costly, but maybe you never need it (YAGNI). Err for flexibility, you pay the constant cost of dealing with the API complexity, but you surely avoid some costly assumption hunts.

Usually, startup prefer simplicity because they will pivot anyways. In contrast, enterprise prefers flexibility, so they can plan years ahead and things stay in the budget.

[alephnil]

> As simple as possible, as flexible as necessary. That requires knowing the future.

Knowing the future in this case should usually mean that you have requests for a feature from customers, but you don't have time to do it in this version. At least that is something I find useful as a rule of thumb. If that is not the case, you should really think twice before making it flexible rather than simple.

[nicholasjon]

> As simple as possible, as flexible as necessary.

That really resonates with me.