The cost YAGNI was never about • Hacker News Board

Re: The cost YAGNI was never about

#51

Post by MoreQARespect » Sun, Jun 28, 2026, 9:05 PM UTC

cauch wrote: post #48

MoreQARespect wrote: post #32

Earlier quoted context omitted.

YAGNI is simply a tacit recognition that you can't predict the future with any reasonable level of certainty. The reason it is controversial is that some devs truly believe that they can predict the future with all the self assurance of a grandma sitting in front of a one armed bandit in vegas. So, they will: * Create generalized functions where a specific one would have done. * Create abstractions for something that…

The problem is that YAGNI is __literally__ predicting the future: you ain't gonna need it. How do they know that, if it is not a prediction? In the examples I have observed, your 3 points were made impossible because early on people said YAGNI. You can always "create them later", the same way you can always "restart from scratch". Creating abstraction for a code that was designed without being compatible with these a…

It's predicting that you will predict wrong frequently enough to make it not worthwhile predicting at all.

I apply the same logic at slots: the way to win is not to play.

>Creating abstraction for a code that was designed without being compatible with these abstraction has a huge cost

I have never found it more expensive to create an abstraction after following the rule of 3.

Indeed, ive always noticed that abstractions which are front loaded are nearly ALWAYS worse than abstractions built with hindsight.

>As I've said, nothing is all white or all black. The problem with YAGNI is the developers think it's all white

We think you're playing slots and remembering only the wins, believing that you're just naturally talented at predicting the future.

Ive seen this attitude in hundreds of devs. They all think theyre uniquely able to anticipate the code base's future needs.

Re: The cost YAGNI was never about

#52

Post by mohamedkoubaa » Sun, Jun 28, 2026, 9:14 PM UTC

cassianoleal wrote: post #4

phamilton wrote: post #2

The cost of restructuring has also gone down. The cost of shoring up behavior with tests ahead of a restructure has gone down because of AI. The cost of implementing a zero downtime migration has gone down because of AI. A big part of the rust hype has been the low cost of restructuring within an application, even before AI. And now even more so. The opportunity cost of not being able to safely restructure has gone u…

> This is the number one thing I optimize for now: the ability to quickly and safely change significant parts of the code and product. This was always a good thing. Its value has nothing to do with the advent of AI coding. > The opportunity cost of not being able to safely restructure has gone up substantially. This bit is contradictory with everything else you said. Prior to AI coding it would take a lot longer to p…

Ironically, AI assisted/generated code is not trending in the direction of the ability to safely and quickly change. Especially when piloted poorly

Re: The cost YAGNI was never about

#53

Post by antonvs » Sun, Jun 28, 2026, 9:14 PM UTC

geetee wrote: post #7

[flagged]

This article is mostly AI slop. It’s very recognizable, and that’s probably what you’re picking up on in other articles as well, because it’s everywhere right now.

Re: The cost YAGNI was never about

#54

Post by Scubabear68 » Sun, Jun 28, 2026, 9:28 PM UTC

bazoom42 wrote: post #36

Scubabear68 wrote: post #12

What Beck misses over and over again is there are many domains where there are “table stakes” that simply have to be done. I think a huge amount of technical debt goes straight to YAGNI - devs pretending they are not going to need something that, yeah, they need. YAGNI and related tenets were all excuses for “we are consultants in a field we don’t understand”.

YAGNI is not about things you know you need, because then you wouldn’t write any code ever.

This was the issue with the early agile-developed systems.

Not that they didn’t write no code, obviously, but they didn’t understand the domain and so YAGNI’d everyone to death. As a result there wasn’t enough code for the system would do what it needed to do.

The code was simple and highly testable, but didn’t actually do the job.

Re: The cost YAGNI was never about

#55

Post by rkachowski » Sun, Jun 28, 2026, 9:35 PM UTC

geetee wrote: post #7

[flagged]

I don't know what happened to Kent Beck, a few of his recent articles seem to be devoid of substance.

Re: The cost YAGNI was never about

#56

Post by cassianoleal » Sun, Jun 28, 2026, 9:37 PM UTC

mohamedkoubaa wrote: post #52

cassianoleal wrote: post #4

Earlier quoted context omitted.

> This is the number one thing I optimize for now: the ability to quickly and safely change significant parts of the code and product. This was always a good thing. Its value has nothing to do with the advent of AI coding. > The opportunity cost of not being able to safely restructure has gone up substantially. This bit is contradictory with everything else you said. Prior to AI coding it would take a lot longer to p…

Ironically, AI assisted/generated code is not trending in the direction of the ability to safely and quickly change. Especially when piloted poorly

I hear you! I also actually find it a lot more difficult to ensure proper guardrails are in place to keep the agents doing good engineering work.

Re: The cost YAGNI was never about

#57

Post by marcosdumay » Sun, Jun 28, 2026, 9:37 PM UTC

zephen wrote: post #24

marifjeren wrote: post #9

Earlier quoted context omitted.

Interesting. How do chip companies plan such projects? Do they use agile, waterfall, or some other non-software-industry frameworks?

(Some) chip companies have jumped on the agile bandwagon for (some) tasks. It's always interesting to read about some chip company or another making some agile move, when the reality is that they were already doing about as many agile things as possible before agile was a thing. (For example, a management commitment to "shift left" when they have always been about significant up-front testing and feedback.) In many,…

Just to point, but shifting left isn't agile at all. In fact, it's slightly against development agility.

It's just a good engineering practice, that is more than useful enough to compensate for any loss of agility it may cause.

Re: The cost YAGNI was never about

#58

Post by [deleted] » Sun, Jun 28, 2026, 9:41 PM UTC

[deleted]

Re: The cost YAGNI was never about

#59

Post by mrkeen » Sun, Jun 28, 2026, 9:42 PM UTC

At some point for me something flipped.

I YAGNI the concretion and write the abstract-as-possible version.

Do I write a UserStore? That would be the simplest, right? Well no, I might not need that particular formulation of a User. So I just make a Store of anything-which-is-storable.

If you're not used to it, it looks like you've over-engineered and ended up with Generics soup, but paradoxically, you're committing yourself the least to any concrete implementation.

Re: The cost YAGNI was never about

#60

Post by chuckadams » Sun, Jun 28, 2026, 9:45 PM UTC

esafak wrote: post #50

This is terrible advice. You absolutely should structure your code with a view to the future. Easily refactorable code is synonymous with good code. And using the right abstractions makes this happen. Consult a domain expert to find out what you will need. This is what experience is for.

Yes, but you shouldn't structure for a future that isn't likely to actually happen. And if you keep things reasonably modular in general, it shouldn't be a major lift to refactor if that future does arrive. Still, Beck didn't do a very good job convincing me. And if you have to always explain what "Real" Blub is and how almost no one practices Real Blub, then maybe Blub was just never a good maxim to begin with.