James YAGNI
In the software world, YAGNI is one of many cutely named heuristics from the agile community that stands for “don’t waste time/money putting that feature/functionality in the code base NOW cuz odds are that You Ain’t Gonna Need It!”. It’s good advice, but it’s often violated innocently, or when the programmer doesn’t agree with the YAGNI admonisher for legitimate or “political” reasons.
When a team finds out downstream and (more importantly) admits that there’s lots of stuff in the code base that can be removed because of YAGNI violations, there are two options to choose from:
- Spend the time/money and incur the risk of breakage by extricating and removing the YAGNI features
- Leave the unused code in there to save time/money and eschew making the code base slimmer and, thus, easier to maintain.
It’s not often perfectly clear what option should be taken, but BD00 speculates (he always speculates) that the second option is selected way more often than the first. What’s your opinion?
Leave a reply to bulldozer00 Cancel reply
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 
Tony,
YAGNI is a prediction. Its results depend on:
1. How clear a vision of the future the predictor has. Much of the YAGNI’s power relies on a perception that engineers can be prone to fantasy, imagining requirements that don’t materialize
2. What the cost is of being wrong? If you follow YAGNI and it turns out you do need it, how widespread is the change. OTOH, if you anticipate a need and add it now, how hard is it to rip it out later?
If the deferred capability is peripheral and the effort/risk required to splice it it later will have a low refactoring cost, then YAGNI is a great idea. OTOH, if the deferred capability central and would be pervasive, then the disruption associated with waiting can be high.
Java followed YAGNI principles and decided that the JVM didn’t need realtime support. RTSJ was the first JSR and it took forever to implement, because garbage collection (a huge challenge to RT) was non-deterministic. RTSJ has to resort to defining different classes of memory (heap, scope, etc.) with exotic rules about which areas could refer to others. The standard Java runtime library was ignorant of those rules, and would blithely violate them.
Similar examples include deciding you don’t need fine-grained access control, or deciding you can get by with data in files rather than a DBMS.
Charlie
Thanks for the feedback Charlie. YAGNI is not a prediction, it’s a misnamed actor 🙂
Much like “one man’s requirement is another man’s design”, one man’s YAGNI is another man’s ORINI (Oh Rats! I Needed It!).
Entirely correct!
This is a classic Type 1, Type 2 error problem, where the hypothesis is “Don’t Need It”
Type 1 Error = I thought the hypothesis was false, but it turned out true = YAGNI/Cagney
Type 2 Error = I thought the hypothesis was true, but it turned out false = ORINI
D’oh! I hate dilemmas/paradoxes/tradeoffs. They make my head hurt.