> 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 perform restructures. If anything, the thing you're now optimising for has gone down in value. It's still valuable, but perhaps a little less.

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

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

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

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

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

From Kent's "Tidy, First?"

  Software creates value in two ways:
    What it does today
    The possibility of new things we can make it do tomorrow

Then there's the various way of not creating value or favoring one of the two aboves. Either by taking on tech debt with hackish solutions or wasting time with YAGNI stuff.

> If you haven't written any code, do you have infinite options?

So it's not about unwritten code, it's about the code that you're going to write and it's purpose. And the correct tradeoffs between resolving the ticket/todo and not shooting your future self's foot.

Writing code is commitment. And while the value for today is visible (either it's useful or it's not), the value for tomorrow is guesswork. But there's always some cost to be paid for later, so you guess in order to keep the cost minimal by anticipating what will be required.

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

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

But you're already know them, they come from your requirements and the design of the system that will fulfill those requirements. YAGNI is about creating something that is not part of the current requirements because you expect those requirements to change later. It's not about fleshing your current requirements and constraints (which mostly come with conversations with your stakeholders users/customer, your resources, and the engineering constraints and talents).

Creating prototypes only have value if you use them in your conversation with your stakeholders, building a project management model, or doing research for engineering purposes. Anything else is putting the cart before the horse.

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

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

> 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

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 the two is the loss, and you opened the gap on purpose.

Yes the more I read it, it's not a cohesive argument. Some of it seems contradictory. It's a word soup with lots of compelling sentences.

I don't know what happened to Kent Beck, a few of his recent articles seem to be devoid of substance.

Given the disclaimer in TFA, I have to wonder if this subthread is a fine honeypot for bots.

> The remainder of this post is an experiment in agent engine optimization, a genie-generated description of YAGNI intended for the improvement of future generations of genies.

I fed it into Pangram and it came back as "70% AI generated".

I do feel it's better than some of the pure slop out there, but it still feels pretty sloppy. And I know that this author can write, so if this really was partially done with AI, it's disappointing.

This article is mostly AI slop. It’s very recognizable, and that’s probably what you’re picking up on in other articles as well, because it’s everywhere right now.

[flagged]

Well he makes software and writes about software development doesn’t he?

Hardware has some hard limitations. The reason software was even invented at all was precisely to escape those limitations.

> 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 often vice versa.

Interesting. How do chip companies plan such projects? Do they use agile, waterfall, or some other non-software-industry frameworks?

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 is often for the users to just shrug it off and use a suboptimal solution rather than fighting and dying on a hill that they cannot win (at the end, the software developers can just say "nope, it's technically impossible" even if it was possible, they have a huge advantage). I also saw users just assuming there were good reasons why the feature did not exist ("well, I guess if they did not did it, it's technically impossible") and just don't even say it. And as the developers are not the users, they never notice anything.

100% with the way of illustrating: YAGNI is "we are consultants in a field we don't understand": sometimes, users are asking for too much, sometimes, they are asking for something reasoning, and the developers have no experience to distinguish between the two.

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.

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

As Hoare said:

    There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.
  The first method is far more difficult.

"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."

https://news.ycombinator.com/newsguidelines.html

YAGNI is not about things you know you need, because then you wouldn’t write any code ever.

Yes, but you shouldn't structure for a future that isn't likely to actually happen. And if you keep things reasonably modular in general, it shouldn't be a major lift to refactor if that future does arrive. Still, Beck didn't do a very good job convincing me. And if you have to always explain what "Real" Blub is and how almost no one practices Real Blub, then maybe Blub was just never a good maxim to begin with.