Comment by addisonj | Hacker News Reader

Comment by addisonj | Hacker News Reader

These comments seem to illustrate something I have felt for a while: yagni is incredibly divisive topic and for every person saying praising it is another who is at the very least cautious of its application.

It makes me wonder where the divide is.

Perhaps more large 'enterprise' shops where projects can spin out of control into what they 'must have' whereas the small shops where you need to get a product out ASAP?

Or maybe age of developer, with the young eager guy confident he can whip out all n features in 3 weeks so we might as well add that feature too vs the experienced dev who knows better and we will add it once it is needed?

I have put some time and effort into asking people about this very question, but still am no closer to understanding why some really appreciate it and others hate the phrase.

Personally, my guiding principle after being bit by yagni is that it is a wonderful principle to use when making product/feature decisions but should be exercised very carefully when making architecture decisions. Which makes sense, features come on and go, but architecture is generally something you need to live with. In other words, whenever yagni is used is an argument against what are more good coding and design practices than practical problems, then it may be something more of a case of 'no really, we are going to need it'

Funny, I think of the age divide running the other way. Younger devs, who came up during the age of agile, take YAGNI as a given, while older devs have seen the results of too many hasty decisions.

The advice I was given when I started out was, "it's cheaper to fix something upstream". Catching a potential problem during design is always cheaper than catching it during development, which is cheaper again than catching it after release.

This argument always seems to get lost in the YAGNI discussion.

YAGNI only makes sense in the context of other extreme programming[1] practices, such as making code safe to modify through unit tests[2] and easy to modify because you refactored mercilessly[3] to produce a nice, modular design.

I suspect the divide in reactions to YAGNI comes between people who have embraced those practices and those who haven't (and probably don't even know what they would look like, and can't imagine an environment that uses them).

In the context of a project where making changes is hard and dangerous, and where you have few automated tests, you will be tempted to change a lot at once, so that you can then manually check everything works once, rather than having to do that multiple times. And that might well be the better strategy.

Consider the question "What if we need extra fields in our 'product' table?". The Extreme Programming answer is both 'embrace change' and YAGNI. That means 1) we absolutely definitely require some general mechanism to be able to add columns to tables in the future, so we must have that in place, and not assume the product table schema is fixed forever 2) we have no idea what columns or how many columns will be needed in the future, so we don't add any now speculatively.

But many people work in environments where adding a column to a table would be a massively expensive task (thousands of stored procedures that need rewriting etc.). In this context, the 'YAGNI' response which just refuses to think about future does sound stupid, because it is.

[1] http://c2.com/cgi/wiki?ExtremeProgramming [2] http://c2.com/cgi/wiki?UnitTest [3] http://c2.com/cgi/wiki?RefactorMercilessly

> It makes me wonder where the divide is.

I think it works beautifully if you're applying it along with "refactor mercilessly", backed by good unit tests. It's a principle that doesn't necessarily stand on its own; it needs to be part of a healthy, iterative system of development.

If refactoring becomes difficult or dangerous for whatever reason (eg, designing an API for long-term, widespread usage), then YAGNI may not work.

Reply on news.ycombinator.com