Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The cost YAGNI was never about

newsletter.kentbeck.com

Post reply on HN
Print view View original

31–40 of 151 posts

Re: The cost YAGNI was never about

#31

Post by gste »

"When you build structure before the feature arrives, you’re committing on a guess."

I would argue that you are guessing either way. It could be probable that your feature will arrive, but not certain. It's a probability. If you don't build structure now, there's a cost for refactoring. If you build prematurely and the feature never arrives, you wasted effort.

What's the cost, probability and trade off between those possibilities? Obviously it depends. The whole YAGNI idea is a massive generalisation by design. Ultimately it depends on the circumstance.

Either way, it's often full of guessing and hand waving. It's the same problem as giving reliable work estimates. Certain software developers don't cope well with an uncertain world and look for black-and-white rules for everything.

Re: The cost YAGNI was never about

#32

Post by MoreQARespect »

cauch wrote: post #21
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”.

I agree. Nothing is all black or white of course, but I have personally observed situations where software engineers started with YAGNI and then said "that will require too much restructuring, we went into another direction, so, no, we cannot do it anymore". The worst part is that software engineers are not even in a good position to understand when YAGNI fails: when they don't plan for a useful feature, the solution…

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 will never be needed in the end.

* Create abstractions for something that will be needed but not in the form they initially expected.

It is not about avoiding refactoring. That misses the point entirely. Refactoring cleans up code mess that exists NOW - creating abstractions for somehting that exists NOW.

Re: The cost YAGNI was never about

#33

Post by saulpw »

svat wrote: post #16
geetee wrote: post #7

[flagged]

I think it's the latter. I find the introduction (written by Kent Beck) easier to understand than the rest of the article (which he says is AI-written: "genie-generated description of YAGNI"). In particular writing like this is just annoying: > Perfect foresight doesn’t save you, because the discounting doesn’t care whether you were correct. It cares that you sequenced the cost ahead of the return. The gap between th…

This sounded like generated text to me. "The gap" etc

Re: The cost YAGNI was never about

#35

Post by sublinear »

phamilton wrote: post #5
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…

I'm not talking about time. I'm talking about safety. The amount of times I've seen "I refactored it, but I'm not confident enough to take it to prod" is significant. Being able to go faster but still not ship it is the huge opportunity cost.

In the broader corporate world, that's not "opportunity cost". All changes are considered "risk".

All deployments must be approved by an advisory board. All work must originate from a clear business need. Analysis of those needs is not concerned with implementation, least of which whether "AI" is used.

What matters far more is that a contract requires work to be done by a deadline. Those deadlines are driven by policy. There will be no adjustment to policy unless tangible benefits are shown from more frequent deployments of code.

I gotta tell you that's extremely unlikely if you're already shipping every other week at the end of the sprint. Most of that sprint is spent in meetings, not writing code. Nobody is doing big refactors because it wasn't built so fast to require them. There's some technical debt, but nothing so severe. Those meetings are preventing risk, not wasting time. The bottleneck is a feature, not a bug.

If you think the future of dev work is to be a bureaucrat, you're right! It looks like the rest of the world outside of SV is ahead of the curve and living in the future.

Re: The cost YAGNI was never about

#36

Post by bazoom42 »

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.

Re: The cost YAGNI was never about

#37

Post by phamilton »

sublinear wrote: post #35
phamilton wrote: post #5

Earlier quoted context omitted.

I'm not talking about time. I'm talking about safety. The amount of times I've seen "I refactored it, but I'm not confident enough to take it to prod" is significant. Being able to go faster but still not ship it is the huge opportunity cost.

In the broader corporate world, that's not "opportunity cost". All changes are considered "risk". All deployments must be approved by an advisory board. All work must originate from a clear business need. Analysis of those needs is not concerned with implementation, least of which whether "AI" is used. What matters far more is that a contract requires work to be done by a deadline. Those deadlines are driven by polic…

That's not at all what I meant.

I mean "We can't build X because our code structure makes that difficult" has an opportunity cost of the value of X.

I don't think the future of dev work is being a bureaucrat. I've done more rigorous engineering the last two years than I did previously. I'm more confident in the things I shop and they were built in a fraction of the time. It's a bright future for software engineering.

Re: The cost YAGNI was never about

#38

Post by AyanamiKaine »

I personally think it all comes to exploring and implementing solutions for problems. There is always a cost associated with solving the wrong problem. Or implementing a bad solution for something that was not even necessary.

Sometimes software developement can devolve to, just becoming a trial-error approach instead of thinking about a set of strategies/problems to explore.

There is a good case that exploring problems further in specific direction than needed can help long term. But implementing solutions aimlessly is never a good idea.

I think this is what Kent Beck really means, critizing implementing something just in case because you might need it in the future.

Re: The cost YAGNI was never about

#39

Post by MoreQARespect »

passive wrote: post #30

(In general, I think we don't do enough to emphasize best practices in the era of AI, but...) What Kent completely ignores here, as far a I can tell, is that there is significant value in finding out sooner what the needed features are. Building speculative structure can be a forcing function to establish requirements, because at least you start exposing failure modes. It might be more expensive than waiting, so hope…

>Building speculative structure can be a forcing function to establish requirements

Sure, if you're doing it as a spike but if you're not throwing the code away then it functions as a forcing function for creating slop.

Re: The cost YAGNI was never about

#40

Post by dingdingdang »

disfictional wrote: post #19
marifjeren wrote: post #8

> This is not an argument that prediction is hard, as if a sharper architect escapes it. I disagree with this. The argument _only works_ if prediction is hard.

> Even a correct guess leaves you worse off than not committing. Similarly, this is also confusing. If I scaffold a highly-likely feature and everything lines up, I ship the feature faster. My team isn't guaranteed to grow or even maintain our headcount, so scrambling to account for YAGNI close to the deadline feels worse than congratulating ourselves on our restraint.

Honestly think a lot of this article is ai babble - check how it ends on several classic ai negative triples such as "you’ll pay both bills on it just the same — plus you’ll comprehend it less, because you didn’t write it." ... etc.
Post reply on HN