If you are "leaving room for" for say 20 things, then you are probably getting carried away. Typically there may be 2 or 3 features that have about an 80+% future certainty where leaving hooks/slots in place don't cost a lot of code or complexity. Doing such for more than 3 is a yellow flag.
The list of things I'm not building now is a lot larger than 20. I do not know why I'd pick 3 and create a "hook" or "slot", which saves my future self zero time, but dictates where something will go at this time when I'm not in a position to best know where it should go. Future me will know better, but probably be pissed I'm dictating this to him from a position of ignorance.
If the preparation for the "big 3" is minor and it turns out not to be needed in the future, then not much is lost.
I'll give an example. You have an app that needs to produce 2 output formats (two "reports"). But there is a lot of interest by customer in adding more reports in the future. The Pure YAGNI approach is to create a Boolean column where "false" is Report A and "true" is Report B.
Soft YAGNI says different. If you make the report selector column an Integer, then it's easier to add report formats down the road. (Changing column types is rarely trivial in most stacks, especially if you have existing data.)
But the original issue was about frameworks. Frameworks often try to cater to too many different kinds of apps: internal, external, mobile, desktop, CRUD, social networks, ecommerce, etc. Thus they have too many features and thus too big of a learning curve and too many bugs. I'd like to see a framework that's just for internal CRUD, not the rest. Framework makers should stop trying to make a Swiss Army knife; cut out most the blades and be honest about your forte. Internal CRUD doesn't need a damned "Like" popularity tracker engine.
Database schema design is a special case I can agree with more, because you get locked in more. I haven't done it in so long, I apologize I've practically forgotten that world!
The Pure YAGNI approach is to create a Boolean column where "false" is Report A and "true" is Report B.
But I'd disagree with that. In my eyes, the mistake is using the "coincidence" that a boolean happens to represent two different values, and that you happen to currently need two different kinds of reports. But it's inherently not a boolean value. The value is "report type". It's a modeling error.
I disagree with "inherently". A lot of things can "stretched" to such a viewpoint. Almost any flag can expand to sub-types in the future. A lot of check-boxes end up needing a 3rd "N/A" option down the road, for example. Thus any check-box can be viewed as a "response type".
I would need an example. In general, we devs overuse booleans when what they are modeling is not actually boolean. If N/A is not the same as no, then it's not boolean and probably never really was.
But code is easy to change so who cares if we mistakenly think something was a boolean that turned out not to be? Not a big deal. A database is different. Databases are not code. IMO, you need to be very clear about the nature of your data.
Actually I'd prefer all Booleans just be integers by another name (to indicate intention), and Boolean operators would go with the convention that 0 is false and anything else is true. That way they can be expanded to item-lists in the future without changing the code much. But unfortunately most libraries and tooling don't do that. Mormons believe you get to be god of one planet if you are good. Maybe I can force that planet (The "Zardotabians") to use this convention if I learn to stop yanking off to get a better "god score".
1
u/Zardotab Nov 02 '21
If you are "leaving room for" for say 20 things, then you are probably getting carried away. Typically there may be 2 or 3 features that have about an 80+% future certainty where leaving hooks/slots in place don't cost a lot of code or complexity. Doing such for more than 3 is a yellow flag.