You Ain't Gonna Need It

From Wikipedia, the free encyclopedia

In software engineering, YAGNI, short for 'You Aren't Gonna Need It', suggests to programmers that they should not add functionality until it is necessary. Ron Jeffries writes, "Always implement things when you actually need them, never when you just foresee that you need them."^[1] According to those who advocate the YAGNI approach, the temptation to write code that is not necessary at the moment, but might be in the future, has the following disadvantages:

The time spent is taken from adding, testing or improving necessary functionality.
The new features must be debugged, documented, and supported.
Any new feature imposes constraints on what can be done in the future, so an unnecessary feature now may prevent implementing a necessary feature later.
Until the feature is actually needed, it is difficult to fully define what it should do and to test it. If the new feature is not properly defined and tested, it may not work right, even if it eventually is needed.
It leads to code bloat; the software becomes larger and more complicated.
Unless there are specifications and some kind of revision control, the feature may not be known to programmers who could make use of it.
Adding the new feature may suggest other new features. If these new features are implemented as well, this may result in a snowball effect towards creeping featurism.

[edit] Balancing concerns

Judging to omit a feature due to the YAGNI viewpoint should be balanced against other concerns, such as benefits of refactoring code, anticipating upcoming features, team expectations (or fears), availability of part-time expert assistance, and providing for completeness of functionality.

Note that the concept of avoiding unnecessary work with the YAGNI principle must be tempered against the potential need for refactoring software modules to make them simpler or faster in the future. If a software module, or an entire software product, represents a dead-end effort at the time, then any further modifications (such as refactoring) can be viewed as YAGNI issues. However, this concern is somewhat obviated by the effects of YAGNI itself - that is, it is always easier to refactor simpler code.

Another restriction is the potential for enhanced features for the customer. A feature which might seem unnecessary, at an early point, might become part of a vital future enhancement adding value to the product. Such judgments, assessing current and future features, should probably involve discussions with multiple people to help determine a "yes" or "no" decision about implementing such features. Of course, YAGNI only applies to features that are known not to be needed.

Also affecting the decision is the impact of fear or confusion for the people involved with a new feature. An individual or team working on a new enhancement might face disappointment if the new work is denied, or demanded, against their personal expectations, either excited about the new work, or dreading the anticipated workload, associated with a particular feature. This concern should obviously be handled well prior to YAGNI principles being applied.

Yet another conflicting factor is the access to expert assistance, which might be limited. For example, experts might be available to design features X, Y, or Z, and also recommend another, but currently unneeded, feature W. A judgment call is needed to determine whether such expert design of an unneeded feature should be encouraged, while the expert is available, to support potential product enhancement in the future, where enhancements would be implemented by junior personnel after the expert has left. Perhaps a bigger concern stems from depending on outside expert assistance at all.

A logical conflicting factor is the notion of completeness, which tends to define missing options, or facets, mostly likely to be needed: for example, among features which allow adding items, deleting items, or modifying items, completeness could be used to also recommend "renaming items". The critical impact of completeness can be seen in some types of wiki-collaboration software which can add or delete image-files, but not simply rename images, at all, even after several years of software upgrades. Of course, YAGNI, by definition, would not apply to features that are needed to "complete" the project.

In general, the YAGNI viewpoint must be balanced against the other concerns, such as those of refactoring, upcoming vital features, team expectations, part-time expert assistance, and logical completeness.