I understand it. I've formerly been employed at a BigCo during a 6 month period when the entire IS department was in the throes of an architectural analysis paralysis. If you've never seen an abstract factory factory factory, then you could be forgiven for thinking the only people that invoke YAGNI are slackers that want to be lazy.

I've worked at Microsoft, so maybe I do know what a slow-moving BigCo is like. Yet for all the cruft I did see, I never once recall thinking, "if only these people had YAGNI..." Usually the problem was just the opposite, that something was built that was overly specialized and not re-usable and somehow managed to spread its implementation details all over the place.

The factory-factory-factory example reminds me of a certain brand of OO spaghetti, very typical of people who are applying ideas from OOP but don't have a firm grasp of what problem those ideas were meant to solve. I see that problem as distinct from YAGNI, it's just a problem of bad design.

My own advice would be: it's fine to make some shortcuts in the interest of productivity, but please try to keep them isolated. The details of your shortcut shouldn't leak heavily into your design, and the next person to maintain it should be able to swap out pieces without fearing the rest of the thing will fall over.

Agreed. Most of the hand-wringing I see against overengineering is just people trying to justify bad programming practices.

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!

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.

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.

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.

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.

I divide YAGNI into two cases: security and bloat.

Bloated features are what you just described - more often than not, it's unproductive to code in extra things you don't need on a deadline. You can better work elsewhere. And yet, I think you're right, a lot of developers who will eventually need/want what they're putting in later anyway.

On the other hand, YAGNI has significant security implications. I posted a example downthread about how a database could be compromised by adding in a back-end feature for lazy admins. In that case, YAGNI is really something you want to avoid.

A lean system is an easier system to plug up. But I also understand that's a bit outside the scope of strict features.

For another example where YAGNI is not a good idea, see https://news.ycombinator.com/item?id=6268480 about apps not handling HTTP response code 410 (resource is gone) correctly.

Maybe it shouldn't be seen as a hard rule but as some heuristic in the back of your mind, to avoid over-abstraction, digression and never-shipped depression. A counter-balancing notion.

And most of the times people mean YAGNI for the first expression of need-vs-implementation. Surely they know there's a lot of chance that one will need more solid abstraction, but it's just to avoid digging too deep into the wrong hole. Somehow it's like http://en.wikipedia.org/wiki/Simulated_annealing . Avoid being stuck in a local maximum.

> seeing a piece of code that was specially written for a very narrow and specific use case, and needing to extend it to some scenario that the original author did not envision

There's pain in both options: making something specific that has to be made more general later, and making something overly general and never actually having a use for the additional complexity.

The former, though, is solving problems you have, and the latter is solving problems you often don't end up having. Given the choice, I would always prefer the former.

Thinking about reuse and applying YAGNI are not opposites.

On the contrary, I find that to apply YAGNI successfully, you must think about reuse, or you'll waste a ton of time refactoring all the time and the cost of adding the features you do end up needing will be massive.