I'm always a bit surprised when we treat "cost" as something binary. Successful people, in my experience, are those who take calculated risks and are right oft

I'm always a bit surprised when we treat "cost" as something binary. Successful people, in my experience, are those who take calculated risks and are right often enough to differentiate themselves. Software is no different. When faced with a YAGNI situation, you need to make a judgement call. There will be costs in building it now. Those costs might be less now vs later (sometimes just because the context is fresh). The cost may vary depending on how much work you do. There will also be "expected benefits". The estimated (judgement call) likelihood of actually needing it times the cost savings (future cost - current cost). Compare the expected benefits between projects and pick the one you expect to add the most value. As pointed out by others, this often means simply drawing the abstraction in the right spot to make future development easier. Even if future development never happens, it's likely you built a good abstraction that was well thought out. The cost is low (you had to frame the abstraction somewhere) and the expected benefits are high.