Pretty bad advice. The good thing about YAGNI is that you can treat it as dogma and you'll be fine. Sometimes you'll be wrong, but it's always going to be easy

Pretty bad advice. The good thing about YAGNI is that you can treat it as dogma and you'll be fine. Sometimes you'll be wrong, but it's always going to be easy to recover from mistakes. Doesn't matter how much experience you have, YAGNI is always a net positive. Author's recommendations on the other hand require a lot of caution. Take logging for example. It's quite a slippery slope: how much logging is enough? Just a few INFO statements here and there? Or multiple levels? Centralized logging? Structured logging? Alerts? What about retention? GDPR? Good logging requires thinking. You can always add more logging when necessary. But you cannot unadd the logging noise you accidentally introduced (well technically you can, but noone does it). Zero-one-many: if 1% of your users needs two addresses, then 0.01% will need more than two. You can just say no to those. You avoided one level of abstraction by slightly upsetting 0.01% of your users. In most cases that's a good thing: unlike MAU, complexity piles up and grows non-linearly. Versioning: in most cases if you don't control both ends of the API, versioning is a requirement, YAGNI doesn't apply here. And when you do, versioning is a huge process change that rarely pays off.