3 ms·
The only exceptions are APIs and data serialization/storage. Your cost of change on these are huge, so better to eat some extra cost now to future proof.
by kstenerud 8y ago
The only exceptions are APIs and data serialization/storage. Your cost of change on these are huge, so better to eat some extra cost now to future proof.
- olavk 8y agoYeah, although there is a difference between planning for a specific future which may not arrive, and planning to make any future change less painful.
- mmt 8y agoI'm pretty sure the original rule recognizes no exceptions, and certainly not on something so broad as an entire category. It may be that much narrower exceptions could exist, but future-proofing sounds like it could simply be justified as a feature actually needed now, if not just good overall coding practice [1]. The danger of allowing such a broad exception is that it doesn't take a huge leap to imagine a situation where it's used as permission to do something like a custom implementation of ACID in the app backed by a NoSQL key-value store (or "sharded" MySQL, before NoSQL was a thing). [1] YAGNI isn't a standalone rule but one of many in the "XP" collection. Any one of them, out of context, in complete isolation, could just as (if not more) easily require a long list of caveats/exceptions to make sense in the general case.