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

81–90 of 151 posts

Re: The cost YAGNI was never about

#81

Post by majormajor »

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…

> The cost of shoring up behavior with tests ahead of a restructure has gone down because of AI.

Yes.

But the ease of not doing that and instead just getting a brittle set of three-quarters-baked tests is extremely high! And many people seem happy to go from "a few human-written mediocre brittle tests" to "a bunch of AI-written mediocre brittle tests" because it is an objective improvement and the people who weren't avoiding speculative structure and looking for the write boundaries before are happy to also not do so no.

So completely agree with the "take advantage of the tools this way" but I also wouldn't claim it's a reason to no longer worry about if you're building the wrong castles in the sky too early, because perfect refactor-proof testing contracts are still usually pretty hard to design.

Re: The cost YAGNI was never about

#82

Post by skydhash »

cauch wrote: post #74
MoreQARespect wrote: post #67

Earlier quoted context omitted.

>This is the problem: your judgement is biased. You think it was a good idea, but in reality, you have no real idea if it was or not. My judgement is based upon my experience trying it both ways many times over the course of decades. >To avoid over-building, the solution is not to invent a rule that says "just don't build". It isnt a rule that says dont build what you need now. It is a rule that says dont try to anti…

> My judgement is based upon my experience trying it both ways many times over the course of decades. You miss my point: if you are the person who develop the code, your judgement is biased, because you are not the user. You will judge the success without knowing if you delivered what the user needed or not. I saw it again and again, especially with devs who have a lot of experience, because they don't realise that t…

YAGNI is mostly an answer to someone that says "let's create this abstraction", but can't argue why it's really needed. If you can't argue about why you need an abstraction, the best strategy is to not create it. Because removing it afterwards may be more costly than implementing it (if it ever get done).

It's not an objective answer that "you really not gonna need that". It's more "No clear explanation about that abstraction? You ain't gonna need it".

Re: The cost YAGNI was never about

#83

Post by majormajor »

joshka wrote: post #68
mohamedkoubaa wrote: post #52

Earlier quoted context omitted.

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

Citation needed. But in seriousness, this intuitively feels like something (as phrased) that would be easily influenced by loud noise and quantity rather than hard facts. The "piloted poorly" part is applicable to any tool use. AI is no different there other than its adoption rate.

The pattern I observe is: "write code, write test, make things green"

This is different in two ways from the classic TDD red-green-refactor suggestion:

1) they don't start with the test first, so the tests that get implemented are after writing the code, and run the risk of the model attention being now more influenced by the just-written code than the original spec

2) they finish when everything is green and don't followup with the "refactor" step unless manually prompted (either directly or indirectly by your own scaffolding/rules/whatever). this results in frequent hyper-local non-ideal-longterm fixes for things that went wrong in the first shot at writing the code pre-test-writing.

(As always, the only person who can ensure the code landing in your repo is good is you.)

Re: The cost YAGNI was never about

#84

Post by skydhash »

zeroonetwothree wrote: post #15
fmbb wrote: post #13

Earlier quoted context omitted.

All tech debt I have ever seen in my 15 years of professional software development has been someone building too many abstractions or generalizations trying to future proof stuff.

That’s the opposite of the typical definition of tech debt. Usually tech debt is debt—-ie something you take on to ship faster now at the expense of paying it in the long run.

The tech debt comes after the implementation of the many abstractions. Instead of removing them (which can be really hard), you take the easy option of following the complex design, which also make the removal incrementally harder.

Re: The cost YAGNI was never about

#85

Post by [deleted] »

mrkeen wrote: post #59

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 y…

[deleted]

Re: The cost YAGNI was never about

#86

Post by skybrian »

skydhash wrote: post #75
skybrian wrote: post #72

Earlier quoted context omitted.

What corresponds to owning an option?

Again from "Tidy First?" Financial options have these parameters: The *underlying* thing that we can buy The *price* of the underlying, including the volatility of that price The *premium* of the option, or the price we pay today The *duration* of the option, or how long we have to decide whether to purchase the underlying So, there's some behavior of the software that we may want which correspond to the underlying o…

This "scaffolding" sounds like some kind of code that you've written that you don't need yet? What's an example?

Also, in the current article, it sounds like he's using "option" as a metaphor for something different?

> Building early spends that option. You exercise it before expiry and throw away the time value.

Re: The cost YAGNI was never about

#87

Post by chowells »

lmm wrote: post #76
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…

> 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. Disagree. The growth in brittle AI-generated tests means restructuring is more costly than it was before. Pruning your test suite so that it tests the essence of the problem and not the incidental design decisions is something AIs aren't yet capable of.

Oh, it's worse than that. I've seen a rise in mutation testing, intended to ensure any change in implementation is caught by tests. Think about that for a moment. It's giving a fancy name to creating brittle tests than fail if any line of code is changed.

And this is seen as a good thing, because LLMs are really bad at confining their changes appropriately. Testing is really in a dark place right now.

Re: The cost YAGNI was never about

#88

Post by antonvs »

> Chet, eyes going up to the ceiling, pausing, “Oh.” Walks away.

That's the first step in routing around damage. In this case, Kent Beck is the damage, not being willing to listen to what a teammate has to say about the design of a system.

Re: The cost YAGNI was never about

#89

Post by xboxnolifes »

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…

>> 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 value of type safe code did not go up, the cost of development speed has gone down.

Re: The cost YAGNI was never about

#90

Post by joshka »

majormajor wrote: post #83
joshka wrote: post #68

Earlier quoted context omitted.

Citation needed. But in seriousness, this intuitively feels like something (as phrased) that would be easily influenced by loud noise and quantity rather than hard facts. The "piloted poorly" part is applicable to any tool use. AI is no different there other than its adoption rate.

The pattern I observe is: "write code, write test, make things green" This is different in two ways from the classic TDD red-green-refactor suggestion: 1) they don't start with the test first, so the tests that get implemented are after writing the code, and run the risk of the model attention being now more influenced by the just-written code than the original spec 2) they finish when everything is green and don't f…

But here's the rub - if you want your clanker to do those steps, it's usually a simple matter of adding them to your AGENTS.md and then it always does them.

I'm a big fan of the characterization step step being added. And it can be reasonable to add this before or even after the fact as a commit prior to your actual commit (assuming you're familiar with using tools where that's easy to do - e.g. jj or git with rebase). And the agents can do this - they just don't tend to without you saying to do so.

A lot of engineering practice comes from choosing which elements are reasonable to use given the context of what you're building. Providing that is your job. When you do that poorly, you get poor results. But garbage in garbage out has always been a thing. Any advanced automation amplifies ambient assumptions

Post reply on HN