It's not a secret anymore!
The moose likes OO, Patterns, UML and Refactoring and the fly likes YAGNI (or not?) Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Customer Requirements for Developers this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "YAGNI (or not?)" Watch "YAGNI (or not?)" New topic

YAGNI (or not?)

Tapio Niemela
Ranch Hand

Joined: Jan 06, 2006
Posts: 77
Hi, I've recently been pondering about the YAGNI principle. Basically it warns about over-engineering and premature over-optimization. I agree somewhat to that principle, but at my current project I'm working with legacy code which could have benefited of *some premature* design. Now code-base is filled with classes with static methods. Methods which iterate through similar-like structures and apply some invocation (like calculate something) to applicable objects in the structure. Sounds bit like visitor or functional programming (or it's counterpart implemented in java), especially predicates, or what do you think?

The problem is that the code-base should have been implemented differently in the first place (maybe using visitor or FP). Now when I have to make changes I have two options:
- apply same methodology as used previously. E.g. everything is static something();. (Need I say more..)
- try to apply *some* design within the change. The problem is that it should have already been made; it's like post-over-engineering the implementation, also concern is it "necessary" or "(re)-usable". Code changes where I have taken this road have probably become more complicated.

Especially I think that acyclic visitor "hooks" could have been put into important classes. Some say it will complicate the code. Maybe, but then it would exist, thus enabling adding functionality afterwards

So, in my opinion, YAGNI doesn't always apply. Sometimes it might be better to design the code before jumping to the coding activity. But this should take place in the first phases of the project, not in late phases. Big question remains : WHEN are you actually gonna need it, or not?
Jayesh A Lalwani
Saloon Keeper

Joined: Jan 17, 2008
Posts: 2636

The problem with YAGNI is that it's very easy to go from YAGNI to YAGNIITTR(You aint gonna need it in the this release) to YAGNIITTS(You aint gonna need it in the this sprint) to WDWDITRW(Why dont we do it the right way). The thing is that whether you gonna need it or not need it is a judgement call, and in many organisations that are adopting agile practices, the guy who keeps looking 3 sprints ahead gets shunted aside.
Matthew Brown

Joined: Apr 06, 2010
Posts: 4538

I wouldn't consider YAGNI an excuse for poor design. Keep it simple to begin with, and don't add features you don't need, but the moment that the code can benefit from some refactoring go ahead and improve it. Otherwise you're eventually going to get an unmaintainable mess (as you're seeing).

I read a quote I liked about YAGNI in a book I reviewed here (, which said something along the lines of "spend as much time as you need to produce high-quality code, but don't spend any time developing features you don't need".
chris webster

Joined: Mar 01, 2009
Posts: 2168

Like a lot of Agile ideas, I think YAGNI gets used as an excuse for poor/short-sighted designs and implementation, especially when it relates to cross-cutting concerns that tend not to come up in user-driven "stories" etc. But you can often keep your code open for later improvements, without necessarily implementing those extra features now.

But in a lot of places YAGNI is tends to boil down to WAGNI-BWDWPFI (we are gonna need it - but we don't wanna pay for it). YAGNI is easier to remember though!

No more Blub for me, thank you, Vicar.
It is sorta covered in the JavaRanch Style Guide.
subject: YAGNI (or not?)
It's not a secret anymore!