The YAGNI principle of software development says that when there's a good chance that "you ain't gonna need it", it's better to postpone adding a program feature.
Even when it turns out that the functionality really is needed, the habit of writing code that is not necessary at the moment has some overlooked disadvantages:
* The time spent is taken from 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 not possible to define what it should do, or to test it. This often results in such features not working right even if they eventually are needed.
* It leads to code bloat; the software becomes larger and more complicated while providing no more functionality.
* Unless there are specifications and some kind of revision control, the feature will never be known to programmers who could make use of it.
* Adding the new feature will inevitably suggest other new features. The result is a snowball effect which can consume unlimited time and resources for no benefit.
This principle very much supports both the concepts of Eliminating Waste and Defer Commitment. If you are not sure that code or functionality is really needed, you need to do some more homework. This homework could be additional research, talking with customers, or just waiting until you deliver higher priority functionality to the customer and really see if they need something else. In Lean, if there isn't direct Customer Value it is considered Waste. That is a bad thing. As mentioned above, it also leads to more complexity which can impact the long-term maintainability and quality of your code. Therefore, why not keep things as simple as possible until you absolutely need to put more into it?
I have seen in many design sessions where things get into a frenzy because the developers have figured out something cool with the technology they are using and are very eager to implement their ideas. This is fine, as long as the technology and their ideas translate into something the customer really wants or needs. Too many times, customers are usually forced into having something new that the development team thought they needed only to find they hardly use it. What happens next? Well, usually both the customer and the development team live with this unused, most likely complicated functionality forever. In the end, nobody is really happy about it.
However, when you find yourself in such a meeting (and you will at some point), remind the team about YAGNI. This will be a good reminder to them about the important of value and to wait until it is the right time to implement such functionality.
No comments:
Post a Comment