71–80 of 151 posts
Earlier quoted context omitted.
Interesting. How do chip companies plan such projects? Do they use agile, waterfall, or some other non-software-industry frameworks?
They (or at least some of them) use waterfall - the real waterfall, not the bogeyman invented by agile consultants.
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.…
> 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 ea…
Earlier quoted context omitted.
> 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.
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.
Earlier quoted context omitted.
> I have never found it more expensive to create an abstraction after following the rule of 3. This is the problem: your judgement is biased. You think it was a good idea, but in reality, you have no real idea if it was or not. Don't get me wrong, as I've said, I think that sometimes not over-building is a good idea. The problem is that YAGNI is the wrong solution. To avoid over-building, the solution is not to inven…
>This is the problem: your judgement is biased. You think it was a good idea, but in reality, you have no real idea if it was or not. My judgement is based upon my experience trying it both ways many times over the course of decades. >To avoid over-building, the solution is not to invent a rule that says "just don't build". It isnt a rule that says dont build what you need now. It is a rule that says dont try to anti…
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 the blind spot is independent to experience and get a false sense of confidence.
> It isnt a rule that says dont build what you need now. It is a rule that says dont try to anticipate what architectures or abstractions might be needed in the future.
And what mine and the comment I answered are saying is that unfortunately YAGNI is badly designed in a way that leads devs to think there is only two options: 1. anticipate what architectures or abstractions might be needed in the future, 2. not anticipate anything. The correct solution is not to anticipate what __might__ be needed, it is to listen to people who have a better idea of what __is__ needed.
Again (but are you even reading what I said, you totally ignored some of the points in my previous comment), we all agree here that over-building or jumping to architecture or abstraction that will not be needed is a bad thing. But YAGNI as a solution to this problem is stupid. The solution is to be careful with the assumption and cross-check with the team (which include non-dev). YAGNI recommends to treat one ASSUMPTION ("it will not be needed") as default, which is as stupid as assuming the opposite. And the reason devs think it works is that over-development has externalities that affect devs (a bloated software is harder to manage) while under-development has externalities that affect non-devs (users have to live with the absence of features, delivering something that does half the job is accepted by the users because it is better than nothing and because they don't know if the missing features is just "irreducible complexity" that devs cannot fix).
> I used to think like you when I was more junior (most do), so it's not like I dont have a lot of practice thinking that YAGNI applied only sometimes.
100% of the devs who created bad software applying YAGNI stupidly said exactly that. These bad software were created because these devs thought they had plenty of experience and that they knew better.
(and by the way, I'm not junior, and I have delivered a lot of code that ended up in production, mainly when I had to step up when devs were not able to do so, sometimes because they were saying "YAGNI")
> It was hard experience that taught me that it was pretty universal.
Exactly what the devs who messed up the projects I have as examples have said.
Earlier quoted context omitted.
> 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 ea…
What corresponds to owning an option?
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 you own an option when you create the scaffold (paying the premium). So you're already writing code, but there's nothing valuable to the business yet. Owning an option can be good as in you're not paying the full price yet. But you've paid something and it can impact your budget for adding fully realized features (which is the only thing that is truly valuable to the company).
If you can keep a lot of potential behaviors (your options) in your portfolio (your codebase) open while keeping the cost of creating them minimal, then your portfolio become more resilient. As today's is tomorrow's past, your value as a developer is what behavior you can extract from your portfolio to create the valuable thing for the business (which is the only thing your employee and/or customers care about). Having an option that have kept the price cheap is what matters.
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.
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.
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.
> The remainder of this post is an experiment in agent engine optimization, a genie-generated description of YAGNI
Genie-generated means AI generated
(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 hope…
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.
Earlier quoted context omitted.
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.
> 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.
[flagged]
> 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.