[Nomentatus]

Yes, I have seen businesses die, both ways. The problem is that YAGNI cashes out to "make the right decisions" - it's logically a tautology, but an emotional encouragement to drop features. Dropping is usually the correct decision - but too often catastrophic when it's not. If you invoke YAGNI you have to be careful you aren't "picking up nickles in front of steamrollers" - a great idea until suddenly it's not. Fortunately, frequent iteration gives people a more realistic view of the cost of raisins.

[beat]

I haven't seen businesses die because they can't wait two weeks for a new feature, and had to have it right now. I have seen businesses die because a development team was so paralyzed by constant interruptions that they were dysfunctional and couldn't get any real work done.

[mistermann]

I've seen products fail because of a refusal to support flexibility in core functionality because the extra work couldn't be justified due to YAGNI, and then get totally outclassed by competitive products where they were more agile.

Want to know the correct answer to this agreement? Sometimes YAGNI is good, sometimes it's bad. Anyone who doesn't realize this is not qualified to decide which case a team finds itself in.

[Nomentatus]

If it's a better data structure, then two weeks might set the course, alas. It's happened to me. Fact is, one can't get away from judgement calls, slogans might nudge in one direction or another, but it all remains a judgement call what's just a raisin and what isn't. The fatal problem is bosses up the chain who want to demonstrate they matter and are worth their expense by throwing in superfluous raisins; having a crude slogan (misleading or not) to deter them is fine by me.

[beat]

A "better data structure" is almost never an emergency. And being unable to adapt or extend a data structure in the future is not agile, and it's not the simplest thing that can possibly work.

Back when I first started building a startup, I thought "Thank Dog I no longer have to deal with stupid compromised software, and can start writing everything right!" By the time I was getting anywhere, I was well into toss-over-wall methodology. I did things that I knew full well were compromised and would hurt me later, because the work needed done, and needed to "be done". It was a real education.

I actually have a lightning talk in mind on this subject, called "Why software sucks", that argues that suckage is the nature of software development, and that "barely works" is the best we can realistically ask for - or even should ask for.