You Ain't Gonna Need It
Encyclopedia
"You ain't gonna need it" (acronym: YAGNI) is the principle in extreme programming
that programmer
s 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."
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.
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.
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 rename images.
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.
Extreme Programming
Extreme programming is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements...
that programmer
Programmer
A programmer, computer programmer or coder is someone who writes computer software. The term computer programmer can refer to a specialist in one area of computer programming or to a generalist who writes code for many kinds of software. One who practices or professes a formal approach to...
s should not add functionality until it is necessary. Ron Jeffries
Ron Jeffries
Ron Jeffries is one of the 3 founders of the Extreme Programming software development methodology circa 1996, along with Kent Beck and Ward Cunningham. He was from 1996, an XP coach on the Chrysler Comprehensive Compensation System project, which was where XP was invented. He is an author of...
writes, "Always implement things when you actually need them, never when you just foresee that you need them."
Rationale
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 correctly, even if it eventually is needed.
- It leads to code bloatCode bloatCode bloat is the production of code that is perceived as unnecessarily long, slow, or otherwise wasteful of resources. Code bloat can be caused by inadequacies in the language in which the code is written, inadequacies in the compiler used to compile the code, or by a programmer...
; the software becomes larger and more complicated. - Unless there are specifications and some kind of revision controlRevision controlRevision control, also known as version control and source control , is the management of changes to documents, programs, and other information stored as computer files. It is most commonly used in software development, where a team of people may change the same files...
, 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 effectSnowball effectSnowball effect is a figurative term for a process that starts from an initial state of small significance and builds upon itself, becoming larger , and perhaps potentially dangerous or disastrous , though it might be beneficial instead...
towards creeping featurismCreeping featurismFeature creep, creeping featurism or featureitis is the ongoing expansion or addition of new features in a product, such as in computer software. Extra features go beyond the basic function of the product and so can result in over-complication rather than simple design...
.
Balancing concerns
Judging to omit a feature due to the YAGNI viewpoint should be balanced against other concerns, 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
Refactoring
Code refactoring is "disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior", undertaken in order to improve some of the nonfunctional attributes of the software....
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.
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.
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
Wiki
A wiki is a website that allows the creation and editing of any number of interlinked web pages via a web browser using a simplified markup language or a WYSIWYG text editor. Wikis are typically powered by wiki software and are often used collaboratively by multiple users. Examples include...
-collaboration software which can add or delete image-files, but not rename images.
In general, the YAGNI viewpoint must be balanced against the other concerns, such as those of refactoring
Refactoring
Code refactoring is "disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior", undertaken in order to improve some of the nonfunctional attributes of the software....
, upcoming vital features, team expectations, part-time expert assistance, and logical completeness.
See also
- KISS principleKISS principleKISS is an acronym for the design principle Keep it simple, Stupid!. Other variations include "keep it simple and stupid", "keep it short and simple", "keep it simple sir", "keep it simple or be stupid" or "keep it simple and straightforward"...
- Abstraction principle (programming)Abstraction principle (programming)In software engineering and programming language theory, the abstraction principle is a basic dictum that aims to reduce duplication of information in a program whenever practical by making use of abstractions provided by the programming language or software libraries...
- Don't repeat yourselfDon't repeat yourselfIn software engineering, Don't Repeat Yourself is a principle of software development aimed at reducing repetition of information of all kinds, especially useful in multi-tier architectures...
- List of software development philosophies
- Extreme programmingExtreme ProgrammingExtreme programming is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements...
- MoSCoW MethodMoSCoW MethodMoSCoW is a prioritisation technique used in business analysis and software development to reach a common understanding with stakeholders on the importance they place on the delivery of each requirement - also known as MoSCoW prioritisation or MoSCoW analysis.According to A Guide to the Business...