Using YAGNI Responsibly

DISCLAIMER: For the agilists reading this post, there is nothing new here. I just hear a lot of misconceptions around terms like YAGNI and wanted to provide my own take on things.

YAGNI is an acronym for "you ain’t gonna need it". You often hear it bandied about agile shops. One developer suggests an over-architected solution and the other cries out YAGNI. For example:

Dev#1: We can transfer that file using BizTalk!

Dev#2: YAGNI. We can download it using HttpWebRequest.

I’m not knocking BizTalk here. My point is that if all you need to do is transfer a file from point A to point B, BizTalk is an awfully complicated and expensive way to do it.

Many agile critics see YAGNI as an excuse for developers to do stupid things. Critics claim that YAGNI encourages developers to hard-code connection strings and other silliness. "In development, you’re not going to need to change the connection string. So by the YAGNI principle, you should hard-code your connection strings. Isn’t agile stupid?" YAGNI is a principle like any other and should be applied intelligently. It’s about keeping simple problems simple. It’s about the right tools for the right job – don’t try to drive a finishing nail with a sledgehammer. Too often we as an industry implement "enterprise solutions" to solve otherwise trivial problems.

YAGNI isn’t an excuse to be sloppy with your architecture. If you’re building the next hot social bookmarking application, it better scale. You better design with caching, distribution, load-balancing, etc. in mind. I would want some architectural spikes demonstrating acceptable performance at high user loads. Similarly if you’re developing an internal application to be used by 10 users, I would bet that you don’t need the complexity of a load-balanced web farm, distributed middle-tier cache infrastructure, and a clustered database. YAGNI is about choosing the appropriate amount of complexity for the problem at hand.

YAGNI is about building software at the last responsible moment. The "responsible" part is key. You can’t slap an asynchronous architecture in after the fact. You need to design that in up front. At the same time you should avoid speculative generalization. Solve the problems at hand with a responsible eye toward future requirements. Keep yourself lean and nimble enough to respond to those future requirements, but don’t build them "just in case we need them". What you will need in the future seldom has any resemblance to what you might build now. Even worse, unused features add complexity and rigidity to a codebase. You’re actually worse off than if you didn’t have those features at all! Keeping your architecture simple, lean, and nimble requires a lot of discipline.

So next time someone suggests using a SOA-based ESB to integrate the disparate workflows in the document lifecycle, ask yourself whether a wiki couldn’t work just as well. :^)

About James Kovacs

James Kovacs is a Technical Evangelist for JetBrains. He is passionate in sharing his knowledge about OO, SOLID, TDD/BDD, testing, object-relational mapping, dependency injection, refactoring, continuous integration, and related techniques. He blogs on as well as his own blog, is a technical contributor for Pluralsight, writes articles for MSDN Magazine and CoDe Magazine, and is a frequent speaker at conferences and user groups. He is the creator of psake, a PowerShell-based build automation tool, intended to save developers from XML Hell. James is the Ruby Track Chair for DevTeach, one of Canada’s largest independent developer conferences. He received his Bachelors degree from the University of Toronto and his Masters degree from Harvard University.
This entry was posted in Agile. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • szahn

    YAGNI works best against enterprise business savy Java developers who want to wrap everything around a Java bean and make it serialization compliant. It’s best to stick with POJOs and lightweight serialization libraries instead of relying on JAXB, in my opinion.

  • kyaw kyaw naing discusses 3 types of YAGNI, relating them to technical debt of software development.

  • Troy DeMonbreun

    YAGNI is another concept often pushed around (or interpreted) as prescriptive advice, when in fact its success as a principle is heavily driven by the brain that applies the principle. The quote “should be applied intelligently” is indicative of how open for interpretation YAGNI is.

    As much as I wish the principle of YAGNI’s value was (mostly) prescriptive, such as “The Principles of OOD” — — , to me, its true value is as a mnemonic (a memory aid) and as a ubiqutious term within this industry.

    Even given the (seemingly) most popular and potentially prescriptive interpretation of YAGNI:

    “building software at the last responsible moment”

    … the phrase “last responsible” is wildly open for interpretation.

    I personally love the term YAGNI, and use it quite often, but while always reminding myself that it is not a prescriptive principle, and trying to use it to describe, for instance, my choice between architectures, rather than to instruct.

    Regarding another (IMO) prescriptive development item, TDD, I have a similar opinion:

  • Chris Brandsma

    Never underestimate the human potential to take a principle and blow it all out of proportion.
    “Principle xyz does not work in edge case abc, therefore it is invalid” <- this happens all too often.