Every professional software deliverer has the responsibility to consider the implications of what they’re doing and when.
Defensive programming is one example where this comes up.
This post is really about how we balance the relative costs of doing or not doing something at a particular point in time. The bad news is that YAGNI is a little more complicated than the immediate “cost to build” the unnecessary feature you’ve described.
What if your customer had another, much more valuable feature for you in the meantime? You might of incurred a “cost of delay” in not giving the customer that other new feature quickly.
In introducing the presumptive feature now you’ve also incurred a “cost to carry” that code around in your codebase. You’re going have to ask yourself and others to read it and understand it, to store it and version control it.
When you do eventually encounter the breaking scenario you’ve described in the future you will incur a “cost to repair” that feature. That cost might be greater than it would be now if your code changes a great deal in the meantime.
So YAGNI absolutely should not apply to refactoring that allows you to change your code easily. A clean codebase is the ultimate defence kit against these costs.
I really like your thought process on this. Though I just want to make sure I understand you correctly: Are you saying that YAGNI is not a reasonable argument against clean code techniques like the never/exhaustiveness checking I showed above?
If so, I agree with you because it helps to keep the codebase clean, and as you said:
A clean codebase is the ultimate defence kit against these costs.
“Yagni only applies to capabilities built into the software to support a presumptive feature, it does not apply to effort to make the software easier to modify.”
Every professional software deliverer has the responsibility to consider the implications of what they’re doing and when.
Defensive programming is one example where this comes up.
This post is really about how we balance the relative costs of doing or not doing something at a particular point in time. The bad news is that YAGNI is a little more complicated than the immediate “cost to build” the unnecessary feature you’ve described.
What if your customer had another, much more valuable feature for you in the meantime? You might of incurred a “cost of delay” in not giving the customer that other new feature quickly.
In introducing the presumptive feature now you’ve also incurred a “cost to carry” that code around in your codebase. You’re going have to ask yourself and others to read it and understand it, to store it and version control it.
When you do eventually encounter the breaking scenario you’ve described in the future you will incur a “cost to repair” that feature. That cost might be greater than it would be now if your code changes a great deal in the meantime.
So YAGNI absolutely should not apply to refactoring that allows you to change your code easily. A clean codebase is the ultimate defence kit against these costs.
I really like your thought process on this. Though I just want to make sure I understand you correctly: Are you saying that YAGNI is not a reasonable argument against clean code techniques like the never/exhaustiveness checking I showed above?
If so, I agree with you because it helps to keep the codebase clean, and as you said:
Well put. :)
Yes. As Martin Fowler puts it:
“Yagni only applies to capabilities built into the software to support a presumptive feature, it does not apply to effort to make the software easier to modify.”
Wow. That’s an incredible quote. Thank you so much for making me aware of it. :)
Here’s the reference along with a discussion of the cost considerations behind YAGNI
martinfowler.com/bliki/Yagni.html