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?
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.
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).
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!