Does YAGNI Mean You Ignore The Obvious

StupidYou’ve probably heard of the YAGNI principle, it stands for (You Ain’t Gonna Need It). Essentially it is meant as a mantra for developers to prevent us from anticipating functionality and building things before we know that they are actually necessary. You can think of it as an Agile principle or an unspoken (or sometimes vociferously spoken :)) rule if you like. Regardless, it can sometimes be a good idea to keep this principle in mind and measure much of what you do as a developer against it to make sure you’re not building a ‘mountain’ when a ‘mole hill’ will do just fine.

I like the idea of YAGNI and often try to apply it to what I do, but just like any principle that has been around for a while I have seen the message (or the idea behind the principle) be diluted to the point where some people start to use it without thinking and without understanding what it is all about.

Applying YAGNI Without Thinking

You know you’re applying YAGNI without thinking when it becomes the first and only yardstick for anything you do as a software developer. Implement a pattern? No way – YAGNI, a simple loop will do. Use a utility library? What for – YAGNI, it’s just one simple method, we can roll our own. How about building in more automation around our deployment process? Bah – YAGNI, we only do this once every 3 months, we can do without.

Don’t get me wrong I am not advocating always using patterns, or libraries, or automating without thought. What I am trying to say is, you can’t unilaterally apply YAGNI to everything without considering the larger context. If I do use a pattern here, will it make my code more readable, maintainable, testable, if the answer is yes then perhaps the pattern is a good idea. The point is, YAGNI in and of itself is not an objective it is just a practice, a tool. No matter what task you do you should always be aiming to make the system easier to understand and easier to use, more testable and maintainable, cleaner and more robust. If that means writing a little bit more code and putting in a little bit more thought, then YAGNI will just have to deal with it.

The Ideas Behind YAGNI

To give it even more context, applying YAGNI to everything you do is a recipe for a dish of spaghetti code. In my opinion the two main ideas you need to consider before reaching for the YAGNI stick are:

  • granularity
  • balance

Granularity

It makes a lot more sense to me to apply YAGNI to much larger concerns. Let’s make our application scalable to 1000 requests per second. Whoa, YAGNI – it is only ever gonna be used internally and there are only 100 users, not necessary. We as developers tend to sometimes let our love of playing with cool technology run away with us and end up using a proverbial bazooka to clobber a fly. YAGNI can help us avoid this, but it is only really relevant when we are talking about things that can take significant time, money or work. I am referring to coarse-grained concerns – major features, changing project direction, radical technology changes. If you’re dealing with any of those or similar than by any means apply YAGNI and see if it still makes sense, otherwise there are perhaps other practices that can take precedence.

Balance

You have to balance the YAGNI mentality against reality. You often CAN anticipate which way the project is likely to go in the near future and it might make sense to build particular things now to cater for this. You may have capacity now but will not necessarily have it later. You may have some expertise within your team at the moment that will not be available down the track. These things can weigh in against YAGNI. And when we are talking about finer grained features (i.e. the actual code and low level design of the system), then the *abilities should always take precedence, maintainability, testability, usability, readability etc.

The Agile Practice Stupidity Threshold

No matter what practice you use you should always understand the implications behind it and in what context the practice is best applied. For example, TDD is a great practice and you can use it to evolve better designs through writing the tests first. However, would you ever use TDD to evolve attribute readers or writers – of course not! More than that, there is a certain level of code that is just too simple to require being evolved through TDD, there is simply no need. But, if you use TDD without thinking you can find yourself doing exactly that, which would just be stupid and a bad use of TDD.

Every practice you use, including TDD and YAGNI has a certain threshold which I call the stupidity threshold. While you’re using the practice as a tool giving due consideration to all other concerns, you’re fine. But, as soon as the use of a particular practice becomes an objective in and of itself, you have crossed the practice stupidity threshold and will find yourself in trouble eventually.

Image by hiddedevries

  • Pingback: Dew Drop – August 25, 2009 | Alvin Ashcraft's Morning Dew

  • http://cubeantics.com Robert

    I agree; principles, practices, methodologies, etc. are only good for helping you within their specific scope. As soon as you try and retro-fit a practice to a problem that doesn’t fit, you can end up failing. Likewise, if you only learn and subscribe to a specific methodology and follow it blindly (just like YAGNI) then you rob yourself of the ability to solve problems creatively and effectively. I think the best approach is to jam your brain full of this kind of good/helpful knowledge and learn to apply it where necessary and ignore it when it has no business influencing your project.

    • http://www.skorks.com Alan Skorkin

      I completely agree (it’s like you read my mind :)). You have to supply yourself with as many tools as you can and then it is just a matter of using the right tool for the right job. The only thing to guard against is finding a favorite tool and using it for everything (the everything is a nail mentality).

  • Pingback: The Stupidity Threshold | Thought Clusters

  • Murat Ozgur KAYMAKCI

    very good point and very good article. YAGNI is like a knife, if you don’t use it correctly, you can cut yourself :)

  • Pingback: YAGNI Prensibinin Püf Noktaları | Bulutlararası

  • Kris Sandberg

    I agree, too. But I think your point rather applies to KISS than YAGNI.

    • http://www.skorks.com Alan Skorkin

      It certainly does apply to KISS, I believe it applies to both equally well.

  • Jason Baker

    Interesting post. I agree 100%.

    It’s interesting that I just now stumbled upon this post, because I just got done writing a post with a somewhat complimentary point of view: http://jasonsupdates.posterous.com/the-rise-of-sydni-or-yagni-is-only-about-prob

    • http://www.skorks.com Alan Skorkin

      Just checked out your post you provide a very sensible analysis, you’re right definitely complementary :).

  • Pingback: Finite State Machines in Game Development | Ext JS, Flex, and Flash Consultant – Jesse Warden

  • Pingback: » Finite State Machines in Game Development iOS Gaming