The cost YAGNI was never about

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 up substantially.

This is the number one thing I optimize for now: the ability to quickly and safely change significant parts of the code and product.

(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 hopefully you don't do it for most of your requirements, but sometimes it's your best option.

Building the wrong thing is now a much less expensive option, and that means the calculation around YAGNI is different. But it's still a calculation, and for now, each team needs to figure out how it has changed for them.

Kent Beck compares unwritten code with a financial option to buy something at a given price.

But that's just an analogy, and it can be taken too far. If you haven't written any code, do you have infinite options? You haven't spent any time yet, but still, that doesn't seem quite right. It might be used to justify staying in the planning stage and putting off writing code indefinitely, to avoid committing to anything.

Why might the analogy work anyway?

Maybe the cost is reading the code? Code that hasn't been written doesn't need to be read. And if you're using a coding agent, it doesn't clutter up the context with irrelevant detail.

Also, code that hasn't been written yet doesn't need testing. Tests you haven't written yet don't take any time to run.

These are good reasons to try to keep a project as small as possible. By putting off features, you delay codebase growth as long as you can.

This suggests that you can avoid a lot of costs by running someone else's code. If you can use a standard API then you don't need to understand the implementation in detail or run its tests. But there are risks to adding dependencies.

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.

Seeing running software as an asset is the right approach.

But the costs of executing and even re-doing things went significantly down.

The costs that didn't went down are the ones of breaking the chain of trust to a predictable outcome. A specific version of some running software accumulated trust. If you rewrite it from scratch that capital is reset on release.

> 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.

https://en.wikipedia.org/wiki/You_aren't_gonna_need_it in case anyone else was wondering

My general principal is the cost of deleting code should be as low as possible and that includes the entire application as long as the data is around and easy to repurpose then the program itself should be as deletable as possible

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

I can't tell if my brain is decaying or if this is just drivel. It's happening more and more, not just this article. Maybe I'm just burnt out and my brain rejects any attempts at comprehending software articles.

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.

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”.

[dead]