06 August 2007


i'm a big believer in the yagni practice, preferring to avoid work that i don't have to do now (laziness) and to avoid refactoring baggage that arises from implementing early. what i don't appreciate is the playing of the yagni card in order to stop discussion. i've been hearing it lately applied to ideas rather than actual coding. am i the only one that sees a slippery slope here? is it kosher to drop the Y-bomb if you simply don't agree with the ideas presented?

i tend to think that stopping discussion so abruptly (or even trying to) will stifle participation in the future, canceling any benefit of supposedly increased communication on an XP team.


  1. I imagine that for some people, YAGNI merely reduces down to "saving time" in their mind. So if you're having a discussion about something, and they feel that they're wasting time on the discussion itself, then they'll play the YAGNI card. Improperly, of course. But in their mental shorthand, it'll make perfect sense to them.

    Also bear in mind that coders are not known for their exceptional social skills, and pointless conversations (from their point of view) are the ultimate waste of time and effort.

    Just explaining the pheomenon, not making excuses for it.

  2. I agree that YAGNI was been widely abused. I've seen it abused as early as 2002, and there have been many messages on the extremeprogramming Yahoo group about it, too.

    The original context was to try to prevent someone from spending serious time (on the order of days or weeks) extracting a framework that was not asked for by the customer, and which would likely turn out to be a completely unnecessary complication, when instead, thanks to unit tests and refactoring, it would actually cost no more time to factor it out later, when the need for it became clear.

    Since then, there's been a lot of semantic diffusion about the term. I think it's too much fun to say. "YAGNI!" BAM! Direction changes. I second Scavinger's comments.

    I also think YAGNI is mostly for Agile beginners, although even experts may sometimes need a gentle reminder. More specifically, if you really are confident that unit tests and refactoring are *not* going to save you from a tragic descent into chaotic spaghetti hell, then it makes perfect sense to back off and do some extra careful design and preparation and maybe even create a fancy framework up front. And that's why I think YAGNI is mostly for beginners: because with experience with unit tests and refactoring, it's hard to lack that confidence. The software development field, such as it is, trains you to lack that confidence (and to lack those unit tests, too). You are trained to program in fear. If it ain't broke, don't fix it. Even if you logically know you are programming with a safety net, you can still feel the fear.

    I think we can do one of two things, not necessarily mutually exclusive: We can try to preserve the word "YAGNI", and create a new idiom to call out "YAGNI violations". Or we can ban the term altogether, and favor softer, more understandable phrases, depending on context, such as:

    * "Justify what you're doing."
    * "Let's ask the customer."
    * "Let's not program in fear."
    * "We have unit tests, you know!"