Yagni Exceptions

YouArentGonnaNeedIt and DoTheSimplestThingThatCouldPossiblyWork must both be balanced against BuildForTodayDesignForTomorrow and PlanAheadForReuse?.

---

The Extreme Weirdos say DoTheSimplestThingThatCouldPossiblyWork, meaning to pick, always, a simple solution over a more complex one, even if the more complex one will probably be needed later. They say YouArentGonnaNeedIt, meaning never to put in a piece of functionality you foresee, even if you're sure you will need it later. Are there exceptions to this rule? --Mythical Interlocutor

Well, yes, there are exceptions. But remember that your situation probably isn't one of them. It will almost certainly pay off to stick to simple solutions, stick to providing business value ASAP, and keep your code squeaky clean. Remember that when you are investing in the future, even when it's necessary, you really aren't investing in what's needed now.

So, exceptions:

If your DBA is one of those stick-in-the-mud types who won't change schema without a letter from the Chairman, and you're using a relational database to store your objects, it can be really hard to evolve. In that case, try these three strategies, in order:

1. Correct the DBA. Consider Extreme Prejudice. (not an XP technique.)
2. Have your own copy of the database, whose schema you can change whenever you want to, and schedule schema changes to the real database on a regular but slower basis.
3. Do more future planning, build bigger objects for the future, accepting that you will slow down your entire development to do so. Report your lack of progress making the problem visible.

If you have a large object database, migration can become a time-consuming problem. Try these:

1. Speed up migration by all possible means. Consider: creating collections of all the objects that need it, to avoid searching all instances; migrating with multiple processors; etc.
2. Add auxiliary objects to support new data values.
3. Leave undefined slots in key objects for future use.
4. Do more future planning, build bigger objects for the future, accepting that you will slow down your entire development to do so. Report your lack of progress making the problem visible.

Any other suggestions? -- RonJeffries

---

Yes. Remember that YouArentGonnaNeedIt and DoTheSimplestThingThatCouldPossiblyWork are there to stop developers volunteering FeaturesThatTheCustomerHasNotAskedFor?.

---

If as a developer you are really sure that the feature will be needed:

• get the customer to request it by writing the appropriate UserStory and then prioritizing it with your current work.
• If and only if the customer agrees and assigns the new feature the same priority and delivery date as your current work do you actually need it.
• Otherwise, YouArentGonnaNeedIt is still true so do not write it yet.

-- PeteMcBreen

Danger here: you must give them a fair estimate; you must be aware that "oh yeah sure" isn't really a request; you're working against the balancing aspects of separating customer-developer responsibility. Additionally, you can lead a horse to water but you can't make him accept that the network functionality he isn't asking for now is going to be a total pain in the ass to shoehorn in later. Offer concrete examples.

moved here from YouArentGonnaNeedIt

If only that were true. If we have learned nothing in a million years can we agree on the following: 1) Many examples can be created that disprove a simplistic theory. 2) All theories are, (generally speaking) simplistic. So... some 30ish years ago a couple the IP "gurus" are talking and decide that 3 digits ought to cover all the IP addresses "we will ever need."' Somebody quote me on this, "Shortsightedness is not an asset." TomLeylan It turns out that "SometimesYourGuessWasWrong!"

---

If you moderate any instance of YagNi with ZeroOneInfinityRule where applicable, most of these arguments disappear. (EG: If you can have more than one computer on the internet, why not support any number?) Also, YagNi AND ZeroOneInfinity are both subject to wrong interpretations. In my mind, the first one should have "...but make sure that if you're wrong, you have places to add it (EG, empty functions)," and the second applies to upper limits (see ZeroOneInfintyIsaUpperBound.)

---

moved here from YouArentGonnaNeedItOriginalPage?

TheyWriteTheRightStuff, but is the story of WhyTheShuttleIsLeftHanded an example of YAGNI?

---

YAGNI may not always be applicable when doing InformationOrientedSoftwareDevelopment? because

• If the information oriented software development is done correctly, it will be flexible enough to adjust to what is really needed, in theory.
• InformationOrientedProgrammingIsAlsoDesign

-- JonGrover

---

CategoryExtremeProgramming

---

Is TestFirst an exception to YAGNI?