8 ms·

The cost YAGNI was never about

131 points by kiyanwang 3mo ago

phamilton 3mo ago
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.
- cassianoleal 3mo ago
  > 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.
  - phamilton 3mo ago
    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.
    - sublinear 3mo ago
      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 policy. There will be no adjustment to policy unless tangible benefits are shown from more frequent deployments of code. I gotta tell you that's extremely unlikely if you're already shipping every other week at the end of the sprint. Most of that sprint is spent in meetings, not writing code. Nobody is doing big refactors because it wasn't built so fast to require them. There's some technical debt, but nothing so severe. Those meetings are preventing risk, not wasting time. The bottleneck is a feature, not a bug. If you think the future of dev work is to be a bureaucrat, you're right! It looks like the rest of the world outside of SV is ahead of the curve and living in the future.
      - phamilton 3mo ago
        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.
        sublinear 3mo ago
        [dead]
    - cassianoleal 3mo ago
      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.
  - mohamedkoubaa 3mo ago
    Ironically, AI assisted/generated code is not trending in the direction of the ability to safely and quickly change. Especially when piloted poorly
    - cassianoleal 3mo ago
      I hear you! I also actually find it a lot more difficult to ensure proper guardrails are in place to keep the agents doing good engineering work.
    - joshka 3mo ago
      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.
      - majormajor 3mo ago
        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.)
        joshka 3mo ago
        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
  - xboxnolifes 3mo ago
    >> 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.
- samrus 3mo ago
  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
  - 6510 3mo ago
    > It doesnt cost that much time or effort to think hard If you manage to avoid effort and thinking long enough it will get harder.
- rednb 3mo ago
  > 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.
  - rzmmm 3mo ago
    Over the last couple months I've seen the debt multiplication in some OSS projects. It's like premature aging of a codebase.
  - phamilton 3mo ago
    > 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.
- lmm 3mo ago
  > 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.
  - chowells 3mo ago
    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.
- majormajor 3mo ago
  > 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.
  - phamilton 3mo ago
    > 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.
- ffsm8 3mo ago
  > The cost of implementing a zero downtime migration has gone down because of AI. You either don't know what that technical term means or you're just wrong. AI does not meaningfully move the needle on that. It only makes backwards compatible deployments easier insofar you're able to do the overhead for splitting the change with less effort then before.
  - phamilton 3mo ago
    I've always known how to do zero downtime migrations. The question has always been "Is the engineering cost worth it?" > It only makes backwards compatible deployments easier insofar you're able to do the overhead for splitting the change with less effort then before. Yes. That reduces the cost of implementing them. To be clear, I'm not talking about "Split my db migration and my code that depends on the new table". I'm talking about things like "Set up dual writes between an old database schema and a new database schema with a thorough test suite and do shadow reads against both datasets in prod to do differential testing". That's nontrivial engineering effort that would definitely warrant a discussion in the past. Today we just do it. It's fast and lowers risk.
sebastianconcpt 3mo ago
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.
zephen 3mo ago
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.
- marifjeren 3mo ago
  Interesting. How do chip companies plan such projects? Do they use agile, waterfall, or some other non-software-industry frameworks?
  - ajb 3mo ago
    They (or at least some of them) use waterfall - the real waterfall, not the bogeyman invented by agile consultants.
    - andrekandre 3mo ago
      [dead]
  - zephen 3mo ago
    (Some) chip companies have jumped on the agile bandwagon for (some) tasks. It's always interesting to read about some chip company or another making some agile move, when the reality is that they were already doing about as many agile things as possible before agile was a thing. (For example, a management commitment to "shift left" when they have always been about significant up-front testing and feedback.) In many, if not most, cases, the testing software is so huge that at least some of it needs to be tested itself. That can certainly benefit from agile. But the overall process more resembles traditional waterfall. You have several definite final endpoints, and although you can make subsequent changes, those are expensive. Also, you have a silicon budget, and a pin budget, and a heat and power budget. At the end of the day, you are producing something physical with real-world physical constraints that (a) cost real money, and (b) can't be altered by just telling your customer to add more RAM or a bigger processor. Also, in general, although designers will write their own little unit tests for a few things, it is best practice to insure that the real tests are performed by internal organizations that are different than the organization the designer is in. I think that subconsciously, he truism that it is easier to work with and reason about a system that is already working, and to keep it working, than to get it working at all to begin with, drives a lot of the methodology. The designer might focus on tests to insure that things work well enough to see some results, so things can be hooked up and system tests performed earlier. In one sense, this is a shift left -- the validation people and the people writing software for the chip can get started sooner than they would have otherwise, even if it's a bit frustrating because not everything works off the bat. But the real torture tests are typically written by the dedicated verification and validation teams. Those are really different skills than design.
geetee 3mo ago
[flagged]
- mh2266 3mo ago
  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.
- svat 3mo ago
  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.
  - saulpw 3mo ago
    This sounded like generated text to me. "The gap" etc
- temp_praneshp 3mo ago
  [flagged]
  - dang 3mo ago
    You can't post like this here, and we ban accounts that do, so please don't. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- gste 3mo ago
  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.
marifjeren 3mo ago
> 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.
- disfictional 3mo ago
  > 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.
  - dingdingdang 3mo ago
    Honestly think a lot of this article is ai babble - check how it ends on several classic ai negative triples such as "you’ll pay both bills on it just the same — plus you’ll comprehend it less, because you didn’t write it." ... etc.
    - girvo 3mo ago
      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.
      - marifjeren 3mo ago
        The article does not say this.
        croemer 3mo ago
        It does: > The remainder of this post is an experiment in agent engine optimization, a genie-generated description of YAGNI Genie-generated means AI generated
        3mo ago
skybrian 3mo ago
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.
- skydhash 3mo ago
  > 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 Unwritten code has no value. The code that is being written today, if it will be creating value, leans towards helping with with a request/issue today or helping making/solving things easier 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.
  - skybrian 3mo ago
    What corresponds to owning an option?
Scubabear68 3mo ago
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”.
- fmbb 3mo ago
  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.
  - zeroonetwothree 3mo ago
    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.
    - skydhash 3mo ago
      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.
    - rcxdude 3mo ago
      Unused abstractions are tech debt, whether they were previously used or (even worse) never used. They constrain and complicated the addition of other features and abstractions within the code. It's almost always easier to start with a codebase that is simpler and with fewer abstractions and take it in a given direction than it is one with lots of abstractions which don't suit the direction you want to take it. (and of course, everyone imagines that their abstractions will be in the right direction, but this is rarely the case). Unused abstractions are pure waste, because they take effort to make and effort to remove and never produce any value.
turlockmike 3mo ago
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
huflungdung 3mo ago
[dead]
passive 3mo ago
(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.
- MoreQARespect 3mo ago
  >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.
- skydhash 3mo ago
  > 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.
gste 3mo ago
"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.
- dogwalker5000 3mo ago
  > 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-coding/ https://www.sebastiansylvan.com/post/the-perils-of-future-co... TL;DR - it sides with YAGNI
AyanamiKaine 3mo ago
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.
rwmj 3mo ago
https://en.wikipedia.org/wiki/You_aren't_gonna_need_it https://en.wikipedia.org/wiki/You_aren't_gonna_need_it in case anyone else was wondering
- a96 3mo ago
  https://c2.com/xp/YouArentGonnaNeedIt.html https://c2.com/xp/YouArentGonnaNeedIt.html on the original Wiki.
deleted 3mo ago
[deleted]
esafak 3mo ago
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.
- chuckadams 3mo ago
  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.
  - mrkeen 3mo ago
    > 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. I'll push back. No-one I work with seems to practice "real DI", "real encapsulation", or "real agile", and the software is the worse for it.
    - chuckadams 3mo ago
      Good point, though I'll try to draw a distinction between those and subjective-opinion-based slogans like "YAGNI". Maybe I should just limit it to that one: YAGNYAGNI?
deleted 3mo ago
[deleted]
mrkeen 3mo ago
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 yourself the least to any concrete implementation.
- deleted 3mo ago
  [deleted]
- dpark 3mo ago
  > 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.
  - tpoacher 3mo ago
    Then again, this goes completely against the "O" in the SOLID principles (and possibly also the "D" too). Personally I prefer SOLID to YAGNI.
  - deleted 3mo ago
    [deleted]
antonvs 3mo ago
> 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.
marvinstrauch 3mo ago
[flagged]
zamalek 3mo ago
I recently had to functionally migrate away from a codebase that had a ton of YAGNI. _Even with_ an agent it was a herculean task: how do you know if something is really used in a distributed system. I missed things, the agent missed things, it all took way longer than it should have. (FWIW, I wasn't simply doing a 1:1 port, I took the opportunity to simplify - which meant completely understanding how the old system worked, including things that were _never_ used if I failed to identify them as such)

131 points by kiyanwang 3mo ago

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.

cassianoleal 3mo ago
> 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.
- phamilton 3mo ago
  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.
  - sublinear 3mo ago
    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 policy. There will be no adjustment to policy unless tangible benefits are shown from more frequent deployments of code. I gotta tell you that's extremely unlikely if you're already shipping every other week at the end of the sprint. Most of that sprint is spent in meetings, not writing code. Nobody is doing big refactors because it wasn't built so fast to require them. There's some technical debt, but nothing so severe. Those meetings are preventing risk, not wasting time. The bottleneck is a feature, not a bug. If you think the future of dev work is to be a bureaucrat, you're right! It looks like the rest of the world outside of SV is ahead of the curve and living in the future.
    - phamilton 3mo ago
      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.
      - sublinear 3mo ago
        [dead]
  - cassianoleal 3mo ago
    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.
- mohamedkoubaa 3mo ago
  Ironically, AI assisted/generated code is not trending in the direction of the ability to safely and quickly change. Especially when piloted poorly
  - cassianoleal 3mo ago
    I hear you! I also actually find it a lot more difficult to ensure proper guardrails are in place to keep the agents doing good engineering work.
  - joshka 3mo ago
    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.
    - majormajor 3mo ago
      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.)
      - joshka 3mo ago
        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
- xboxnolifes 3mo ago
  >> 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.
samrus 3mo ago
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
- 6510 3mo ago
  > It doesnt cost that much time or effort to think hard If you manage to avoid effort and thinking long enough it will get harder.
rednb 3mo ago
> 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.
- rzmmm 3mo ago
  Over the last couple months I've seen the debt multiplication in some OSS projects. It's like premature aging of a codebase.
- phamilton 3mo ago
  > 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.
lmm 3mo ago
> 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.
- chowells 3mo ago
  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.
majormajor 3mo ago
> 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.
- phamilton 3mo ago
  > 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.
ffsm8 3mo ago
> The cost of implementing a zero downtime migration has gone down because of AI. You either don't know what that technical term means or you're just wrong. AI does not meaningfully move the needle on that. It only makes backwards compatible deployments easier insofar you're able to do the overhead for splitting the change with less effort then before.
- phamilton 3mo ago
  I've always known how to do zero downtime migrations. The question has always been "Is the engineering cost worth it?" > It only makes backwards compatible deployments easier insofar you're able to do the overhead for splitting the change with less effort then before. Yes. That reduces the cost of implementing them. To be clear, I'm not talking about "Split my db migration and my code that depends on the new table". I'm talking about things like "Set up dual writes between an old database schema and a new database schema with a thorough test suite and do shadow reads against both datasets in prod to do differential testing". That's nontrivial engineering effort that would definitely warrant a discussion in the past. Today we just do it. It's fast and lowers risk.

sebastianconcpt 3mo ago

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.

zephen 3mo ago

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.

marifjeren 3mo ago
Interesting. How do chip companies plan such projects? Do they use agile, waterfall, or some other non-software-industry frameworks?
- ajb 3mo ago
  They (or at least some of them) use waterfall - the real waterfall, not the bogeyman invented by agile consultants.
  - andrekandre 3mo ago
    [dead]
- zephen 3mo ago
  (Some) chip companies have jumped on the agile bandwagon for (some) tasks. It's always interesting to read about some chip company or another making some agile move, when the reality is that they were already doing about as many agile things as possible before agile was a thing. (For example, a management commitment to "shift left" when they have always been about significant up-front testing and feedback.) In many, if not most, cases, the testing software is so huge that at least some of it needs to be tested itself. That can certainly benefit from agile. But the overall process more resembles traditional waterfall. You have several definite final endpoints, and although you can make subsequent changes, those are expensive. Also, you have a silicon budget, and a pin budget, and a heat and power budget. At the end of the day, you are producing something physical with real-world physical constraints that (a) cost real money, and (b) can't be altered by just telling your customer to add more RAM or a bigger processor. Also, in general, although designers will write their own little unit tests for a few things, it is best practice to insure that the real tests are performed by internal organizations that are different than the organization the designer is in. I think that subconsciously, he truism that it is easier to work with and reason about a system that is already working, and to keep it working, than to get it working at all to begin with, drives a lot of the methodology. The designer might focus on tests to insure that things work well enough to see some results, so things can be hooked up and system tests performed earlier. In one sense, this is a shift left -- the validation people and the people writing software for the chip can get started sooner than they would have otherwise, even if it's a bit frustrating because not everything works off the bat. But the real torture tests are typically written by the dedicated verification and validation teams. Those are really different skills than design.

geetee 3mo ago

[flagged]

mh2266 3mo ago
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.
svat 3mo ago
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.
- saulpw 3mo ago
  This sounded like generated text to me. "The gap" etc
temp_praneshp 3mo ago
[flagged]
- dang 3mo ago
  You can't post like this here, and we ban accounts that do, so please don't. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
gste 3mo ago
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.

marifjeren 3mo ago

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

disfictional 3mo ago
> 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.
- dingdingdang 3mo ago
  Honestly think a lot of this article is ai babble - check how it ends on several classic ai negative triples such as "you’ll pay both bills on it just the same — plus you’ll comprehend it less, because you didn’t write it." ... etc.
  - girvo 3mo ago
    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.
    - marifjeren 3mo ago
      The article does not say this.
      - croemer 3mo ago
        It does: > The remainder of this post is an experiment in agent engine optimization, a genie-generated description of YAGNI Genie-generated means AI generated
      - 3mo ago

skybrian 3mo ago

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.

skydhash 3mo ago
> 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 Unwritten code has no value. The code that is being written today, if it will be creating value, leans towards helping with with a request/issue today or helping making/solving things easier 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.
- skybrian 3mo ago
  What corresponds to owning an option?

Scubabear68 3mo ago

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

fmbb 3mo ago
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.
- zeroonetwothree 3mo ago
  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.
  - skydhash 3mo ago
    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.
  - rcxdude 3mo ago
    Unused abstractions are tech debt, whether they were previously used or (even worse) never used. They constrain and complicated the addition of other features and abstractions within the code. It's almost always easier to start with a codebase that is simpler and with fewer abstractions and take it in a given direction than it is one with lots of abstractions which don't suit the direction you want to take it. (and of course, everyone imagines that their abstractions will be in the right direction, but this is rarely the case). Unused abstractions are pure waste, because they take effort to make and effort to remove and never produce any value.

turlockmike 3mo ago

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

huflungdung 3mo ago

[dead]

passive 3mo ago

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

MoreQARespect 3mo ago
>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.
skydhash 3mo ago
> 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.

gste 3mo ago

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

dogwalker5000 3mo ago
> 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-coding/ https://www.sebastiansylvan.com/post/the-perils-of-future-co... TL;DR - it sides with YAGNI

AyanamiKaine 3mo ago

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.

rwmj 3mo ago

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

a96 3mo ago
https://c2.com/xp/YouArentGonnaNeedIt.html https://c2.com/xp/YouArentGonnaNeedIt.html on the original Wiki.

deleted 3mo ago

[deleted]

esafak 3mo ago

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.

chuckadams 3mo ago
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.
- mrkeen 3mo ago
  > 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. I'll push back. No-one I work with seems to practice "real DI", "real encapsulation", or "real agile", and the software is the worse for it.
  - chuckadams 3mo ago
    Good point, though I'll try to draw a distinction between those and subjective-opinion-based slogans like "YAGNI". Maybe I should just limit it to that one: YAGNYAGNI?

deleted 3mo ago

[deleted]

mrkeen 3mo ago

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 yourself the least to any concrete implementation.

deleted 3mo ago
[deleted]
dpark 3mo ago
> 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.
- tpoacher 3mo ago
  Then again, this goes completely against the "O" in the SOLID principles (and possibly also the "D" too). Personally I prefer SOLID to YAGNI.
- deleted 3mo ago
  [deleted]

antonvs 3mo ago

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

marvinstrauch 3mo ago

[flagged]

zamalek 3mo ago

I recently had to functionally migrate away from a codebase that had a ton of YAGNI. _Even with_ an agent it was a herculean task: how do you know if something is really used in a distributed system. I missed things, the agent missed things, it all took way longer than it should have. (FWIW, I wasn't simply doing a 1:1 port, I took the opportunity to simplify - which meant completely understanding how the old system worked, including things that were _never_ used if I failed to identify them as such)