[cite web]
url=http://www.xprogramming.com/Practices/PracNotNeed.html
title=You’re NOT gonna need it!
accessdate=2007-11-07
author=Ron Jeffries] 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, the unnecessary feature 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.
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.
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, in potentially private conversations, 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.
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 simply rename images, at all, even after several years of software upgrades.
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.
ee also
* KISS principle
* Don't repeat yourself
* List of software development philosophies
* Extreme Programming
* MoSCoW Method
References
External links
* [http://c2.com/cgi/wiki?YouArentGonnaNeedIt You Arent Gonna Need It page at Portland Pattern Repository's Wiki ]
