I think "being sure we need it" is shorthand for a particular list of costs that apply to any new dependency and new way of doing things, such as:
- cost of people learning how two different ways of handling things work, and having to choose between them
- cost of the inevitable cases where the library's choices don't mesh with ours
- cost of the inevitable cases where our libraries have to be modified to work with the new one (for example, we would probably have to make sure KhanErrors and MultiErrors can be composed both ways nicely -- possibly to the point of wrapping the whole lib)
- maintenance cost if the library later goes unmaintained, or makes breaking changes we need to incorporate, or whatever
— ben kraft
Yagni originally is an acronym that stands for "You Aren't Gonna Need It". It is a mantra from ExtremeProgramming that's often used generally in agile software teams. It's a statement that some capability we presume our software needs in the future should not be built now because "you aren't gonna need 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. Yagni is only a viable strategy if the code is easy to change, so expending effort on refactoring isn't a violation of yagni because refactoring makes the code more malleable. Similar reasoning applies for practices like SelfTestingCode and ContinuousDelivery. These are enabling practices for evolutionary design, without them yagni turns from a beneficial practice into a curse. But if you do have a malleable code base, then yagni reinforces that flexibility. Yagni has the curious property that it is both enabled by and enables evolutionary design.
Yagni is not a justification for neglecting the health of your code base. Yagni requires (and enables) malleable code.
I also argue that yagni only applies when you introduce extra complexity now that you won't take advantage of until later. If you do something for a future need that doesn't actually increase the complexity of the software, then there's no reason to invoke yagni.