“You Aren’t Gonna Need It” is an agile design principle from ExtremePrograming that goes against building code for future features before they are needed. Martin Fowler states in his blog “YAGNI” (https://martinfowler.com/bliki/Yagni.html) how building these features early typically add more time than they save. Fowler breaks down the individual costs of these features and where they add up, along with how these costs vary between three different scenarios. The best scenario is that the presumptive code was still required and added to the project when it was needed. The next scenario is that the feature is scrapped from the project entirely. Arguably the worst scenario is that the feature is added, however, the code that was built in the past was built incorrectly and needs to be updated. These scenarios each have their different costs, but even with the best scenario it is likely time was still lost between deciding to build the feature and when it was finally needed. Assuming that time can be saved by adding a future feature early because it relates to something you are currently doing will only add more work when it comes to debugging, refactoring, and reading the code.
Costs of YANGI
- Cost of Building – All effort and time programming, analyzing, and testing the feature.
- Cost of Delay – The time spent on the presumptive feature could have been spent on a more relevant and required feature, creating a delay in the release and actually monetary and time based costs.
- Cost of Carry – Adding unnecessary code to a project only makes it harder to read and understand, slowing down further production.
- Cost of Repair – Assuming the feature is eventually added to the project, the way it was built in the past may not be right anymore and needs to be repaired or redone.
- Cost of Removal – In the event that the feature is scrapped and removed from the project, the code will also need to be removed or will only continue the accumulation cost of carry.
What YAGNI Is VS What YAGNI Is Not
Following the principle of YAGNI means time spent building code should be spent building code that is relevant to the current state of the build. This does not mean that refactoring falls under YAGNI principles as it is time being spent making the software easier to modify.
Using YAGNI Moving Forward
As projects become larger and more complicated it is important to keep my code clean, organized, and on schedule. The best way to do this is to ensure features are added only when they are needed to not clutter the space with unused code.
From the blog CS@Worcester – CS Learning by kbourassa18 and used with permission of the author. All other rights reserved by the author.
