Martin Fowler, author and consultant at Thoughtworks, describes yagni practice, why its is important and the costs of building presumptive features, in his recent blog. Yagni is an acronym that stands for "You Aren't Gonna Need It". It is an Extreme Programming (XP) practice which states a programmer should not add functionality until deemed necessary.
XP co-founder Ron Jeffries says that:
Always implement things when you actually need them, never when you just foresee that you need them.
As per Cunningham & Cunningham wiki:
Even if you are totally sure that you will need a feature later on, don't implement it now. Usually, it will turn out either you don't need it after all, or what you actually need is quite different from what you foresaw needing earlier. There are two main reasons to practice yagni:
- You save time, because you avoid writing code that you turn out not to need.
- Your code is better, because you avoid polluting it with 'guesses' that turn out to be more or less wrong but stick around anyway.
Martin says that when we think of a presumptive feature, it's likely that we will be wrong. In this case, an obvious cost of the presumptive feature is the cost of build i.e. all the effort spent on analyzing, programming, and testing this now useless feature. He says that if we were correct in understanding our needs. Even in this happy case, building the presumptive feature incurs two serious costs. The first cost is the cost of delayed value and second is cost of carry. He explains these costs as:
Cost of delay: Teams can build some other feature which can generate revenue.
Cost of carry: The code for the presumptive feature adds some complexity to the software, this complexity makes it harder to modify and debug that software, thus increasing the cost of other features. This impacts the additional cost to build the feature, plus the additional cost of delay since it look longer to put it into production.
Martin mentions that there is an additional cost of repair in case of right feature built wrong.
Development teams are always learning, both about their users and about their code base. They learn about the tools they're using and these tools go through regular upgrades. They also learn about how their code works together. All this means that you often realize that a feature coded six months ago wasn't done the way you now realize it should be done. In that case you have accumulated technical debt and have to consider the cost of repair for that feature or the on-going costs of working around its difficulties.
Martin says that yagni applies to large features as well as with small things. A lot of small yagni decisions add up to significant reductions in complexity to a code base, while speeding up delivery of features that are needed more urgently.
Community comments
The original article
by Martin Fowler,
Re: The original article
by savita pahuja,
don't understand. ..
by Erik Gollot,
Re: don't understand. ..
by Gyula Csom,
Uh huh.
by Jonathan Allen,
Re: Uh huh.
by Luis Espinal,
Re: Uh huh.
by Johnny FromCanada,
Re: Uh huh.
by Luis Espinal,
Uh huh.
by Jonathan Allen,
Re: Uh huh.
by Abhishek Sharma,
Re: Uh huh.
by Jonathan Allen,
The original article
by Martin Fowler,
Your message is awaiting moderation. Thank you for participating in the discussion.
In case anyone is interested, the original article is at martinfowler.com/bliki/Yagni.html. (As I write this, there is no link to the original in the InfoQ post.)
Re: The original article
by savita pahuja,
Your message is awaiting moderation. Thank you for participating in the discussion.
Apology.. Updated with the original article link.
Thanks
don't understand. ..
by Erik Gollot,
Your message is awaiting moderation. Thank you for participating in the discussion.
In which world are you living ?
What does it means creating features that you do not need ?
The developer, the king of Agile, is not alone, he's just one piece of the puzzle. He works with business analysts that work themselves with the business. ..and they know what is needed. The developer even if is involved just has to develop the feature, not imagine a new one...even he can propose some interested evolution.
So i don't really understand this discussion. ...
Uh huh.
by Jonathan Allen,
Your message is awaiting moderation. Thank you for participating in the discussion.
I'm not sure how much stock we should put into his YAGNI claims when so much of his advice is centered around creating copious amounts of abstract interfaces, DI injection points, IoC containers, and other kinds of mostly unnecessary plumbing.
It's like a guy who put a sink in every room of the house saying that you should only build a one car garage because you aren't certain that you'll need the extra space.
Uh huh.
by Jonathan Allen,
Your message is awaiting moderation. Thank you for participating in the discussion.
I'm not sure how much stock we should put into his YAGNI claims when so much of his advice is centered around creating copious amounts of abstract interfaces, DI injection points, IoC containers, and other kinds of mostly unnecessary plumbing.
It's like a guy who put a sink in every room of the house saying that you should only build a one car garage because you aren't certain that you'll need the extra space.
Re: don't understand. ..
by Gyula Csom,
Your message is awaiting moderation. Thank you for participating in the discussion.
The role of the developer/analyst/customer itself would be an interesting (but other) topic...
If you are not interested in business YAGNI (ie. your analysts deals with business scope in your workflow) then you might be still interested in engineering YAGNI:-)
For instance a typical mistake is to overabstract things or abstract beforehand. That is introducing such an abstraction that is (a) currently not needed since a simpler solution could work and (b) there is a chance that it won't be needed ever, since new problems wouldn't fit. Now YAGNI kicks of with all its costs the article talks about. This kinda stuff is also related to another XP rule, ie. simplicity [1].
Cheers,
Gyula
[1] see for instance: www.extremeprogramming.org/rules/simple.html
Re: Uh huh.
by Abhishek Sharma,
Your message is awaiting moderation. Thank you for participating in the discussion.
I think there is no relation of IOC or DI with yagni. Yagni talks not to work on feature which is not required right now. But your code should be extensible for addition of new feature and you can achieve it by using by IOC or DI container.
For example let's take simple example of text comparator utlity, today your requirement is to only report differences and you are reporting it in simple format, say csv (Work done, with prespective of future extensibilty you used DI). In future you want some minor analytics on difference(new feature) and you think why not to have difference report in Excel. With presence of DI you can easily(xml changes) add class for writing data in excel.
Re: Uh huh.
by Jonathan Allen,
Your message is awaiting moderation. Thank you for participating in the discussion.
My code doesn't need to be extensible. It's my code, I can change it any time I want. In fact, the only time I've ever had trouble extending code was when it was already "extensible", but in a way that made it impossible to add the extension points I needed without major refactoring and full regression testing.
Now if we're talking about a library that someone else wrote, then yea is might need to be extensible. But extensibility in libraries are a feature. They need to be carefully thought about and documented, not just slapped together without a second thought. That's why WCF is so hated. It is incredibly extensible, but no one knows how to extend it.
Re: Uh huh.
by Luis Espinal,
Your message is awaiting moderation. Thank you for participating in the discussion.
Are IoC containers unnecessary plumbing?
Re: Uh huh.
by Johnny FromCanada,
Your message is awaiting moderation. Thank you for participating in the discussion.
Yes, when you currently only need "Hello, World!"
Re: Uh huh.
by Luis Espinal,
Your message is awaiting moderation. Thank you for participating in the discussion.
But that response does not make any sense. Your original post that claimed IoC containers are superfluous did not make any qualifications in terms of a system's size. As a result, the statement has to be taken to systems in general.
Of course IoC's would not make sense in a "Hello World" program, or in a trivial system for that matter. And we could say the same out of everything in such a trivial context, even structured programming.
But we are not talking about trivial systems. Trivial systems make redundant almost everything that is important in non-trivial systems. So to say IoC's are redundant in "Hello World" systems is true, but it is as useful as saying "water is wet", or "the world is round". It is a TBU (true but useless).
The context that matters is the context of non-trivial systems. That context is implicit in this discussion.
So are IoC's redundant or not?