[drylight]

YAGNI is not about being lazy, it's about being smart about the code being written, about the craft.

Over-engineering, architecture astronauts, hurt a system a lot more than someone following YAGNI. Making systems that are a big mess of hard to understand and modify code (even worse). I've seen this happen again and again.

Architects sitting in ivory towers pump out Word documents which result in overly complicated systems. Large, slow, waste people's time and money. The whole idea of "oh, in 10 years we may want to handle this and that" adds unecessary code which then needs to be tested and creates many more points of failure. And did I mention slow? These hairy-balled monstrosities are terribly sow.

If over-engirneers got paid by the line of code, they'd be millionaires. If they got paid for writing elegant, short and easy to maintain code, then they wouldn't have two pennies to rub together -- the YAGNI developer would be sitting in his yacht.

You Ain't Gonna Need It!

[sanderjd]

I'm not so convinced that YAGNI generally leads so directly to "elegant, short, and easy to maintain code" as you say. Certainly, with a very keen sense of when to make the transition from Ain't to Are, it can lead to time-savings and simpler and more focused code, but with less discipline or tight deadlines or (typically) both, it can also lead to repetition and the complexity of maintaining many one-off features, even if each is relatively simple in itself. Something very similar can be said for a more architectural philosophy - with a very keen sense of when a design is liberating and when it is burdensome, it can lead to less repetition and targeted maintenance, but with less discipline it can lead to analysis-paralysis and over-engineering. Like most things, the best answer is somewhere in the middle.

My preference is YAGNI while keeping a sharp eye on things that are relatively hard to make extensible later and relatively easy to make extensible now. To tack on another not-great example to the not-great Dog example - if I find myself writing 'dog' a bunch of times in a bunch of ways, I may well pull that out into some sort of `type` variable even if I-ain't-gonna-need-it.

[drylight]

You're correct when you say about YAGNI not necessarily leading to "elegant, short, and easy to maintain code". That is, in the end, up to the developer's skill.

[sanderjd]

Well, I agree with you because you're agreeing with me, but I'm not sure your comment that I replied to agrees with you. From my reading, it definitely implies that YAGNI leads to good code and architecture astronautics doesn't, entirely ignoring developer skill. Perhaps you just oversold your point.

[hackinthebochs]

It would be much easier to discuss issues of design patterns and when to apply them if we weren't constantly being bombarded with straw men. Ivory towers and word documents? Come on now, this adds nothing to the discussion and yet this is basically the entirety of the argument against anticipatory structural code.