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

91–100 of 151 posts

Re: The cost YAGNI was never about

#91

Post by phamilton »

majormajor wrote: post #81
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…

> perfect refactor-proof testing contracts are still usually pretty hard to design

Not sure about hard, but definitely rare and we as an industry are under-skilled in these areas.

We have decades of research and tools for testing and verification of software. Property tests, dependent types, formal verification and proof, etc. The paths have been there, we have just collectively prioritized other things.

It requires an intentional shift in how we design and build. That shift is the harder part.

Re: The cost YAGNI was never about

#92

Post by phamilton »

rednb wrote: post #49
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 ability to quickly and safely change significant parts of the code and product. Hum, this reminds me something... "O: open to extension, closed to modifications". Old things are new again. From context efficiency with approaches such ad DDD and clean architectures, all the way to items such as this one, AI is not creating new tradeoff, it just acts as a multiplier, multiplying productivity for teams doing thing…

> Old things are new again.

This is exactly how I've felt. I've read some many old papers and books and found great techniques that are even more applicable than ever.

Re: The cost YAGNI was never about

#93

Post by skydhash »

skybrian wrote: post #86
skydhash wrote: post #75

Earlier quoted context omitted.

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.

In the financial world, you need to pay to own an option. The "option" he is talking about, you paid it in terms of time to construct the scaffolding.

You need a feature F, you can build feature F directly (no options, just creating what is valuable today). One example is using an external dependency directly in your business logic.

You can also build enough abstraction so that feature F is decoupled enough from the rest of the project that the latter only have a logical view of it (which hardly changes). That can be done cheaply, making it easier to easily modify the code according to the business logic. You just go a little further than the previous version, but without really committing to the anticipated changes. Like hiding the dependency behind an interface of your choosing.

You can also over engineer the solution anticipating changes that are not likely to happens (buying options at very high cost). One example is writing an ORM layer because you may need to switch from sqlite to SQLServer. Or writing an agnostic UI library because you may need to support everything from HTML to raw OpenGL and ncurses. The issue there is that there's no requirements (from stakeholders) or business values in supporting those use cases.

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

In the last case, you've written code, aka consuming time and money, for a scenario that is uncertain. And even if they do realize, your code would likely be worthless as the assumptions behind it does not match the real requirements. The threshold between the last and the second case is that in the latter, you're not committing to the future design. You're laying some groundwork that leave future work, when needed, easier to accomplish.

Re: The cost YAGNI was never about

#94

Post by dpark »

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…

> If you're not used to it, it looks like you've over-engineered and ended up with Generics soup

Yes, it looks exactly like that. You’ve built not just an interface for UserStore you probably didn’t need, but a generalized Store abstraction that you definitely didn’t need.

> but paradoxically, you're committing yourself the least to any concrete implementation

This isn’t paradoxical at all. You’ve avoided committing yourself to a concrete implementation by implementing layers of goop you don’t need and likely never will. And because you did all this abstraction without real needs to ground it, you almost certainly did it wrong even if you do eventually need it.

You are gonna need a user store, so you should have built that first.

Re: The cost YAGNI was never about

#95

Post by gofreddygo »

actionfromafar wrote: post #28
gofreddygo wrote: post #14

Earlier quoted context omitted.

> we are consultants This is the key insight. Design patterns were developed by a set of consultants. Promoted by other consultants. Consultants have perverse incentives, like bankers. Realizing this made me critical of the design pattern kool aid. I've come to terms that these are going to be around longer than I'm going to be employed writing code. i keep the criticism to myself and avoid them when i dont see fit.…

I still prefer the upsides of a shared vocabulary for talking about programming.

The programming language is the shared vocabulary

Everything above are made up leaky abstractions with a handful of exceptions

Re: The cost YAGNI was never about

#96

Post by girvo »

marifjeren wrote: post #69
girvo wrote: post #61

Earlier quoted context omitted.

The article said it was indeed AI generated babble right at the start, which is why I skipped reading it the moment I saw that. A shame, really.

The article does not say this.

Yes, it does:

> a genie-generated description of YAGNI intended for the improvement of future generations of genies

Re: The cost YAGNI was never about

#97

Post by [deleted] »

dpark wrote: post #94
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…

> If you're not used to it, it looks like you've over-engineered and ended up with Generics soup Yes, it looks exactly like that. You’ve built not just an interface for UserStore you probably didn’t need, but a generalized Store abstraction that you definitely didn’t need. > but paradoxically, you're committing yourself the least to any concrete implementation This isn’t paradoxical at all. You’ve avoided committing…

[deleted]

Re: The cost YAGNI was never about

#98

Post by dogwalker5000 »

gste wrote: post #31

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

> What's the cost, probability and trade off between those possibilities?

I read an old article that compared the various scenarios.

https://www.sebastiansylvan.com/post/the-perils-of-future-co...

TL;DR - it sides with YAGNI

Re: The cost YAGNI was never about

#100

Post by cauch »

skydhash wrote: post #82
cauch wrote: post #74

Earlier quoted context omitted.

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

Look at the article itself:

> Chet said, “You don’t understand. We’re definitely going to need it. See, here’s an example…”

> Me (interrupting), “You aren’t going to need it.”

> Chet, get frustrated, “But we really are…”

> Me, “You aren’t going to need it.”

This is a clear example of YAGNI being used when the dev, actively, does not care if the other person has any argument to defend it will be needed.

YAGNI itself is badly designed, it gives the wrong answer. It should be "Build Thing Carefully": no abstraction if no argument, abstraction if no good argument beyond "YAaGnNIii".

And I know devs would just say "but devs who don't listen is super rare", but it is not true: you probably read the article and did not flinch, not noticing that it's a clear situation where the dev actively refuse to listen to the arguments. How many time did you witness or participate to such situation and still think it never happens?

At the end, I don't understand: just do "Build Thing Carefully", where what you built is well-thought, and not only you get YAGNI for free, but you also avoid the problem with refusing to build something that is needed.

Post reply on HN