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

41–50 of 151 posts

Re: The cost YAGNI was never about

#41

Post by sublinear »

phamilton wrote: post #37
sublinear wrote: post #35

Earlier quoted context omitted.

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.

[dead]

Re: The cost YAGNI was never about

#42

Post by cassianoleal »

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.

Time, safety and cost are one and the same. Not safe enough? Spend more time increasing confidence. Taking too long? Cheap out now and pay the price later due to added risk.

All of that is orthogonal to AI. All AI did was accelerate the typing code part - which was never the bottleneck or a very significant cost to begin with.

Re: The cost YAGNI was never about

#45

Post by zephen »

toast0 wrote: post #27
zephen wrote: post #6

Nothing I have read by Kent Beck has ever suggested that he would be useful in a chip company, where lots of people toil for a long period of time in order to produce something that no customer can possibly see until it's finished, and that must be sold in quantities of millions in order to make money.

> no customer can possibly see until it's finished I'm sure lots of chip companies don't share their work in progress, but it's not impossible. Sharing simulations and prototypes and engineering samples can and does happen. You've typically got to be a big customer, of course. But yes, insights for an industry with relatively small costs for change don't apply easily to an industry with large costs for change, and of…

> You've typically got to be a big customer, of course.

Yes, if you're a big enough customer, you might essentially be part of the design team.

> Sharing simulations and prototypes and engineering samples can and does happen.

Simulations aren't the thing. They don't go fast enough to solve anybody's problem. To your point, if a customer is part of the design team, then yes, they can, at that point, help to debug, or possibly even get started on their own dependent designs. (Part of the shift-left I talked about in another comment.)

I'm not sure what you mean by "prototypes" but "engineering samples" are essentially the finished product, done after all the work I described.

Yes, they may have bugs (or they might just not have passed validation and ESD testing yet), but that doesn't alter the fact that a waterfall effort happened before they were delivered.

> But yes, insights for an industry with relatively small costs for change don't apply easily to an industry with large costs for change, and often vice versa.

The problem with indiscriminate use of agile is that, while, yes, the software industry has relatively small costs for change, it has traditionally had huge costs for the initial delivery, and many agile proponents don't properly segregate those two cases.

If LLMs live up to their apparent promise, then, of course, the equations around the huge costs for the initial delivery could change dramatically.

Of course, the same LLM promise means that the strict definition of TDD (tests written first) is also irrelevant, and perhaps even counterproductive.

Re: The cost YAGNI was never about

#46

Post by samrus »

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…

Your increasing thrash betting that AI will fix it for you. The only thing your getting in return is not having to think that hard.

It doesnt cost that much time or effort to think hard, so you will be outcompeted by people levergaing AI as much as you, but thinking enough to not have it be thrashing around

Re: The cost YAGNI was never about

#48

Post by cauch »

MoreQARespect wrote: post #32
cauch wrote: post #21

Earlier quoted context omitted.

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…

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 abstraction has a huge cost. And, as I've said, it is not rare that it's the users who pay the most of the cost, which mean the devs don't even know it is a problem.

As I've said, nothing is all white or all black. The problem with YAGNI is the developers think it's all white: they can decide "you ain't gonna need it" when they have no expertise on what is going to be needed because they are not the users.

Re: The cost YAGNI was never about

#49

Post by rednb »

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 things right, and multiplying debt for teams having a low quality bar as far as design and architecture are concerned.

Re: The cost YAGNI was never about

#50

Post by esafak »

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.
Post reply on HN