> 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.
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.
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.)
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
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.
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.
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.
> 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.
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.
> 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.
> 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.
> 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
> 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.
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.
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.
> 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.
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, there's some behavior of the software that we may want which correspond to the underlying of the option. That behavior will have a value for to the business later which is it's price (can be 0 or negative). We can spend time and money to create its scaffold (the premium). The duration is how much time we can spend with the scaffold especially if it raise the cost of other behaviors.
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.
In the financial world, you need to pay to own an option. The "option" he is talking about, you paid it in terms of time to construct the scaffolding.
You need a feature F, you can build feature F directly (no options, just creating what is valuable today). One example is using an external dependency directly in your business logic.
You can also build enough abstraction so that feature F is decoupled enough from the rest of the project that the latter only have a logical view of it (which hardly changes). That can be done cheaply, making it easier to easily modify the code according to the business logic. You just go a little further than the previous version, but without really committing to the anticipated changes. Like hiding the dependency behind an interface of your choosing.
You can also over engineer the solution anticipating changes that are not likely to happens (buying options at very high cost). One example is writing an ORM layer because you may need to switch from sqlite to SQLServer. Or writing an agnostic UI library because you may need to support everything from HTML to raw OpenGL and ncurses. The issue there is that there's no requirements (from stakeholders) or business values in supporting those use cases.
> > Building early spends that option. You exercise it before expiry and throw away the time value.
In the last case, you've written code, aka consuming time and money, for a scenario that is uncertain. And even if they do realize, your code would likely be worthless as the assumptions behind it does not match the real requirements. The threshold between the last and the second case is that in the latter, you're not committing to the future design. You're laying some groundwork that leave future work, when needed, easier to accomplish.
(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.
> 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.
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.
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.
> 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.
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.
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)
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.
"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.
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.
> Well he makes software and writes about software development doesn’t he? Hardware has some hard limitations.
Right.
> The reason software was even invented at all was precisely to escape those limitations.
But the methods which are useful for hardware are also often useful for software. Most of the useful parts of agile were already practiced well before that was a name for anything. And the demonization of the straw-man version of waterfall in order to sell more agile consulting has led to some serious misconceptions of what waterfall really is and what it is really capable of and useful for.
The initial impetus for what became known as TDD was software maintenance, and it makes sense there.
But most TDD practitioners are nowhere near as good at real testing as the waterfall test practitioners who understand that a single missed testcase could delay a $10 million project by six months.
And this is why, even in the realm of software you still see serious efforts for aviation and nuclear power plants, and other things with real-world consequences, using more traditional methods.
I have not seen Kent Beck argue for eXtreme Programming or other Agile methods in nuclear power plant software or aviation. These are niche industries and constitute a vanishingly tiny part of all the lines of code out there I presume.
The fact that short iterations adding features incrementally leads to better outcomes for software project is something professionals have known and argued for since the 1960s.
> The fact that short iterations adding features incrementally leads to better outcomes for software project is something professionals have known and argued for since the 1960s.
And practiced by software professionals since the 1960s. For maintenance. Even for aviation and nuclear. But in those industries, you're going to have a clear case, better documentation, and not be trying to "sprint."
Again, many truly best practices well predated XP/agile, and were subsumed into it. The real problem with XP/agile is the dogmatic straw-manning and demonization of other good practices that have their place, such as waterfall and exploratory programming. YAGNI, in particular, is more often used as a cudgel to shut down useful learning and exploration than anything else.
> 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.
> 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.
(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.
On the other hand, like a lot of other good ideas, the agile community has claimed this. A quick google will show that many claim it is a "core agile idea."
It’s absolutely an agile idea. The core of agile development is the ability to iterate quickly. Shift left for certain things enables the cycle to shorten and accelerate iteration.
I agree that it was done by many organizations before “agile” but that’s true of all agile practices. Agile is a philosophy and a collection of tools. None of the tools are new though.
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
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.
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.
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?
> 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.
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.
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.
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.
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.
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.
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 will never be needed in the end.
* Create abstractions for something that will be needed but not in the form they initially expected.
It is not about avoiding refactoring. That misses the point entirely. Refactoring cleans up code mess that exists NOW - creating abstractions for somehting that exists NOW.
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.
> 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 invent a rule that says "just don't build". The solution is to stop having developers thinking they know what is useful or what is not.
> Indeed, ive always noticed that abstractions which are front loaded are nearly ALWAYS worse than abstractions built with hindsight.
Again, you cannot know if it is worse or not. You are not the user. It may be good in some cases, it may be bad in other, and I have seen devs saying exactly what you said when their "abstractions in hindsight" was catastrophic.
There is a lot of example, but just one: we built a system that was collecting data, the goal being to accumulate data for months and then analyse it. Few people involved in the project proposed some structure for the data, but the devs used YAGNI to do what they preferred (there was some objection but at the end, the devs just did what they wanted to do, ignoring the rest of the team because they were confident that they knew more than them how to build software). Later, we started the analysis, and realised all the data were crap: the devs kept changing the data structure by building their abstraction with hindsight, without even documenting when these modifications were deployed to the different sensors. We had a mix of data built based on different parameters with no way to know which part was using which parameters.
After the project failure, I saw many devs still saying that they were right to use YAGNI, and being totally oblivious that it's their choice that doomed the project. They were, seriously, saying that it was a lack of requirement, or that the "users changed their mind", while it was not true at all (I was there, and I was not in either side, I just observed), the situation was well known from the start. The problem was they insisted to apply YAGNI as if they understood better than the other collaborators what as needed.
> We think you're playing slots and remembering only the wins, believing that you're just naturally talented at predicting the future.
You literally just said "ive always noticed that abstractions which are front loaded are nearly ALWAYS worse than abstractions built with hindsight".
This is literally you remembering the amount of "win" and the amount of "loose".
> Ive seen this attitude in hundreds of devs. They all think theyre uniquely able to anticipate the code base's future needs.
That's exactly my point (and I'm not a dev).
When you are saying "abstraction is better built in hindsight", you are just thinking you are smarter than other people.
When the situation is that it is difficult to understand what we will need, the solution is to discuss together to understand what we will need. We may get it wrong sometimes, but we will get it right sometimes. If someone just decides to ignore other collaborators opinion and decides "we will need this abstraction", this person has way more chance to be wrong. If someone just decides to ignore other collaborators opinion and decides "we will not need this abstraction", this person has way more chance to be wrong too.
YAGNI is just someone noticing that building a big house without following the plan led to extra work because they have to demolish the bits they've built on next door property, so they decide to build a small house without following the plan.
>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 anticipate what architectures or abstractions might be needed in the future.
>Again, you cannot know if it is worse or not.
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.
It was hard experience that taught me that it was pretty universal.
> My judgement is based upon my experience trying it both ways many times over the course of decades.
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.
YAGNI is mostly an answer to someone that says "let's create this abstraction", but can't argue why it's really needed. If you can't argue about why you need an abstraction, the best strategy is to not create it. Because removing it afterwards may be more costly than implementing it (if it ever get done).
It's not an objective answer that "you really not gonna need that". It's more "No clear explanation about that abstraction? You ain't gonna need it".
> Chet said, “You don’t understand. We’re definitely going to need it. See, here’s an example…”
> Me (interrupting), “You aren’t going to need it.”
> Chet, get frustrated, “But we really are…”
> Me, “You aren’t going to need it.”
This is a clear example of YAGNI being used when the dev, actively, does not care if the other person has any argument to defend it will be needed.
YAGNI itself is badly designed, it gives the wrong answer. It should be "Build Thing Carefully": no abstraction if no argument, abstraction if no good argument beyond "YAaGnNIii".
And I know devs would just say "but devs who don't listen is super rare", but it is not true: you probably read the article and did not flinch, not noticing that it's a clear situation where the dev actively refuse to listen to the arguments. How many time did you witness or participate to such situation and still think it never happens?
At the end, I don't understand: just do "Build Thing Carefully", where what you built is well-thought, and not only you get YAGNI for free, but you also avoid the problem with refusing to build something that is needed.
> This is a clear example of YAGNI being used when the dev, actively, does not care if the other person has any argument to defend it will be needed
The first paragraph set the context
I could do this simplistic thing now but in 3 weeks that will be insufficient so since we’re going to need this more complicated thing I want to do it now.
You can solve today’s problem and do some groundwork to extend later. What you don’t do is solving today’s problem with a solution for a future problem.
Whatever complicated thing that may be wanted, meaning you don’t have the full specification, as it’s not a current problem for a stakeholder.
In systems design, you’re solving problems belonging to the stakeholder, the project resources, and engineering needs and constraints. Going outside the union of those sets is overengineer, building things no one needs, costing resources that should be allocated to other things, and complicating the design because other things need to react to that new feature.
> YAGNI itself is badly designed, it gives the wrong answer. It should be "Build Thing Carefully": no abstraction if no argument, abstraction if no good argument beyond "YAaGnNIii".
YAGNI is not a case again against abstraction. It’s a case against features. You can always design code to modularize and decouple an implementation from where it’s used. What you don’t do is creating extra code for things that are not needed yet.
Why? Because anything that is going to be needed between now and that X moment in the future will have to take your design into account. The cost may be negligible, but often it’s not.
IMO, there’s no argument that can stand against “This is not part of the current requirements”. Solving future requirements ahead of time is a fool’s errand. But you can always make the current design flexible enough for future changes.
The first paragraph is exactly what I've observed that make me think YAGNI is a bad practice.
3 weeks is very short, it's basically next Sprint. This stupid developer is, without flinching, saying, "we may (or may not) already know that what we are building during this sprint will not be suitable to next sprint, but let's build it anyway because YAGNI".
How is that not stupid? Just clarify. Just say "oh? ok, maybe it is a good idea, let's have a look". Don't interrupt with "YAGNI" like it is done in the article. And don't pretend that this is smarter than doing exactly the equivalent stupid thing of jumping into over-engineering without checking.
It is really crazy to me that people don't read the beginning of this article and don't scream "WTF, why is this dev so stupid".
Don't get me wrong, maybe Chet is an idiot and came up with a over-designed solution. The problem is that YAGNI does not care: YAGNI applies both if Chet is an idiot or if Chet is a stakeholder that know better than the dev what the direction should be.
You are saying "you don’t have the full specification", but you have no idea if you have the full specification or not. The whole text is totally compatible with a situation where you exactly have the full specification, where the devs are being explained what is coming soon, and that one dev is just plugging his ears: "nanana, YAGNI, I don't want to hear what comes next".
That's exactly my problem with YAGNI: when you read this article, you should hear alarm bells. The fact that the author just chooses to not even try to check if Chet is correct or not should be a red flag. But because you have drunk the cool-aid of YAGNI, you don't even notice that the correct solution for the dev was not to flatly block the discussion with "you ain't gonna need it", but "yeah, let's discuss this, are you really really sure we will need it, are you sure it's not over-engineered. If not, great, let's do like that."
> In systems design, you’re solving problems belonging to the stakeholder, the project resources, and engineering needs and constraints. Going outside the union of those sets is overengineer, building things no one needs, costing resources that should be allocated to other things, and complicating the design because other things need to react to that new feature.
Again, I have been in these situations, and I have seen, with my own eyes, that what you say is incorrect.
I have acted as a developer, as a architect, as a stakeholder, and as an observer seeing devs and stakeholders trying to work together.
What I've observe is more nuanced than that:
- if a dev comes up with some abstraction, there is indeed some chance this is a waste of time and this abstraction is not needed
- if a non-dev pushes for some abstraction or structure, there is some chance that it is a waste of time, but also a lot of chance that it is not, and this is not negligible at all and in fact crucial for doing a good work.
- if a dev says YAGNI, there is close to 90-100% chance that they have no understanding of what is the big picture, which is a problem anyway. If they had some understanding of what is the big picture, they will not say YAGNI, they will say "oh? are you sure? it is not compatible with my understanding, but maybe I'm wrong, let's clarify".
- these devs are very very unaware of how inefficient they are. They deliver things that does not correspond to what the stakeholders wanted, but then don't have a relationship close enough with the users for them to notice that it's suboptimal, or blame it on the stakeholders or on the timeframe or on other things.
> Why? Because anything that is going to be needed between now and that X moment in the future will have to take your design into account.
But isn't that exactly the point? In this article, you and the author have no idea if the design you propose to do right now is compatible with what is needed. In this article, the author shut down the question of "let's think about what is needed", they just said "someone decomposed this piece of work into few steps, so I will do each piece blindly without looking at the big picture, because otherwise it is not YAGNI".
> IMO, there’s no argument that can stand against “This is not part of the current requirements”
You should always assume that requirements are wrong. If someone is coming to you saying "hey, I think I've understood that what is needed is ...", you should never answer then "shut up, we do the requirements blindly". If there are doubt, just clarify instead of putting your head in the sand with YAGNI.
The reason the requirements should be assumed as wrong is not because the person who came up with the requirements is incompetent, but it is because requirements are impossible to come up with correctly. Because they require the person who come up with the requirements to already know exactly all the subtleties in all areas of expertise. Imagine that person is a non-dev. They have a good understanding of what they want. But how can they know that within ThingyDB, what people call an integer is in fact what normal people will call a fraction. So they say "we want an integer", and the devs deliver something that return a fraction. And if the non-dev says "it's not what I had in mind", then the devs will say "well your requirements were bad". Both it cuts both way: it is also not the devs fault if in their context, "integer" means that specific object. Both interlocutors don't know what they don't know. They cannot write requirements where every single word is over-defined just in case.
(And if you have the opportunity, ask a dev team to come up with requirement outside of their subject of expertise, it is usually hilarious. But also a really good eye-opening exercise for these devs who were condescending towards the non-devs)
This is an obvious case to illustrate, but this is very close to what happen in practice. An example I have in mind is between the Project team, where they collaborated with "organisation", which are just other partner companies, and the Dev team, where they had "organisation_id" used for authentication. And of course, no one noticed that the same company would have several organisation_id because they had different project and different contact person. The devs were convinced that several entities that were in fact the same organisation (according to the common sense definition) were, according to them, several different organisations.
You are constantly ignoring the main point: There’s a simple solution for today’s requirement, and there’s a complicated solution that will also solve a future, not existing yet, requirement. Chet want to write the later, not the former.
The complicated solution is trying to solve two problems at once, and one of them does not exist yet. It’s speculative.
> The fact that the author just chooses to not even try to check if Chet is correct or not should be a red flag.
Chet himself says that the thing will be necessary 3 weeks from now, implying that it’s not necessary today.
You can anticipate changes and plan for it. You can brainstorm it. You can even question the current requirements. What you don’t do is solving something that does not exist.
When we say YAGNI, that means the problem you’re stating, even when reasonable by itself, does not apply to the current context. It’s easier to revise a simple design later when needed, than refactoring a complex one that have a flawed assumption.
I think you're missing the point of the poster you are replying to. You make it sound like 3 weeks is 3 years. It ain't.
Very little, or possible nothing at all, is going to change in 3 weeks. If you are that myopic - as the XP people were - then constant failure is not going to be surprising. It will be expected.
It’s not about the specific timeframe. It’s about something that has no value for today’s context superseding something that do. It’s ok to anticipate changes, it’s not ok to act as if they’re already here when it’s clear that they’re not.
And the other axis is the lean towards complexity.
Let’s say you need to add logging for a web app to be able to quickly troubleshoot it. The design was to create a simple module that printf to stderr. But then the dev comes to you with a new complicated design involving elastic search and what not, saying that we will need it in 3 weeks to dissect the logs, etc. It may have been a good idea, but it’s not valuable. The correct idea is to put that on the backlog, not to start writing code for it.
Implementing complicated idea takes more time than implementing simple idea, while the value is the same.
When there’s a need for having something elastic search for the logs, it will be easy to refactor the simple code that we have than fixing the possibly flawed implementation that would have resulted if we went with the complex design.
> It’s about something that has no value for today’s context superseding something that do.
But this is incorrect. Chet is saying "if we interpret today's requirement this way, what we do today has no value, if we interpret today's requirement this other way, what we do today has value". (and if he is in fact not saying that, the problem is that you and the author have no idea if he was saying that or not, you just saw "3 weeks" and concluded, incorrectly, that it is not about today's requirement)
Please check my other comment for an illustrative example.
> Implementing complicated idea takes more time than implementing simple idea, while the value is the same.
That is factually not true. Take my illustrative example of my other comment: Day 1 requirement has ABSOLUTELY NOT VALUE if the devs that implement it don't listen to someone who said "in Day 5, we will be in this situation, so Day 1 requirement has only values if done this way and not that way".
> Let’s say you need to add logging for a web app to be able to quickly troubleshoot it. ...
Your example does not prove anything. We here all agree that over-engineering is a bad idea, and we can all come up with example where it is done.
What you need to do, is to demonstrate that ignoring what we already know for sure will happen in 3 weeks will never be less efficient than taking 5 minutes to pick the correct solution between two simple solutions, one compatible with in 3 weeks and one not.
This is how you demonstrate. If you say "f(x) is always positive", the demonstration is not to present some x values that are positive, the demonstration is to find a way to show that there is no x values for which f(x) is negative. If you restrict yourself to "let's assume that Chet solution to be compatible with the situation in 3 weeks is complex and will not be needed", of course you will conclude what you conclude. What you need to do is to convince us that it is impossible to have a situation where the information of what will be in 3 weeks will never be useful.
Because this is the point: in the situation in the article, the author has not enough information to know if Chet solution is complicated or not something needed. In fact, according to Chet, it is something needed, and the simple solution has therefore __zero value__.
> Chet is saying "if we interpret today's requirement this way, what we do today has no value, if we interpret today's requirement this other way, what we do today has value".
He is certainly not saying that. The premise is that the simple thing has value for today, the complicated thing has value for today and in 3 weeks time.
> than taking 5 minutes to pick the correct solution between two simple solutions, one compatible with in 3 weeks and one not.
The choice is between a simple solution that will solve today’s issue and a complicated solution (which will take more time) that will also solve an hypothetical situation in 3 weeks.
> in the situation in the article, the author has not enough information to know if Chet solution is complicated or not something needed.
The premise of the article is that the solution is indeed complicated and not something needed today. You may have also been in similar situation. You don’t invalidate an argument by pointing that the premise isn’t true when there’s no argument made that it will always hold true.
Saying that P imply Q, does not mean P is always true.
My criticism against YAGNI as a sane approach is not that things cannot be out-of-scope or over-engineered. My criticism against YAGNI is that it teaches developers to be unable to see a situation and think "yeah, maybe it's a bad over-engineering thing, or maybe it is not". It teaches devs to read __everything__ as bad over-engineering.
In your comment, you are showing exactly that. If you are not "contaminated" by YAGNI, you will look at the situation as described and not jump to the conclusion that "the premise is obviously that ...".
Here, you are saying "He is certainly not saying that". But if you look exactly what he is saying in the dialog, he MAY be saying that, but he also MAY NOT. This is my criticism: YAGNI trained you to misinterpret.
In your other comment, you say that Chet ask for developing something for "a powerful engine as the user may like to go offroad with a trailer". Where this even come from? Are you really unable to mentally conceive, in your head, a simple situation where Chet is talking about the exact motor that was planned from the start?
You are saying that Chet is talking about a motor for going offroad with a trailer, and yet, in the article, Chet says "but in 3 weeks that will be insufficient so since we’re going to need this" followed by "You don’t understand. We’re definitely going to need it. See, here’s an example…" followed by "But we really are…".
And at no point, absolutely no point, you thought "wait, maybe Chet is not being excited by a crazy hypothetical situation, maybe Chet is just talking about something ... we are really going to need it ... because it is in today's project goal, because it is just written that it is what we need to build and what the users are asking for".
You keep saying "the premise", but "the premise" is my criticism. I understand that the author is presenting the situation as if Chet is getting out of scope and uselessly complex. My criticism is that in the described situation, the author should recognised that this premise is just an assumption, and that he should ask for more information.
Maybe another example to illustrate. "Hello, my name is Bill, and I really think it's a bad idea to put wall paint in food. Let's take this situation, my friend Bob is coming to help me to cook, and he says "oh, I think it would be better if this birthday cake was more colorful". I immediatly said "Nope, No way", I knew he wanted to add wall paint in the cake. Bob said "maybe we can go to the shop and get ...". "No" I interrupted him. I would not go to the DYI shop to buy wall paint, it's ridiculous."
According to you, you are saying "well, it is the premise of the article that Bob want to use wall paint in the cake". But beyond the premise, this article still shows that Bill has a totally useless and strange reaction: normally, Bill should not have jumped to the conclusion that Bob want to put wall paint in the food.
Well, this conversation with you is a good illustration of why YAGNI is a terrible idea. In this whole conversation, you really struggled even conceive a situation where someone like Chet will use the same language but will not want to replace the project motor for another one to do offtrail with a trailer, but was simply talking about the motor that was planned all along in the project.
Unfortunately, because of YAGNI, there are more and more devs that are unable to see useful discussion without jumping on the conclusion that the whole discussion should be discarded.
> You keep saying "the premise", but "the premise" is my criticism. I understand that the author is presenting the situation as if Chet is getting out of scope and uselessly complex. My criticism is that in the described situation, the author should recognised that this premise is just an assumption, and that he should ask for more information.
There’s a premise that you know can be true. There’s a logical reasoning that you don’t seem to be against. There’s also a conclusion that you also don’t disagree in your comments.
If the whole thread is you arguing about the premise and saying there may be a chance of it not being true, then this is not a discussion. It’s speculative fiction.
> If the whole thread is you arguing about the premise and saying there may be a chance of it not being true, then this is not a discussion. It’s speculative fiction.
But it is a really concrete question. Me or other people may be in Chet's situation, so it is important that you just not answer "if you are not over-engineering, then it's a different premise, so it does not count, you don't really exist".
We both agree that over-engineering is bad. I guess you agree that sometimes, someone may propose a different solution that is not over-engineering? My question, and it is not a trick question, is: can you explain me what this person should do in this situation.
It is not a trick question, it is real: my impression from this discussion is that if I'm in a situation where I have a constructive proposal, not out-of-scope, totally within the project goal, that will help the situation reaching its goal more smoothly, then whatever I say, you will just answer me "you ain't gonna need it", the same way the author did to Chet.
Let's imagine that Chet is speaking to the author of the article, and let's imagine that Chet does not want to plan for a new offroad motor pushing a trailer. Let's imagine that Chet is talking about the current project, its exact current goal, that within this project, they plan to use a standard Sedan 500 pounds engine, and that Chet is charged by the author of the article of installing wheels, but that the author has chosen a simplistic approach and that, as a consequence, these wheels will not be able to support a 500 pound engine. For example, the author of the article has asked Chet to do a "simple-on-axle-mounting" approach, and that car engineers have demonstrated that for more than 400 pounds engine, you need a more complex "double-corkscrew-mounting" (I made this up of course). Installing the wheels is the current task, and installing the engine will happen in 3 weeks. How can Chet approach the author of the article?
In the article, Chet approach the author by saying "I could do this simplistic thing now but in 3 weeks that will be insufficient so since we’re going to need this more complicated thing I want to do it now". What should have he said instead? Why this sentence is bad and what make this sentence sounds like Chet is talking about something out of scope? The author does not know that the "simple-on-axis-mounting" approach is discredited. What in this simple sentence informs the author of the article that Chet is not trying to inform them that this approach is not correct and that he is instead talking about out-of-scope over-engineering?
Your example does not work with the article because the simplistic approach is already proven to be an ok design. The wheel will support the engine. The complex approach (maybe a non standard suspension) is for an hypothetical scenario that Chet believes will occur in 3 weeks. That scenario is not the mounting of the engine which is already planned and scoped.
You don't delay a project because of an hypothetical scenario. What you do is evaluate and present the risks and a possible solutions. You don't rush in the implementation unilaterally. That's a cowboy mindset.
> What in this simple sentence informs the author of the article that Chet is not trying to inform them that this approach is not correct and that he is instead talking about out-of-scope over-engineering?
I could do this simplistic thing now
That means the solution is OK and the implementation will provide some value for the customer.
but in 3 weeks that will be insufficient
How does he know that? Where's the argument, not merely examples as in the rest of the dialogue, but real objective facts and numbers (like there's another requirement that the customers are pressing us). It's very likely that any such situation would have skipped past by when designing the simple approach.
so since we’re going to need this more complicated thing
Will we really need it? We know that we don't need it today. What will change in a few week that will make it a requirement? Again what needed here is objective facts. Not what-if scenarios.
I want to do it now
Why the rush? Why can't it wait for 2 weeks when we can tie the feature to the name of few customers (assuming it's B2B) or market analysis. Why do we need to spend let's say a week on this complicated approach when we can solve the problem in a day or two and ship it.
That's all the questions I would have asked if I was not familiar with the project. But if you're the project lead, the only thing that would have led you to question yourself is if Chet has said the simplistic approach does not work. But it does.
> Your example does not work with the article because the simplistic approach is already proven to be an ok design.
Where is it done? No where in the article the author said "Chet said it will not work in 3 week, so I demonstrated that it will work in 3 weeks". The author just __assume__ it is an ok design.
What I'm telling you is that you and the author are acting in a way that shut down the conversation in case you are right AND in case you wrong.
Your answer to that is "I'm mentally impossible to conceive a scenario where the author missed something, did not realise the 'simple-one-axle-mounting' approach will fail". That is such a red flag.
> The complex approach (maybe a non standard suspension) is for an hypothetical scenario that Chet believes will occur in 3 weeks.
This is not what I ask you. I ask you to say what Chet should say in the situation where Chet is right, where the author design is incorrect and Chet scenario is not hypothetical. You keep twisting back "no but let's just pretend it cannot happen". This is my worry: are you even able to conceive that it can happen?
> That means the solution is OK and the implementation will provide some value for the customer.
What? That is definitively not how normal people would understand this sentence. Are you a native english speaker? According to you "I could do this simplistic thing now but it would not work" is an impossible sentence? Or that this sentence is saying that the solution is OK because the sentence contains "I could do this thing"?
> How does he know that?
Well, that's the point. In this step of this dialog, you don't know yet, and yet you already concluded that Chet does not know and that you know.
> Where's the argument, not merely examples as in the rest of the dialogue, but real objective facts and numbers
Chet is introducing the problem, he is shut down before he can even give his first example. Chet may have plenty of objective facts and numbers, but the author shut down the conversation before it even happen. In this dialog, Chet is __trying__ to bring facts and numbers, starting by a concrete illustration, but he is interrupted before he can do it.
You are so full of it. You are saying "Chet did not arrive and slap the author with a book full of facts, so it is the proof that Chet has no idea of what he is talking about and should be shut down before he can prove this assumption is wrong".
> Will we really need it?
You don't know if you really need it or not, you don't know if Chet has facts and numbers. Because YAGNI is shit, you just assumed that the situation is over-engineer, while you have no idea of what the situation is and stop people who try to explain it to you.
> We know that we don't need it today.
No you don't. You just stop Chet explaining and interrupt him.
> What will change in a few week that will make it a requirement? Again what needed here is objective facts. Not what-if scenarios.
This is what I saying from the start: when Chet reacts like that, the fact that the author does not say "wait a minute, do you have objective facts" is a red flag. The fact that the author goes to the what-if scenario that his design will obviously work, without providing any objective facts, is the problem.
> Why the rush?
Where is there any rush. The situation is extremely simple. The guy say: "hear me you, I think I will be wasting me time doing this". The author answers "shut up" and __assume__ that Chet has no argument.
> That's all the questions I would have asked if I was not familiar with the project. But if you're the project lead, the only thing that would have led you to question yourself is if Chet has said the simplistic approach does not work. But it does.
I saw very experienced devs failing at that all the time. In this article, the author is assuming he has a good understanding of the project and shut down anyone who can bring important information.
Your approach: "I'm the lead, so I cannot be wrong, so I assume Chet is incorrect when he said the simplistic approach will not work" is so bad. Do you even realise that?
You are a perfect example of what I was talking about. What would you have lost in just hearing Chet out? But now, YAGNI is just shit, it pushes people to have this attitude to assume that only them know the truth.
> According to you "I could do this simplistic thing now but it would not work" is an impossible sentence?
Because that’s not what it said. If someone is talking to me, I don’t invent sentences in my head for them and assume things that they haven’t said.
That’s what you’re doing, inventing a whole situation outside of what the author described because you keep adding things that the author has not mentioned.
I have my interpretation of the dialog. And I agree with the author that Chet should focus on the simple thing now, and je can always wait later to refactor it to handle the future situation.
If you want to discuss an alternate interpretation, do it within the confine of the dialog. Don’t add your own words to it.
What it said is "I could do this simplistic thing now but ... that will be insufficient"
It LITERALLY says that it will not work, that it is not a good solution.
Even if Chet is wrong in his prediction, you quoted Chet and pretended that this thing that Chet is saying is a proof that this solution will work. This is so obviously not at all Chet's opinion.
And I'm sure you are going to INVENT "but Chet does not know what will happen in 3 weeks". Firstly, again, your "proof" is a quote from Chet, who, according to you, demonstrate that this solution is ok while that sentence is used by Chet to explain that the solution is not ok. But secondly, you have no idea why Chet is saying what he is saying, you INVENT that Chet does not know, does not have facts and numbers, while there are tons of real life example where it is easy and correct to predict that in 3 weeks something will not work anymore.
> ... inventing a whole situation outside of what the author described ...
I don't.
In the situation described by the author, is it true, is it factual that Chet thinks it will not work: YES, he is saying exactly that.
Is it factual that Chet is trying to provide more information but the author shut him down before hearing them: YES, this is factual.
Your only little argument is "let's imagine that Chet proposal, that he NEVER explains because he is interrupted, is bad". All I'm saying is that you have no idea what Chet argument is, you just assumed. This is fact. Can you tell me where, factually, in the written dialog, Chet explain his understanding and this understanding is indeed incorrect? Can you point me to these sentences? They don't exist.
You see "3 weeks" and concluded that "it is out of scope and/or over-engineered", which is obviously a bad conclusion as it is very easy to find plenty of example where this conclusion is totally wrong.
I don't want an alternate interpretation, there is no need for it. Does the author shut Chet down before Chet explains himself? YES. There is nothing to interpret, it's just a fact. Then, based on that, you said things that are BS, such as "Chet said '3 weeks' so it is the proof that it is out-of-scope". I then gave you a counter-example showing that your reasoning is wrong, and your only argument was "you invented this example so it does not count".
> What it said is "I could do this simplistic thing now but ... that will be insufficient"
> It LITERALLY says that it will not work, that it is not a good solution
You have a strange definition of insufficient.
> Can you tell me where, factually, in the written dialog, Chet explain his understanding and this understanding is indeed incorrect
Both the author and I never said that the complicated thing is wrong or incorrect. YAGNI is basically saying “not now”. Meaning we can revisit when the situation calls for it, but not today.
YAGNI is a matter of priority and resources allocation. You don’t solve problems you don’t have or unlikely risks.
Do you set up a cold room in your house and buy food for the next month because you know you will be hungry then? No. You buy a fridge and groceries for the next few days. Not because a catastrophic event can’t happen, but because your budget is limited and/or you have better things to do with that money.
Complicated things cost more than simple things (to build and maintain) and take longer to ship and produce value. The only reason to not go with simple thing is when it does not work, not when it’s insufficient. We already know it does not handle every little feature, but it will work for now.
You have a strange definition of "okay". "Insufficient" is definitively not okay. The definition of "insufficient" is "less than needed". How is that "okay"? And if it is not "okay", than, yes, it is not a good solution.
Thank you to demonstrate that people who pushes for YAGNI are delivering "insufficient" work and think it is "okay".
> Both the author and I never said that the complicated thing is wrong or incorrect. YAGNI is basically saying “not now”. Meaning we can revisit when the situation calls for it, but not today.
And you have no idea if the situation calls for avoiding the problem today or not today. Take back the car example: if you install wheels that are incompatible with the planned engine, you need to fix this problem __today__.
Your code will fail in 3 week because of a mistake you are making TODAY. The proof: if you install the correct wheels today, then nothing will fail in 3 weeks. The failure that will happen in 3 weeks (and it will happen: car engineers have tested it and are clear on that, it is the law of physics) is not due to a problem that was born in 3 weeks, the failure will be due to the bad decision made today. This is a TODAY problem.
Your reasoning is totally crazy, imagine if it was considered seriously: "oh, you noticed a bug in my code during code review. Well, let's ship the code in production and wait for users to raise a bug ticket, because before then, the problem does not exist".
> YAGNI is a matter of priority and resources allocation. You don’t solve problems you don’t have or unlikely risks.
And in the case of Chet, you have prioritized NOTHING. You still have no idea of what Chet was raising. You have no idea of what are the risks. You have no idea if your current plan is even the correct plan or not.
Imagine the following situation: "oh, we took the wrong road, if we continue tomorrow we will arrive in Berlin instead of Paris". Only very stupid people will say "no, that's a problem for tomorrow, let's just spend all the time in between doing something totally useless that we will need to undo tomorrow".
> You buy a fridge and groceries for the next few days.
You realise your contradiction here: you are saying you buy TODAY food for when you will be hungry IN THE NEXT FEW DAYS. According to your logic, you should not do that. What you should do is to go to the shop every single time you feel hungry and buy only one item, the one you want to eat now.
> Complicated things cost more than simple things (to build and maintain) and take longer to ship and produce value. The only reason to not go with simple thing is when it does not work, not when it’s insufficient.
Simple things that have no value at all cost more than complicated things. When Chet come up, he is saying "hey, I think I notice we are planning to build something that has absolutely no value". Your reaction is "no, it is better to do something useless with no value than something more complicated that has value".
And again, as I guess you will not get it: maybe Chet is wrong. The problem is that you just ignore Chet. Maybe he is wrong, but maybe he is right, you have absolutely not idea.
> We already know it does not handle every little feature, but it will work for now.
It will not work for now. If you install the wrong wheels on a car, the car is useless until you install the engine.
The important thing is not "the task of today", it is to deliver what the user needs. Here, Chet is saying that he thinks you are planning to build something that is a waste of time, something that will not deliver what the users need.
The reaction should be "Chet, maybe you are right, but maybe you are wrong, let's check together". Instead, the reaction was to interrupt him and act as if the users care about today's work more than the real product.
The whole car example is flawed because insufficient does not mean wrong or incorrect.
> And in the case of Chet, you have prioritized NOTHING. You still have no idea of what Chet was raising. You have no idea of what are the risks. You have no idea if your current plan is even the correct plan or not.
Why are you so sure the author cannot compare <complicated thing> and <simple thing>? Or he has not considered <complicated thing> before even Chet and discarded it?
> When Chet come up, he is saying "hey, I think I notice we are planning to build something that has absolutely no value"
You’re again inventing stuff. The simple thing has value today. It will be insufficient in three weeks. It is not insufficient today. If we implement it, the user will have a working solution way sooner instead of waiting for the complicated thing to be ready.
How do you value your user’s time?
> The important thing is not "the task of today", it is to deliver what the user needs.
What the user needs today and what it will need in three weeks are different things. You and Chet have been ignoring the user’s need for today.
If someone wants some data outside of a system and you can write a quick perl script in 30 minutes to produce a CSV, you do it. You don’t argue about setting up a whole ETL pipeline because that will be needed in 3 weeks and the perl script is insufficient. Especially when that pipeline will take days to implement. You can have a whole set of examples and what not. But we can discuss that after the perl script is written and the needed data is exported.
> The whole car example is flawed because insufficient does not mean wrong or incorrect.
In the car example, the solution proposed by the team leader is insufficient. The result is that the solution proposed by the team leader will lead to either the project to fail or to a waste of money.
> Why are you so sure the author cannot compare <complicated thing> and <simple thing>?
What are you talking about? I'm not saying you cannot compare <complicated thing> and <simple thing>, I'm saying that the author does NOT COMPARISON: he has no idea what Chet is talking about, because Chet want to explain and the author shut him down.
You cannot say that Chet's solution, which is more complicated, is less valuable than the simple solution, because you don't even know if the simple solution has any value.
> The simple thing has value today.
No, YOU DON'T KNOW THAT. You invent that. Take the car example: having a wheel but no engine has no value. There are ton of other examples: for example, if someone is talking about a bug that occur because in three weeks we are in 2026 and that the code has a bug that make the code unusable if the year is 2026. If the product is released in February 2026, then the simple thing has zero value. (that's a made-up example for the sake of simplicity, but having bad design that destroy the quality soon after is a real thing, very common)
> How do you value your user’s time?
And how do you value users leaving because in 3 weeks that see the product is not able to do something they were expecting?
> What the user needs today and what it will need in three weeks are different things.
You don't know that. In the example of the car, the user don't need a 1 wheel car with no engine.
Again, because you have no idea what Chet is talking about, you have no idea if what Chet is talking about impacts today's users.
> blablabla ETL blablabla
You keep giving example where someone over-engineer (or ask for working on something too early, or ask to work on something out of scope, or ask to adapt the current goal based on hypothetical future goal, ...). EVERYONE HERE agrees that this is bad and should be avoided. The disagreement is that in the dialog in the article, the author did a terrible job at assessing if Chet contribution was a good or a bad thing (based on these criteria), because the author has drunk the YAGNI cool-aid and jumped to the conclusion it was a bad thing while there are plenty of situations where Chet will act exactly like that when it is not some of these bad things.
(and again, my criticism is not these "bad" things are not bad and should not be avoided, my criticism is that some devs say "YAGNI" and shut down the contributions that are fully relevant to do a good job and deliver value. A simple solution is to not be an obnoxious d*khead and just listen to Chet, to check if it is a real bad thing or not, and act accordingly like an adult instead of behaving like a little kid)
PS: I note that you just ignore elements where you cannot answer. (for example, the food that you don't buy one item at the time, the fact that "prioritization" means nothing when you don't even know between what and what you are prioritizing, ...)
> In the car example, the solution proposed by the team leader is insufficient
Because you created that situation out of the blue. And you’ve been ignoring any case where both solutions do work, but one is more complicated than the other. And the simple one can be delivered very soon, but the complicated one will be useful only three weeks later,
> if someone is talking about a bug that occur because in three weeks we are in 2026 and that the code has a bug that make the code unusable if the year is 2026. If the product is released in February 2026
But the simple thing can let us deploy in 2025 and land a big contract before the holidays. Perfect is the enemy of good as we say.
> Again, because you have no idea what Chet is talking about, you have no idea if what Chet is talking about impacts today's users
It is explicitly mentioned that the complicated thing will only matter in 3 weeks, not today.
> You keep giving example where someone over-engineer. EVERYONE HERE agrees that over-engineering is bad and should be avoid.
And you keep ignoring that time matters and a problem in the future doesn’t mean it exists right now. You do the thing that matters for today, then you do the thing that matters for next week.
Your argument has been the thing that matters for today may not really matter and that is not what Chet has been saying.
I could do this simplistic thing now but in 3 weeks that will be insufficient
Insufficient in 3 weeks only matters if we can’t ship the simple thing in that timeframe. If we can do so in one or 2 days, we can then focus on the complicated thing.
And that’s assuming Chet knows more about the project constraint than the project leader. Something my be great technically, but the other perspectives that the leader have is why he is refuting it. Like he got an email this morning that we will be abandoning the project in 3 weeks but we’re contractually obligated to fix every bug. He can’t discuss that with you, but he can direct your workflow.
So the next time you hear YAGNI, ask why. Don’t rush to prove your point.
What you say if not making much sense. You don't provide counter-arguments or arguments, it looks more like a collection of special cases, but they don't contradict anything I'm saying. It's like if I say "f(x) = x - 10 can be negative, for example if x = 2" and you just say "no because sometimes x = 15". I don't get the point of your argument, you seems to say that if you find one special case that works for your conclusion, then your conclusion is correct.
For example, you just say "what if the simple thing can let us deploy in 2025 and land a big contract before the holiday". Firstly, it's a weak example, do you really believe that someone will sign a big contract with you on brand new code within 3 weeks of the release without either testing for few weeks or asking guarantee that it will still work after 3 weeks? Secondly, it's easily a bad point for your approach, what do you think will be the commercial impact when the partner will see that your code falls apart after 3 weeks because you did not anticipated something they find obvious? Thirdly, a simple tweak and it becomes an example against your approach, what if the big contract is on week 4, and that you miss it because you have to undo the simple solution and build the more complicated solution in order to have a product that work? But more importantly, it does not contradict anything I said, my approach still is better: if you have a big contract, then LISTEN TO CHET, and if what he says can wait, just say "great, noted, but we will do it after the big contract" (and if Chet has a good point, you will win bigger).
I really don't understand your point: listening to Chet has only good consequences. You listen to him, and then you still can decide if it's smarter to do it now or not.
For all the scenarios that me and you have proposed, your method keep failing my scenarios, while my method keep succeeding my scenarios AND your scenarios.
You also are hypocritical: on one hand, you hand-wave "perfect is the enemy of good" and on the other, you whine "bouhou, if we try to stay aware of the constraints that are coming our way, this is soooo baaad, we need to stay pure and perfect, this is sooo important".
About "today's user": users don't care about the code. If the plan is to work on the backend on day X and on the front-end on day X+3weeks, the fact that the code runs on day X is a negative for the user, today's user, because today's user cannot use the backend, he needs the backend and the frontend. And because you built a backend incompatible with the front-end, you will deliver even later. Another illustration is about the car example: today's user don't care about a one wheel structure without an engine, this is totally useless for them. If you successfully install the wrong wheel today, you impacted negatively today's users, because they will get their car even later.
About "time matters": you are arguing that, but you are pushing for a solution that WASTES time. Your logic is "installing the wrong wheel takes 5h, installing the correct wheel takes 10h, so let's install the wrong wheel". Except that the user will not be able to use the final product until the correct wheel has been installed, so you will use 5h to install the wrong wheel, 5h to uninstall the wrong wheel, 10h to install the correct wheel, and you will have spent 20h instead of 10h. And I know your argument, which is "I'm not talking about the car example, in my scenario, today's task is a feature that users can use directly". But my argument is that you are shit at knowing if it is the case or not. You read this article, you saw the author shutting down Chet, and not one instant you thought "ok, but of course this is terrible advise if we are in a car-example situation". I looks like this possibility flew high above your head, as I need hours of exchange to educate you on the subject.
About "you keep ignoring that ... a problem in the future doesn’t mean it exists right now": You saw "3 weeks", and you are mentally unable to realise that because the code is running today, it does not mean that the code is delivering what it is supposed to deliver. A simple example: the task is to install wheels that are compatible with the planned engine, and the team leader planned to install the wrong wheel. Someone notices and say "in 3 weeks, when we install the engine, it will not work". This is not a future problem: you have failed TODAY'S REQUIREMENT, TODAY'S TASK. The task itself requires that what you build is compatible with what will be built in 3 weeks. But because you saw "it will not work in 3 weeks", then you concluded that what you have built today satisfies the requirements. It is sometimes the case, it is sometimes not the case. And because you did not let Chet talk, you don't know what he is talking about, so you don't know if he is talking about a future problem or you having failed today's task in a way that will only be visible in 3 weeks.
About "assuming Chet knows more about the project constraints than the project leader": YES. NO ONE. NO. ONE. No one knows the project perfectly. No one will never miss something. When Chet is coming to the team leader and says "I think we may be wrong", listen to Chet. If Chet is incorrect, fine, no harm done. But Chet may not be incorrect. The team leader does not know what they don't know, they should never assume that they know more about the project constraints than the other collaborators.
And again, because I'm sure you have difficulties wrapping your head around this: I don't ignore that not all project are like a car construction. The problem is that your arguments are incompatible with a common situation. The fact that your arguments are not incompatible with some situations does not mean they are correct. The fact that they fall apart in some situations means they are incorrect.
We need to to task X today, we're going to do Task Y later. But we need both task X and task Y to complete the whole project. But the solution for task X is wrong because it conflicts with task Y. And when we get to task Y, we won't be able to deliver. And Chet know this. But the author don't want to listen to Chet, and the author is wrong for that.
While the situation is:
The project is already defined. There's task X to be done, and we have settle on a solution A for it. Chet is the one who will be implementing it. Chet uncovers a situation that leads him to believe that the solution B is better because of a constraint that will come in effect in 3 weeks. He says that he can implement A, but because we're going to need B in 3 weeks, let's scrap A and go with B instead. Now the author knows both A and B (and maybe B was discussed beforehand but Chet don't knows about it),and says that B don't matter, A is good enough.
Instead of asking why, Chet decide to argue for the validity of B. The author reiterates that B doesn't matter. At the end Chet decides to walk away. And never wanted to learn why A is the better choice when B seems to be perfect.
I was Chet at one time and never have someone like the author to rein me in. I get cured from wanting to implement complicated solution when client asked me for demos and I couldn't show anything because I was trying to solve everything. And you're right, they don't care about code. They care about working product, and today, not in 3 weeks. So between A and B, I deliver A first, then worry about B.
And when someone higher than you (and better placed to have more information about the constraint of the project) refuses your idea. You ask why, you don't immediately try to prove your position. Imagine doing that in the army.
BS. You have no idea if it is the case, you don't listen to Chet. You __assume__ that Chet's solution is motivated by a different goal, but you __shut him down before he said so__.
You now invent things that are never described in the scenario, to try to badly justify that somehow the author's ASSUMPTION is justified. But the problem is that even if what you said happened, the author's assumption is still an assumption: the author is a bad lead for not verifying at 100% that Chet is indeed talking about the same B that the author has in mind. And even if the author does it behind the scene, the author is a bad lead for not being fully aware that he should have writing this step explicitly within the scene, as it is a crucial step for the judgement and should be evaluated before acting as he did.
> Now the author knows both A and B
The author SHUT CHET DOWN BEFORE Chat explains what he is talking about. How does the author even know that Chet's complicated solution correspond to B?
I guess you will say "but Chet told him behind the scene" or a bad argument like that. Which is of course changing the scenario as described in the article (something you were incorrectly whining about but have no problem doing it yourself).
But also it justifies my criticism: even if Chet's explanation happened behind the scene, it means that when you read this scenario, instead of thinking "oh, red flag, the author should make sure he understands exactly what Chet is talking about", you just __jumped to the conclusion__ that this situation was a "constraint from a hypothetical future" situation where what you had behind your eyes gave you no indication it was. And you __invented__ without any justification, that elements that are not within the scene occurred just to justify a posteriori your conclusion.
To take a more extreme example: it is like if the article says "and then this black person is arrested", and when someone says "it is strange, I don't understand on which basis this person was arrested", and someone says "well, when reading the article, I just assumed that the black person is a thief and that they saw it behind the scene". This last person reading of the article has highlighted his prejudice, his bias. Same here: you ignored the possibility that it may be a "Task X vs task Y" situation because you __blindly assumed__ it is the situation that YAGNI has put in your head.
> and maybe B was discussed beforehand but Chet don't knows about it
And maybe the unicorns have whispered to the author's ear what Chet was talking about.
You are so full of shit, you are just making excuses and grasping straws to pretend that the terrible judgement of the author was somehow justified behind the scene. Do you even realise that?
> I was Chet at one time ...
I am not surprised at all. But the problem is that not everyone is as bad developer as you are: sometimes, they found __proper problem__. In the exact dialog, the author shuts Chet down before he can explain the problem. Chet even said "you don't understand ...", trying to say to the author that what he is bringing is not what the author seems to understand it is. That in itself should give you pause: "wait, are we sure Chet is not trying to talk about a problem that the author genuinely missed", but it did not because you were unable to mentally conceive it may be the case.
> And when someone higher than you (and better placed to have more information about the constraint of the project) refuses your idea. You ask why,
Again, if you are a team leader and you think that you will never miss anything or that you are the only ones in position to discover things that has been missed, then you are such a shit team leader. With a fragile ego.
> Imagine doing that in the army
WTF? What kind of argument is that? Your argument seems to boil down to "reSPecT my auTHorItaaa". As a team leader, I am smarter than that: I know that sometimes things will be missed, and I know that it is better for everyone to be in a situation where anyone can bring it to attention.
And, yes, sometimes they will bring to my attention things I already know. But I listen to them first. It does not change ABSOLUTELY ANYTHING, and if someone says the opposite, this person is full of shit and does not know what they are talking about.
YAGNI means you ain’t gonna need it. And if you can’t ask why A stays and B can’t be accepted, that just means you believe your reasoning is always the correct one, and your team leader is an wrong to not accept it.
And as I’ve said. If you state something and the person in front doesn’t accept it, you ask for his reasons. You don’t rush to prove yours.
You really can’t accept that the author knows about B and have a valid reason to not choose it, evenk if B is completely valid? Software engineering is all about tradeoffs. And it’s on the leaders to choose some, even if you really believe it must lean the other way.
> And if you can’t ask why A stays and B can’t be accepted, that just means you believe your reasoning is always the correct one
What? Why are you saying "if you can't ask why"? I personally can ask "why", there is no problem with that. I have been in situation where I was the lead and I had to say no to someone like Chet and I've done it after listening to him. And I've been in situation where I was the lead and I listen to Chet and Chet had a good point that was useful, and I used this point to reassess my decision, and sometimes I change my plan, and sometimes I did not. And I've been in situation where I disagreed with the lead but said "ok, you're the lead, we should not flip-flop between captains, we need one person at the driving wheel, so I accept your decision". Why are you inventing that it is a problem to me? Can you provide the sentence I've written that led you to that conclusion?
But in the article, in the scenario, the author never ask "why". Chet arrived and said he thinks there is something suboptimal, and the author did not say "why", he said "YAGNI", and Chet tried to discuss this and the author did not say "why", he said "YAGNI", and Chet tried to have the author explain why, and the author did not say "why", he said "YAGNI".
The author __REFUSED__ the discussion. Chet did not even had the opportunity to say "why".
> If you state something and the person in front doesn’t accept it, you ask for his reasons.
It is what Chet is trying to do. Chet does not say "no, you are wrong", Chet tried to discuss this: he wants to explain his argument to know what are the author reason for possibly refusing. Chet suspects that the author does not understand, he tries to clarify, to give example, but the author just refuses.
> You really can’t accept that the author knows about B and have a valid reason to not choose it, evenk if B is completely valid?
Why are you thinking that? The problem is not that I believe the author is wrong about B. The problem is that the author has assumed Chet was talking about B when this is only an unsubstantiated assumption.
Look at what I've written, I've written explicitly:
> You listen to him, and then you still can decide if it's smarter to do it now or not.
If you decide "let's not do B" and Chet says "no, I refuse to accept that", then Chet is 100% wrong.
The problem is that the author decided that Chet was talking about B __before Chet even explain what he is talking about__.
Again, if the author has good reason to not do B, then, I FULLY AGREE WE SHOULD NOT DO B. The problem is that the author is an idiot: Chet tries to talk to him about something, and the author just assumes, without any proof, that it is about B.
> Software engineering is all about tradeoffs. And it’s on the leaders to choose some, even if you really believe it must lean the other way.
A leader that choose between tradeoffs when he __refused to listen to the information__ is a bad leader, and his work will be poor.
Let's take your logic further: why providing any information to the lead at all? The stakeholders approach the lead and say "hello, we would like to have a feature, this will be ...", lead: "STOP! This will be a frontend interface with an animation of a little frog dancing", stakeholders: "what? no, we would like ...", lead: "no, you want that", stakeholders: "but you don't understand ...", lead: "good meeting, byyyye".
Honestly, your position is so weak. My question is "what's the problem with just listening to Chet to understand what he is talking about", and your position is so poor that the only thing you were able to do is to say "no because if I listen to Chet, it means Chet refuses my decision", which is blatantly incorrect.
> There’s a simple solution for today’s requirement, and there’s a complicated solution that will also solve a future, not existing yet, requirement.
There are tons of examples that show that your reasoning is incorrect.
Let's invent one: you need to build a car. Day 1: put the front left wheel on the frame structure. Day 2: put the front right wheel on the frame structure, Day 3: put the back left wheel on the frame structure, Day 4: put the back right wheel on the frame structure, Day 5: attach that particular motor on the frame.
Now, you are on Day 1, and Chet arrive and say "this wheel will not do, it will never support the motor that we need to install on day 5".
You are telling me that what Chet said is to be ignored because "it is a requirement for day 5". But it is not. What Chet has done is not bringing a requirement of day 5 into day 1, what Chet has done is that it has noticed an incorrect interpretation in Day 1 requirement. The requirement for Day 1 should have been read as "put the front left wheel on the frame structure, but of course, it goes without saying, use a wheel that is compatible with the car we want to build".
You saying that because Chet is using Day 5 information, the point he is making is not about Day 1 requirement is incorrect.
The thing is: Day 1 requirement and Day 5 requirement don't live on their own. Hell, your job is not to "just do Day 1 requirement" and it has never been. No one, absolutely no one, want a frame structure with just one wheel and no motor.
In the article, Chet does that: he tries to send the message "this is the point of the work, we will need it, it is what we plan to build, so you need to take that into account in today's requirement interpretation. If you don't account for it, you better not even do today's requirement".
And, and let me be clear on that, maybe the element that Chet brings will end up being not relevant or not needed. But the problem is that neither you or the author know that yet, and you reject the discussion before you can even discover if it's the case or not. The problem is that author and you just saw "Day 5" or "in 3 weeks" and, because YAGNI is a terrible advance, jumped on the conclusion "it is in the future, so it has nothing today with today's requirements".
(oh, and in practice, the people who says "YAGNI" will then say "well, the problem is Day 1 requirement, each requirement should go into excruciating details to re-explain the whole point of the work, should think of all the possible interpretation and should be written by someone who know better than me how to build the implementation to each line of code, but somehow should waste their time explaining the project to someone less competent".
Again, the problem with this argument is that the solution of "use your brain, build things carefully" creates a way easier and elegant solution than YAGNI+ridiculously unrealistic requirements.)
This is where the disagreement comesfrom. You have a different interpretation of requirements. A requirement is not a list of tasks. It’s a set of needs and constraints that drive a design.
In your example, the general goal could be to do a small sedan car, but then Chet come in and say that we need a more powerful engine as the user may like to go offroad with a trailer. And he’s ready to cancel the order for the standard engine and ready to adjust the chassis, the frame,… for the new engine.
But the thing is that there is no such requirement in the design, no hard data that says that user would like such data. It’s just anticipating needs without proper market research.
And as I’ve said previously, it’s okay to explore design for a more complete solution. It’s not okay to commit to them with just an emphasis on the benefits, nit the cost of maintenance while there’s no value to the business.
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.
That's interesting, because it's not my experience. A lot of the technical debt I see is that someone half-assed something thinking it would be easy to improve later, but the layer violations and inadequate tests make doing so a massive project, once it's become load-bearing.
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.
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.
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.
IMHO that's like saying we mustn't say "roof" because it's made of smaller parts and only those parts are allowed to have names. Not to mention the languages themselves have some of the patterns.
This was the issue with the early agile-developed systems.
Not that they didn’t write no code, obviously, but they didn’t understand the domain and so YAGNI’d everyone to death. As a result there wasn’t enough code for the system would do what it needed to do.
The code was simple and highly testable, but didn’t actually do the job.
The original Agile poster child, Chrysler Comprehensive Compensation System (C3) was never very successful as a project. It achieved only a fraction of its goals and was ultimately cancelled.
YAGNI in that context is hilarious, because they were replacing an existing COBOL based payroll system. They literally needed pretty much everything the old system did to be successful. Part of the failure is because the devs did not understand what they were replacing.
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.
> 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.
Ironically, AI assisted/generated code is not trending in the direction of the ability to safely and quickly change. Especially when piloted poorly
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.
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.
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.)
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
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.
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.
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]
>> 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.
> 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.
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.
> 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.
> 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.
> 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.
> 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.
Over the last couple months I've seen the debt multiplication in some OSS projects. It's like premature aging of a codebase.
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
> 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.
> 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.
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.
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.
> Kent Beck compares unwritten code with a financial option to buy something at a given price.
From Kent's "Tidy, First?"
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.
What corresponds to owning an option?
Again from "Tidy First?"
So, there's some behavior of the software that we may want which correspond to the underlying of the option. That behavior will have a value for to the business later which is it's price (can be 0 or negative). We can spend time and money to create its scaffold (the premium). The duration is how much time we can spend with the scaffold especially if it raise the cost of other behaviors.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.
This "scaffolding" sounds like some kind of code that you've written that you don't need yet? What's an example?
Also, in the current article, it sounds like he's using "option" as a metaphor for something different?
> Building early spends that option. You exercise it before expiry and throw away the time value.
In the financial world, you need to pay to own an option. The "option" he is talking about, you paid it in terms of time to construct the scaffolding.
You need a feature F, you can build feature F directly (no options, just creating what is valuable today). One example is using an external dependency directly in your business logic.
You can also build enough abstraction so that feature F is decoupled enough from the rest of the project that the latter only have a logical view of it (which hardly changes). That can be done cheaply, making it easier to easily modify the code according to the business logic. You just go a little further than the previous version, but without really committing to the anticipated changes. Like hiding the dependency behind an interface of your choosing.
You can also over engineer the solution anticipating changes that are not likely to happens (buying options at very high cost). One example is writing an ORM layer because you may need to switch from sqlite to SQLServer. Or writing an agnostic UI library because you may need to support everything from HTML to raw OpenGL and ncurses. The issue there is that there's no requirements (from stakeholders) or business values in supporting those use cases.
> > Building early spends that option. You exercise it before expiry and throw away the time value.
In the last case, you've written code, aka consuming time and money, for a scenario that is uncertain. And even if they do realize, your code would likely be worthless as the assumptions behind it does not match the real requirements. The threshold between the last and the second case is that in the latter, you're not committing to the future design. You're laying some groundwork that leave future work, when needed, easier to accomplish.
(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.
> 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.
>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.
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.
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.
> 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.
Then again, this goes completely against the "O" in the SOLID principles (and possibly also the "D" too).
Personally I prefer SOLID to YAGNI.
> 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.
> 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.
AI 2026 still uses em dash. Next year, no such luck.
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.
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
Yes, it does:
> a genie-generated description of YAGNI intended for the improvement of future generations of genies
Thanks. I missed that.
It’s half a sentence to be fair, easy to miss!
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)
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.
"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.
> 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
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.
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.
> Well he makes software and writes about software development doesn’t he? Hardware has some hard limitations.
Right.
> The reason software was even invented at all was precisely to escape those limitations.
But the methods which are useful for hardware are also often useful for software. Most of the useful parts of agile were already practiced well before that was a name for anything. And the demonization of the straw-man version of waterfall in order to sell more agile consulting has led to some serious misconceptions of what waterfall really is and what it is really capable of and useful for.
The initial impetus for what became known as TDD was software maintenance, and it makes sense there.
But most TDD practitioners are nowhere near as good at real testing as the waterfall test practitioners who understand that a single missed testcase could delay a $10 million project by six months.
And this is why, even in the realm of software you still see serious efforts for aviation and nuclear power plants, and other things with real-world consequences, using more traditional methods.
I have not seen Kent Beck argue for eXtreme Programming or other Agile methods in nuclear power plant software or aviation. These are niche industries and constitute a vanishingly tiny part of all the lines of code out there I presume.
The fact that short iterations adding features incrementally leads to better outcomes for software project is something professionals have known and argued for since the 1960s.
> The fact that short iterations adding features incrementally leads to better outcomes for software project is something professionals have known and argued for since the 1960s.
And practiced by software professionals since the 1960s. For maintenance. Even for aviation and nuclear. But in those industries, you're going to have a clear case, better documentation, and not be trying to "sprint."
Again, many truly best practices well predated XP/agile, and were subsumed into it. The real problem with XP/agile is the dogmatic straw-manning and demonization of other good practices that have their place, such as waterfall and exploratory programming. YAGNI, in particular, is more often used as a cudgel to shut down useful learning and exploration than anything else.
> 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.
> 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.
Interesting. How do chip companies plan such projects? Do they use agile, waterfall, or some other non-software-industry frameworks?
(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.
Just to point, but shifting left isn't agile at all. In fact, it's slightly against development agility.
It's just a good engineering practice, that is more than useful enough to compensate for any loss of agility it may cause.
On the one hand, I agree.
On the other hand, like a lot of other good ideas, the agile community has claimed this. A quick google will show that many claim it is a "core agile idea."
It’s absolutely an agile idea. The core of agile development is the ability to iterate quickly. Shift left for certain things enables the cycle to shorten and accelerate iteration.
The useful core idea of "shift left" is early collaboration between development and various testing functions.
But, again, that was being done in many organizations (and for sure, in most successful chip companies) well before anything was ever labeled agile.
I agree that it was done by many organizations before “agile” but that’s true of all agile practices. Agile is a philosophy and a collection of tools. None of the tools are new though.
> that’s true of all agile practices
Which is what, honestly, makes the term essentially meaningless.
To the extent that parts of agile are and have always been "best practices" we already had a term for those.
They (or at least some of them) use waterfall - the real waterfall, not the bogeyman invented by agile consultants.
[dead]
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
https://en.wikipedia.org/wiki/You_aren't_gonna_need_it in case anyone else was wondering
https://c2.com/xp/YouArentGonnaNeedIt.html on the original Wiki.
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.
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.
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?
> 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.
[flagged]
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.
This sounded like generated text to me. "The gap" etc
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.
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.
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.
[flagged]
You can't post like this here, and we ban accounts that do, so please don't.
https://news.ycombinator.com/newsguidelines.html
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”.
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.
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 will never be needed in the end.
* Create abstractions for something that will be needed but not in the form they initially expected.
It is not about avoiding refactoring. That misses the point entirely. Refactoring cleans up code mess that exists NOW - creating abstractions for somehting that exists NOW.
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.
It's predicting that you will predict wrong frequently enough to make it not worthwhile predicting at all.
I apply the same logic at slots: the way to win is not to play.
>Creating abstraction for a code that was designed without being compatible with these abstraction has a huge cost
I have never found it more expensive to create an abstraction after following the rule of 3.
Indeed, ive always noticed that abstractions which are front loaded are nearly ALWAYS worse than abstractions built with hindsight.
>As I've said, nothing is all white or all black. The problem with YAGNI is the developers think it's all white
We think you're playing slots and remembering only the wins, believing that you're just naturally talented at predicting the future.
Ive seen this attitude in hundreds of devs. They all think theyre uniquely able to anticipate the code base's future needs.
> 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 invent a rule that says "just don't build". The solution is to stop having developers thinking they know what is useful or what is not.
> Indeed, ive always noticed that abstractions which are front loaded are nearly ALWAYS worse than abstractions built with hindsight.
Again, you cannot know if it is worse or not. You are not the user. It may be good in some cases, it may be bad in other, and I have seen devs saying exactly what you said when their "abstractions in hindsight" was catastrophic.
There is a lot of example, but just one: we built a system that was collecting data, the goal being to accumulate data for months and then analyse it. Few people involved in the project proposed some structure for the data, but the devs used YAGNI to do what they preferred (there was some objection but at the end, the devs just did what they wanted to do, ignoring the rest of the team because they were confident that they knew more than them how to build software). Later, we started the analysis, and realised all the data were crap: the devs kept changing the data structure by building their abstraction with hindsight, without even documenting when these modifications were deployed to the different sensors. We had a mix of data built based on different parameters with no way to know which part was using which parameters.
After the project failure, I saw many devs still saying that they were right to use YAGNI, and being totally oblivious that it's their choice that doomed the project. They were, seriously, saying that it was a lack of requirement, or that the "users changed their mind", while it was not true at all (I was there, and I was not in either side, I just observed), the situation was well known from the start. The problem was they insisted to apply YAGNI as if they understood better than the other collaborators what as needed.
> We think you're playing slots and remembering only the wins, believing that you're just naturally talented at predicting the future.
You literally just said "ive always noticed that abstractions which are front loaded are nearly ALWAYS worse than abstractions built with hindsight".
This is literally you remembering the amount of "win" and the amount of "loose".
> Ive seen this attitude in hundreds of devs. They all think theyre uniquely able to anticipate the code base's future needs.
That's exactly my point (and I'm not a dev).
When you are saying "abstraction is better built in hindsight", you are just thinking you are smarter than other people.
When the situation is that it is difficult to understand what we will need, the solution is to discuss together to understand what we will need. We may get it wrong sometimes, but we will get it right sometimes. If someone just decides to ignore other collaborators opinion and decides "we will need this abstraction", this person has way more chance to be wrong. If someone just decides to ignore other collaborators opinion and decides "we will not need this abstraction", this person has way more chance to be wrong too.
YAGNI is just someone noticing that building a big house without following the plan led to extra work because they have to demolish the bits they've built on next door property, so they decide to build a small house without following the plan.
>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 anticipate what architectures or abstractions might be needed in the future.
>Again, you cannot know if it is worse or not.
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.
It was hard experience that taught me that it was pretty universal.
> My judgement is based upon my experience trying it both ways many times over the course of decades.
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.
YAGNI is mostly an answer to someone that says "let's create this abstraction", but can't argue why it's really needed. If you can't argue about why you need an abstraction, the best strategy is to not create it. Because removing it afterwards may be more costly than implementing it (if it ever get done).
It's not an objective answer that "you really not gonna need that". It's more "No clear explanation about that abstraction? You ain't gonna need it".
Look at the article itself:
> Chet said, “You don’t understand. We’re definitely going to need it. See, here’s an example…”
> Me (interrupting), “You aren’t going to need it.”
> Chet, get frustrated, “But we really are…”
> Me, “You aren’t going to need it.”
This is a clear example of YAGNI being used when the dev, actively, does not care if the other person has any argument to defend it will be needed.
YAGNI itself is badly designed, it gives the wrong answer. It should be "Build Thing Carefully": no abstraction if no argument, abstraction if no good argument beyond "YAaGnNIii".
And I know devs would just say "but devs who don't listen is super rare", but it is not true: you probably read the article and did not flinch, not noticing that it's a clear situation where the dev actively refuse to listen to the arguments. How many time did you witness or participate to such situation and still think it never happens?
At the end, I don't understand: just do "Build Thing Carefully", where what you built is well-thought, and not only you get YAGNI for free, but you also avoid the problem with refusing to build something that is needed.
> This is a clear example of YAGNI being used when the dev, actively, does not care if the other person has any argument to defend it will be needed
The first paragraph set the context
You can solve today’s problem and do some groundwork to extend later. What you don’t do is solving today’s problem with a solution for a future problem.Whatever complicated thing that may be wanted, meaning you don’t have the full specification, as it’s not a current problem for a stakeholder.
In systems design, you’re solving problems belonging to the stakeholder, the project resources, and engineering needs and constraints. Going outside the union of those sets is overengineer, building things no one needs, costing resources that should be allocated to other things, and complicating the design because other things need to react to that new feature.
> YAGNI itself is badly designed, it gives the wrong answer. It should be "Build Thing Carefully": no abstraction if no argument, abstraction if no good argument beyond "YAaGnNIii".
YAGNI is not a case again against abstraction. It’s a case against features. You can always design code to modularize and decouple an implementation from where it’s used. What you don’t do is creating extra code for things that are not needed yet.
Why? Because anything that is going to be needed between now and that X moment in the future will have to take your design into account. The cost may be negligible, but often it’s not.
IMO, there’s no argument that can stand against “This is not part of the current requirements”. Solving future requirements ahead of time is a fool’s errand. But you can always make the current design flexible enough for future changes.
> The first paragraph set the context
The first paragraph is exactly what I've observed that make me think YAGNI is a bad practice.
3 weeks is very short, it's basically next Sprint. This stupid developer is, without flinching, saying, "we may (or may not) already know that what we are building during this sprint will not be suitable to next sprint, but let's build it anyway because YAGNI".
How is that not stupid? Just clarify. Just say "oh? ok, maybe it is a good idea, let's have a look". Don't interrupt with "YAGNI" like it is done in the article. And don't pretend that this is smarter than doing exactly the equivalent stupid thing of jumping into over-engineering without checking.
It is really crazy to me that people don't read the beginning of this article and don't scream "WTF, why is this dev so stupid".
Don't get me wrong, maybe Chet is an idiot and came up with a over-designed solution. The problem is that YAGNI does not care: YAGNI applies both if Chet is an idiot or if Chet is a stakeholder that know better than the dev what the direction should be.
You are saying "you don’t have the full specification", but you have no idea if you have the full specification or not. The whole text is totally compatible with a situation where you exactly have the full specification, where the devs are being explained what is coming soon, and that one dev is just plugging his ears: "nanana, YAGNI, I don't want to hear what comes next".
That's exactly my problem with YAGNI: when you read this article, you should hear alarm bells. The fact that the author just chooses to not even try to check if Chet is correct or not should be a red flag. But because you have drunk the cool-aid of YAGNI, you don't even notice that the correct solution for the dev was not to flatly block the discussion with "you ain't gonna need it", but "yeah, let's discuss this, are you really really sure we will need it, are you sure it's not over-engineered. If not, great, let's do like that."
> In systems design, you’re solving problems belonging to the stakeholder, the project resources, and engineering needs and constraints. Going outside the union of those sets is overengineer, building things no one needs, costing resources that should be allocated to other things, and complicating the design because other things need to react to that new feature.
Again, I have been in these situations, and I have seen, with my own eyes, that what you say is incorrect.
I have acted as a developer, as a architect, as a stakeholder, and as an observer seeing devs and stakeholders trying to work together.
What I've observe is more nuanced than that:
- if a dev comes up with some abstraction, there is indeed some chance this is a waste of time and this abstraction is not needed
- if a non-dev pushes for some abstraction or structure, there is some chance that it is a waste of time, but also a lot of chance that it is not, and this is not negligible at all and in fact crucial for doing a good work.
- if a dev says YAGNI, there is close to 90-100% chance that they have no understanding of what is the big picture, which is a problem anyway. If they had some understanding of what is the big picture, they will not say YAGNI, they will say "oh? are you sure? it is not compatible with my understanding, but maybe I'm wrong, let's clarify".
- these devs are very very unaware of how inefficient they are. They deliver things that does not correspond to what the stakeholders wanted, but then don't have a relationship close enough with the users for them to notice that it's suboptimal, or blame it on the stakeholders or on the timeframe or on other things.
> Why? Because anything that is going to be needed between now and that X moment in the future will have to take your design into account.
But isn't that exactly the point? In this article, you and the author have no idea if the design you propose to do right now is compatible with what is needed. In this article, the author shut down the question of "let's think about what is needed", they just said "someone decomposed this piece of work into few steps, so I will do each piece blindly without looking at the big picture, because otherwise it is not YAGNI".
> IMO, there’s no argument that can stand against “This is not part of the current requirements”
You should always assume that requirements are wrong. If someone is coming to you saying "hey, I think I've understood that what is needed is ...", you should never answer then "shut up, we do the requirements blindly". If there are doubt, just clarify instead of putting your head in the sand with YAGNI.
The reason the requirements should be assumed as wrong is not because the person who came up with the requirements is incompetent, but it is because requirements are impossible to come up with correctly. Because they require the person who come up with the requirements to already know exactly all the subtleties in all areas of expertise. Imagine that person is a non-dev. They have a good understanding of what they want. But how can they know that within ThingyDB, what people call an integer is in fact what normal people will call a fraction. So they say "we want an integer", and the devs deliver something that return a fraction. And if the non-dev says "it's not what I had in mind", then the devs will say "well your requirements were bad". Both it cuts both way: it is also not the devs fault if in their context, "integer" means that specific object. Both interlocutors don't know what they don't know. They cannot write requirements where every single word is over-defined just in case.
(And if you have the opportunity, ask a dev team to come up with requirement outside of their subject of expertise, it is usually hilarious. But also a really good eye-opening exercise for these devs who were condescending towards the non-devs)
This is an obvious case to illustrate, but this is very close to what happen in practice. An example I have in mind is between the Project team, where they collaborated with "organisation", which are just other partner companies, and the Dev team, where they had "organisation_id" used for authentication. And of course, no one noticed that the same company would have several organisation_id because they had different project and different contact person. The devs were convinced that several entities that were in fact the same organisation (according to the common sense definition) were, according to them, several different organisations.
You are constantly ignoring the main point: There’s a simple solution for today’s requirement, and there’s a complicated solution that will also solve a future, not existing yet, requirement. Chet want to write the later, not the former.
The complicated solution is trying to solve two problems at once, and one of them does not exist yet. It’s speculative.
> The fact that the author just chooses to not even try to check if Chet is correct or not should be a red flag.
Chet himself says that the thing will be necessary 3 weeks from now, implying that it’s not necessary today.
You can anticipate changes and plan for it. You can brainstorm it. You can even question the current requirements. What you don’t do is solving something that does not exist.
When we say YAGNI, that means the problem you’re stating, even when reasonable by itself, does not apply to the current context. It’s easier to revise a simple design later when needed, than refactoring a complex one that have a flawed assumption.
I think you're missing the point of the poster you are replying to. You make it sound like 3 weeks is 3 years. It ain't.
Very little, or possible nothing at all, is going to change in 3 weeks. If you are that myopic - as the XP people were - then constant failure is not going to be surprising. It will be expected.
It’s not about the specific timeframe. It’s about something that has no value for today’s context superseding something that do. It’s ok to anticipate changes, it’s not ok to act as if they’re already here when it’s clear that they’re not.
And the other axis is the lean towards complexity.
Let’s say you need to add logging for a web app to be able to quickly troubleshoot it. The design was to create a simple module that printf to stderr. But then the dev comes to you with a new complicated design involving elastic search and what not, saying that we will need it in 3 weeks to dissect the logs, etc. It may have been a good idea, but it’s not valuable. The correct idea is to put that on the backlog, not to start writing code for it.
Implementing complicated idea takes more time than implementing simple idea, while the value is the same.
When there’s a need for having something elastic search for the logs, it will be easy to refactor the simple code that we have than fixing the possibly flawed implementation that would have resulted if we went with the complex design.
> It’s about something that has no value for today’s context superseding something that do.
But this is incorrect. Chet is saying "if we interpret today's requirement this way, what we do today has no value, if we interpret today's requirement this other way, what we do today has value". (and if he is in fact not saying that, the problem is that you and the author have no idea if he was saying that or not, you just saw "3 weeks" and concluded, incorrectly, that it is not about today's requirement)
Please check my other comment for an illustrative example.
> Implementing complicated idea takes more time than implementing simple idea, while the value is the same.
That is factually not true. Take my illustrative example of my other comment: Day 1 requirement has ABSOLUTELY NOT VALUE if the devs that implement it don't listen to someone who said "in Day 5, we will be in this situation, so Day 1 requirement has only values if done this way and not that way".
> Let’s say you need to add logging for a web app to be able to quickly troubleshoot it. ...
Your example does not prove anything. We here all agree that over-engineering is a bad idea, and we can all come up with example where it is done.
What you need to do, is to demonstrate that ignoring what we already know for sure will happen in 3 weeks will never be less efficient than taking 5 minutes to pick the correct solution between two simple solutions, one compatible with in 3 weeks and one not.
This is how you demonstrate. If you say "f(x) is always positive", the demonstration is not to present some x values that are positive, the demonstration is to find a way to show that there is no x values for which f(x) is negative. If you restrict yourself to "let's assume that Chet solution to be compatible with the situation in 3 weeks is complex and will not be needed", of course you will conclude what you conclude. What you need to do is to convince us that it is impossible to have a situation where the information of what will be in 3 weeks will never be useful.
Because this is the point: in the situation in the article, the author has not enough information to know if Chet solution is complicated or not something needed. In fact, according to Chet, it is something needed, and the simple solution has therefore __zero value__.
> Chet is saying "if we interpret today's requirement this way, what we do today has no value, if we interpret today's requirement this other way, what we do today has value".
He is certainly not saying that. The premise is that the simple thing has value for today, the complicated thing has value for today and in 3 weeks time.
> than taking 5 minutes to pick the correct solution between two simple solutions, one compatible with in 3 weeks and one not.
The choice is between a simple solution that will solve today’s issue and a complicated solution (which will take more time) that will also solve an hypothetical situation in 3 weeks.
> in the situation in the article, the author has not enough information to know if Chet solution is complicated or not something needed.
The premise of the article is that the solution is indeed complicated and not something needed today. You may have also been in similar situation. You don’t invalidate an argument by pointing that the premise isn’t true when there’s no argument made that it will always hold true.
Saying that P imply Q, does not mean P is always true.
Let me answer to your 2 comments here.
My criticism against YAGNI as a sane approach is not that things cannot be out-of-scope or over-engineered. My criticism against YAGNI is that it teaches developers to be unable to see a situation and think "yeah, maybe it's a bad over-engineering thing, or maybe it is not". It teaches devs to read __everything__ as bad over-engineering.
In your comment, you are showing exactly that. If you are not "contaminated" by YAGNI, you will look at the situation as described and not jump to the conclusion that "the premise is obviously that ...".
Here, you are saying "He is certainly not saying that". But if you look exactly what he is saying in the dialog, he MAY be saying that, but he also MAY NOT. This is my criticism: YAGNI trained you to misinterpret.
In your other comment, you say that Chet ask for developing something for "a powerful engine as the user may like to go offroad with a trailer". Where this even come from? Are you really unable to mentally conceive, in your head, a simple situation where Chet is talking about the exact motor that was planned from the start?
You are saying that Chet is talking about a motor for going offroad with a trailer, and yet, in the article, Chet says "but in 3 weeks that will be insufficient so since we’re going to need this" followed by "You don’t understand. We’re definitely going to need it. See, here’s an example…" followed by "But we really are…".
And at no point, absolutely no point, you thought "wait, maybe Chet is not being excited by a crazy hypothetical situation, maybe Chet is just talking about something ... we are really going to need it ... because it is in today's project goal, because it is just written that it is what we need to build and what the users are asking for".
You keep saying "the premise", but "the premise" is my criticism. I understand that the author is presenting the situation as if Chet is getting out of scope and uselessly complex. My criticism is that in the described situation, the author should recognised that this premise is just an assumption, and that he should ask for more information.
Maybe another example to illustrate. "Hello, my name is Bill, and I really think it's a bad idea to put wall paint in food. Let's take this situation, my friend Bob is coming to help me to cook, and he says "oh, I think it would be better if this birthday cake was more colorful". I immediatly said "Nope, No way", I knew he wanted to add wall paint in the cake. Bob said "maybe we can go to the shop and get ...". "No" I interrupted him. I would not go to the DYI shop to buy wall paint, it's ridiculous."
According to you, you are saying "well, it is the premise of the article that Bob want to use wall paint in the cake". But beyond the premise, this article still shows that Bill has a totally useless and strange reaction: normally, Bill should not have jumped to the conclusion that Bob want to put wall paint in the food.
Well, this conversation with you is a good illustration of why YAGNI is a terrible idea. In this whole conversation, you really struggled even conceive a situation where someone like Chet will use the same language but will not want to replace the project motor for another one to do offtrail with a trailer, but was simply talking about the motor that was planned all along in the project.
Unfortunately, because of YAGNI, there are more and more devs that are unable to see useful discussion without jumping on the conclusion that the whole discussion should be discarded.
> You keep saying "the premise", but "the premise" is my criticism. I understand that the author is presenting the situation as if Chet is getting out of scope and uselessly complex. My criticism is that in the described situation, the author should recognised that this premise is just an assumption, and that he should ask for more information.
There’s a premise that you know can be true. There’s a logical reasoning that you don’t seem to be against. There’s also a conclusion that you also don’t disagree in your comments.
If the whole thread is you arguing about the premise and saying there may be a chance of it not being true, then this is not a discussion. It’s speculative fiction.
> If the whole thread is you arguing about the premise and saying there may be a chance of it not being true, then this is not a discussion. It’s speculative fiction.
But it is a really concrete question. Me or other people may be in Chet's situation, so it is important that you just not answer "if you are not over-engineering, then it's a different premise, so it does not count, you don't really exist".
We both agree that over-engineering is bad. I guess you agree that sometimes, someone may propose a different solution that is not over-engineering? My question, and it is not a trick question, is: can you explain me what this person should do in this situation.
It is not a trick question, it is real: my impression from this discussion is that if I'm in a situation where I have a constructive proposal, not out-of-scope, totally within the project goal, that will help the situation reaching its goal more smoothly, then whatever I say, you will just answer me "you ain't gonna need it", the same way the author did to Chet.
Let's imagine that Chet is speaking to the author of the article, and let's imagine that Chet does not want to plan for a new offroad motor pushing a trailer. Let's imagine that Chet is talking about the current project, its exact current goal, that within this project, they plan to use a standard Sedan 500 pounds engine, and that Chet is charged by the author of the article of installing wheels, but that the author has chosen a simplistic approach and that, as a consequence, these wheels will not be able to support a 500 pound engine. For example, the author of the article has asked Chet to do a "simple-on-axle-mounting" approach, and that car engineers have demonstrated that for more than 400 pounds engine, you need a more complex "double-corkscrew-mounting" (I made this up of course). Installing the wheels is the current task, and installing the engine will happen in 3 weeks. How can Chet approach the author of the article?
In the article, Chet approach the author by saying "I could do this simplistic thing now but in 3 weeks that will be insufficient so since we’re going to need this more complicated thing I want to do it now". What should have he said instead? Why this sentence is bad and what make this sentence sounds like Chet is talking about something out of scope? The author does not know that the "simple-on-axis-mounting" approach is discredited. What in this simple sentence informs the author of the article that Chet is not trying to inform them that this approach is not correct and that he is instead talking about out-of-scope over-engineering?
Trying to answer your question.
Your example does not work with the article because the simplistic approach is already proven to be an ok design. The wheel will support the engine. The complex approach (maybe a non standard suspension) is for an hypothetical scenario that Chet believes will occur in 3 weeks. That scenario is not the mounting of the engine which is already planned and scoped.
You don't delay a project because of an hypothetical scenario. What you do is evaluate and present the risks and a possible solutions. You don't rush in the implementation unilaterally. That's a cowboy mindset.
> What in this simple sentence informs the author of the article that Chet is not trying to inform them that this approach is not correct and that he is instead talking about out-of-scope over-engineering?
That means the solution is OK and the implementation will provide some value for the customer. How does he know that? Where's the argument, not merely examples as in the rest of the dialogue, but real objective facts and numbers (like there's another requirement that the customers are pressing us). It's very likely that any such situation would have skipped past by when designing the simple approach. Will we really need it? We know that we don't need it today. What will change in a few week that will make it a requirement? Again what needed here is objective facts. Not what-if scenarios. Why the rush? Why can't it wait for 2 weeks when we can tie the feature to the name of few customers (assuming it's B2B) or market analysis. Why do we need to spend let's say a week on this complicated approach when we can solve the problem in a day or two and ship it.That's all the questions I would have asked if I was not familiar with the project. But if you're the project lead, the only thing that would have led you to question yourself is if Chet has said the simplistic approach does not work. But it does.
> Your example does not work with the article because the simplistic approach is already proven to be an ok design.
Where is it done? No where in the article the author said "Chet said it will not work in 3 week, so I demonstrated that it will work in 3 weeks". The author just __assume__ it is an ok design.
What I'm telling you is that you and the author are acting in a way that shut down the conversation in case you are right AND in case you wrong.
Your answer to that is "I'm mentally impossible to conceive a scenario where the author missed something, did not realise the 'simple-one-axle-mounting' approach will fail". That is such a red flag.
> The complex approach (maybe a non standard suspension) is for an hypothetical scenario that Chet believes will occur in 3 weeks.
This is not what I ask you. I ask you to say what Chet should say in the situation where Chet is right, where the author design is incorrect and Chet scenario is not hypothetical. You keep twisting back "no but let's just pretend it cannot happen". This is my worry: are you even able to conceive that it can happen?
> That means the solution is OK and the implementation will provide some value for the customer.
What? That is definitively not how normal people would understand this sentence. Are you a native english speaker? According to you "I could do this simplistic thing now but it would not work" is an impossible sentence? Or that this sentence is saying that the solution is OK because the sentence contains "I could do this thing"?
> How does he know that?
Well, that's the point. In this step of this dialog, you don't know yet, and yet you already concluded that Chet does not know and that you know.
> Where's the argument, not merely examples as in the rest of the dialogue, but real objective facts and numbers
Chet is introducing the problem, he is shut down before he can even give his first example. Chet may have plenty of objective facts and numbers, but the author shut down the conversation before it even happen. In this dialog, Chet is __trying__ to bring facts and numbers, starting by a concrete illustration, but he is interrupted before he can do it.
You are so full of it. You are saying "Chet did not arrive and slap the author with a book full of facts, so it is the proof that Chet has no idea of what he is talking about and should be shut down before he can prove this assumption is wrong".
> Will we really need it?
You don't know if you really need it or not, you don't know if Chet has facts and numbers. Because YAGNI is shit, you just assumed that the situation is over-engineer, while you have no idea of what the situation is and stop people who try to explain it to you.
> We know that we don't need it today.
No you don't. You just stop Chet explaining and interrupt him.
> What will change in a few week that will make it a requirement? Again what needed here is objective facts. Not what-if scenarios.
This is what I saying from the start: when Chet reacts like that, the fact that the author does not say "wait a minute, do you have objective facts" is a red flag. The fact that the author goes to the what-if scenario that his design will obviously work, without providing any objective facts, is the problem.
> Why the rush?
Where is there any rush. The situation is extremely simple. The guy say: "hear me you, I think I will be wasting me time doing this". The author answers "shut up" and __assume__ that Chet has no argument.
> That's all the questions I would have asked if I was not familiar with the project. But if you're the project lead, the only thing that would have led you to question yourself is if Chet has said the simplistic approach does not work. But it does.
I saw very experienced devs failing at that all the time. In this article, the author is assuming he has a good understanding of the project and shut down anyone who can bring important information.
Your approach: "I'm the lead, so I cannot be wrong, so I assume Chet is incorrect when he said the simplistic approach will not work" is so bad. Do you even realise that?
You are a perfect example of what I was talking about. What would you have lost in just hearing Chet out? But now, YAGNI is just shit, it pushes people to have this attitude to assume that only them know the truth.
> According to you "I could do this simplistic thing now but it would not work" is an impossible sentence?
Because that’s not what it said. If someone is talking to me, I don’t invent sentences in my head for them and assume things that they haven’t said.
That’s what you’re doing, inventing a whole situation outside of what the author described because you keep adding things that the author has not mentioned.
I have my interpretation of the dialog. And I agree with the author that Chet should focus on the simple thing now, and je can always wait later to refactor it to handle the future situation.
If you want to discuss an alternate interpretation, do it within the confine of the dialog. Don’t add your own words to it.
> Because that’s not what it said.
What it said is "I could do this simplistic thing now but ... that will be insufficient"
It LITERALLY says that it will not work, that it is not a good solution.
Even if Chet is wrong in his prediction, you quoted Chet and pretended that this thing that Chet is saying is a proof that this solution will work. This is so obviously not at all Chet's opinion.
And I'm sure you are going to INVENT "but Chet does not know what will happen in 3 weeks". Firstly, again, your "proof" is a quote from Chet, who, according to you, demonstrate that this solution is ok while that sentence is used by Chet to explain that the solution is not ok. But secondly, you have no idea why Chet is saying what he is saying, you INVENT that Chet does not know, does not have facts and numbers, while there are tons of real life example where it is easy and correct to predict that in 3 weeks something will not work anymore.
> ... inventing a whole situation outside of what the author described ...
I don't.
In the situation described by the author, is it true, is it factual that Chet thinks it will not work: YES, he is saying exactly that.
Is it factual that Chet is trying to provide more information but the author shut him down before hearing them: YES, this is factual.
Your only little argument is "let's imagine that Chet proposal, that he NEVER explains because he is interrupted, is bad". All I'm saying is that you have no idea what Chet argument is, you just assumed. This is fact. Can you tell me where, factually, in the written dialog, Chet explain his understanding and this understanding is indeed incorrect? Can you point me to these sentences? They don't exist.
You see "3 weeks" and concluded that "it is out of scope and/or over-engineered", which is obviously a bad conclusion as it is very easy to find plenty of example where this conclusion is totally wrong.
I don't want an alternate interpretation, there is no need for it. Does the author shut Chet down before Chet explains himself? YES. There is nothing to interpret, it's just a fact. Then, based on that, you said things that are BS, such as "Chet said '3 weeks' so it is the proof that it is out-of-scope". I then gave you a counter-example showing that your reasoning is wrong, and your only argument was "you invented this example so it does not count".
> What it said is "I could do this simplistic thing now but ... that will be insufficient"
> It LITERALLY says that it will not work, that it is not a good solution
You have a strange definition of insufficient.
> Can you tell me where, factually, in the written dialog, Chet explain his understanding and this understanding is indeed incorrect
Both the author and I never said that the complicated thing is wrong or incorrect. YAGNI is basically saying “not now”. Meaning we can revisit when the situation calls for it, but not today.
YAGNI is a matter of priority and resources allocation. You don’t solve problems you don’t have or unlikely risks.
Do you set up a cold room in your house and buy food for the next month because you know you will be hungry then? No. You buy a fridge and groceries for the next few days. Not because a catastrophic event can’t happen, but because your budget is limited and/or you have better things to do with that money.
Complicated things cost more than simple things (to build and maintain) and take longer to ship and produce value. The only reason to not go with simple thing is when it does not work, not when it’s insufficient. We already know it does not handle every little feature, but it will work for now.
> You have a strange definition of insufficient.
You have a strange definition of "okay". "Insufficient" is definitively not okay. The definition of "insufficient" is "less than needed". How is that "okay"? And if it is not "okay", than, yes, it is not a good solution.
Thank you to demonstrate that people who pushes for YAGNI are delivering "insufficient" work and think it is "okay".
> Both the author and I never said that the complicated thing is wrong or incorrect. YAGNI is basically saying “not now”. Meaning we can revisit when the situation calls for it, but not today.
And you have no idea if the situation calls for avoiding the problem today or not today. Take back the car example: if you install wheels that are incompatible with the planned engine, you need to fix this problem __today__.
Your code will fail in 3 week because of a mistake you are making TODAY. The proof: if you install the correct wheels today, then nothing will fail in 3 weeks. The failure that will happen in 3 weeks (and it will happen: car engineers have tested it and are clear on that, it is the law of physics) is not due to a problem that was born in 3 weeks, the failure will be due to the bad decision made today. This is a TODAY problem.
Your reasoning is totally crazy, imagine if it was considered seriously: "oh, you noticed a bug in my code during code review. Well, let's ship the code in production and wait for users to raise a bug ticket, because before then, the problem does not exist".
> YAGNI is a matter of priority and resources allocation. You don’t solve problems you don’t have or unlikely risks.
And in the case of Chet, you have prioritized NOTHING. You still have no idea of what Chet was raising. You have no idea of what are the risks. You have no idea if your current plan is even the correct plan or not.
Imagine the following situation: "oh, we took the wrong road, if we continue tomorrow we will arrive in Berlin instead of Paris". Only very stupid people will say "no, that's a problem for tomorrow, let's just spend all the time in between doing something totally useless that we will need to undo tomorrow".
> You buy a fridge and groceries for the next few days.
You realise your contradiction here: you are saying you buy TODAY food for when you will be hungry IN THE NEXT FEW DAYS. According to your logic, you should not do that. What you should do is to go to the shop every single time you feel hungry and buy only one item, the one you want to eat now.
> Complicated things cost more than simple things (to build and maintain) and take longer to ship and produce value. The only reason to not go with simple thing is when it does not work, not when it’s insufficient.
Simple things that have no value at all cost more than complicated things. When Chet come up, he is saying "hey, I think I notice we are planning to build something that has absolutely no value". Your reaction is "no, it is better to do something useless with no value than something more complicated that has value".
And again, as I guess you will not get it: maybe Chet is wrong. The problem is that you just ignore Chet. Maybe he is wrong, but maybe he is right, you have absolutely not idea.
> We already know it does not handle every little feature, but it will work for now.
It will not work for now. If you install the wrong wheels on a car, the car is useless until you install the engine.
The important thing is not "the task of today", it is to deliver what the user needs. Here, Chet is saying that he thinks you are planning to build something that is a waste of time, something that will not deliver what the users need.
The reaction should be "Chet, maybe you are right, but maybe you are wrong, let's check together". Instead, the reaction was to interrupt him and act as if the users care about today's work more than the real product.
The whole car example is flawed because insufficient does not mean wrong or incorrect.
> And in the case of Chet, you have prioritized NOTHING. You still have no idea of what Chet was raising. You have no idea of what are the risks. You have no idea if your current plan is even the correct plan or not.
Why are you so sure the author cannot compare <complicated thing> and <simple thing>? Or he has not considered <complicated thing> before even Chet and discarded it?
> When Chet come up, he is saying "hey, I think I notice we are planning to build something that has absolutely no value"
You’re again inventing stuff. The simple thing has value today. It will be insufficient in three weeks. It is not insufficient today. If we implement it, the user will have a working solution way sooner instead of waiting for the complicated thing to be ready.
How do you value your user’s time?
> The important thing is not "the task of today", it is to deliver what the user needs.
What the user needs today and what it will need in three weeks are different things. You and Chet have been ignoring the user’s need for today.
If someone wants some data outside of a system and you can write a quick perl script in 30 minutes to produce a CSV, you do it. You don’t argue about setting up a whole ETL pipeline because that will be needed in 3 weeks and the perl script is insufficient. Especially when that pipeline will take days to implement. You can have a whole set of examples and what not. But we can discuss that after the perl script is written and the needed data is exported.
> The whole car example is flawed because insufficient does not mean wrong or incorrect.
In the car example, the solution proposed by the team leader is insufficient. The result is that the solution proposed by the team leader will lead to either the project to fail or to a waste of money.
> Why are you so sure the author cannot compare <complicated thing> and <simple thing>?
What are you talking about? I'm not saying you cannot compare <complicated thing> and <simple thing>, I'm saying that the author does NOT COMPARISON: he has no idea what Chet is talking about, because Chet want to explain and the author shut him down.
You cannot say that Chet's solution, which is more complicated, is less valuable than the simple solution, because you don't even know if the simple solution has any value.
> The simple thing has value today.
No, YOU DON'T KNOW THAT. You invent that. Take the car example: having a wheel but no engine has no value. There are ton of other examples: for example, if someone is talking about a bug that occur because in three weeks we are in 2026 and that the code has a bug that make the code unusable if the year is 2026. If the product is released in February 2026, then the simple thing has zero value. (that's a made-up example for the sake of simplicity, but having bad design that destroy the quality soon after is a real thing, very common)
> How do you value your user’s time?
And how do you value users leaving because in 3 weeks that see the product is not able to do something they were expecting?
> What the user needs today and what it will need in three weeks are different things.
You don't know that. In the example of the car, the user don't need a 1 wheel car with no engine.
Again, because you have no idea what Chet is talking about, you have no idea if what Chet is talking about impacts today's users.
> blablabla ETL blablabla
You keep giving example where someone over-engineer (or ask for working on something too early, or ask to work on something out of scope, or ask to adapt the current goal based on hypothetical future goal, ...). EVERYONE HERE agrees that this is bad and should be avoided. The disagreement is that in the dialog in the article, the author did a terrible job at assessing if Chet contribution was a good or a bad thing (based on these criteria), because the author has drunk the YAGNI cool-aid and jumped to the conclusion it was a bad thing while there are plenty of situations where Chet will act exactly like that when it is not some of these bad things.
(and again, my criticism is not these "bad" things are not bad and should not be avoided, my criticism is that some devs say "YAGNI" and shut down the contributions that are fully relevant to do a good job and deliver value. A simple solution is to not be an obnoxious d*khead and just listen to Chet, to check if it is a real bad thing or not, and act accordingly like an adult instead of behaving like a little kid)
PS: I note that you just ignore elements where you cannot answer. (for example, the food that you don't buy one item at the time, the fact that "prioritization" means nothing when you don't even know between what and what you are prioritizing, ...)
> In the car example, the solution proposed by the team leader is insufficient
Because you created that situation out of the blue. And you’ve been ignoring any case where both solutions do work, but one is more complicated than the other. And the simple one can be delivered very soon, but the complicated one will be useful only three weeks later,
> if someone is talking about a bug that occur because in three weeks we are in 2026 and that the code has a bug that make the code unusable if the year is 2026. If the product is released in February 2026
But the simple thing can let us deploy in 2025 and land a big contract before the holidays. Perfect is the enemy of good as we say.
> Again, because you have no idea what Chet is talking about, you have no idea if what Chet is talking about impacts today's users
It is explicitly mentioned that the complicated thing will only matter in 3 weeks, not today.
> You keep giving example where someone over-engineer. EVERYONE HERE agrees that over-engineering is bad and should be avoid.
And you keep ignoring that time matters and a problem in the future doesn’t mean it exists right now. You do the thing that matters for today, then you do the thing that matters for next week.
Your argument has been the thing that matters for today may not really matter and that is not what Chet has been saying.
Insufficient in 3 weeks only matters if we can’t ship the simple thing in that timeframe. If we can do so in one or 2 days, we can then focus on the complicated thing.And that’s assuming Chet knows more about the project constraint than the project leader. Something my be great technically, but the other perspectives that the leader have is why he is refuting it. Like he got an email this morning that we will be abandoning the project in 3 weeks but we’re contractually obligated to fix every bug. He can’t discuss that with you, but he can direct your workflow.
So the next time you hear YAGNI, ask why. Don’t rush to prove your point.
What you say if not making much sense. You don't provide counter-arguments or arguments, it looks more like a collection of special cases, but they don't contradict anything I'm saying. It's like if I say "f(x) = x - 10 can be negative, for example if x = 2" and you just say "no because sometimes x = 15". I don't get the point of your argument, you seems to say that if you find one special case that works for your conclusion, then your conclusion is correct.
For example, you just say "what if the simple thing can let us deploy in 2025 and land a big contract before the holiday". Firstly, it's a weak example, do you really believe that someone will sign a big contract with you on brand new code within 3 weeks of the release without either testing for few weeks or asking guarantee that it will still work after 3 weeks? Secondly, it's easily a bad point for your approach, what do you think will be the commercial impact when the partner will see that your code falls apart after 3 weeks because you did not anticipated something they find obvious? Thirdly, a simple tweak and it becomes an example against your approach, what if the big contract is on week 4, and that you miss it because you have to undo the simple solution and build the more complicated solution in order to have a product that work? But more importantly, it does not contradict anything I said, my approach still is better: if you have a big contract, then LISTEN TO CHET, and if what he says can wait, just say "great, noted, but we will do it after the big contract" (and if Chet has a good point, you will win bigger).
I really don't understand your point: listening to Chet has only good consequences. You listen to him, and then you still can decide if it's smarter to do it now or not.
For all the scenarios that me and you have proposed, your method keep failing my scenarios, while my method keep succeeding my scenarios AND your scenarios.
You also are hypocritical: on one hand, you hand-wave "perfect is the enemy of good" and on the other, you whine "bouhou, if we try to stay aware of the constraints that are coming our way, this is soooo baaad, we need to stay pure and perfect, this is sooo important".
About "today's user": users don't care about the code. If the plan is to work on the backend on day X and on the front-end on day X+3weeks, the fact that the code runs on day X is a negative for the user, today's user, because today's user cannot use the backend, he needs the backend and the frontend. And because you built a backend incompatible with the front-end, you will deliver even later. Another illustration is about the car example: today's user don't care about a one wheel structure without an engine, this is totally useless for them. If you successfully install the wrong wheel today, you impacted negatively today's users, because they will get their car even later.
About "time matters": you are arguing that, but you are pushing for a solution that WASTES time. Your logic is "installing the wrong wheel takes 5h, installing the correct wheel takes 10h, so let's install the wrong wheel". Except that the user will not be able to use the final product until the correct wheel has been installed, so you will use 5h to install the wrong wheel, 5h to uninstall the wrong wheel, 10h to install the correct wheel, and you will have spent 20h instead of 10h. And I know your argument, which is "I'm not talking about the car example, in my scenario, today's task is a feature that users can use directly". But my argument is that you are shit at knowing if it is the case or not. You read this article, you saw the author shutting down Chet, and not one instant you thought "ok, but of course this is terrible advise if we are in a car-example situation". I looks like this possibility flew high above your head, as I need hours of exchange to educate you on the subject.
About "you keep ignoring that ... a problem in the future doesn’t mean it exists right now": You saw "3 weeks", and you are mentally unable to realise that because the code is running today, it does not mean that the code is delivering what it is supposed to deliver. A simple example: the task is to install wheels that are compatible with the planned engine, and the team leader planned to install the wrong wheel. Someone notices and say "in 3 weeks, when we install the engine, it will not work". This is not a future problem: you have failed TODAY'S REQUIREMENT, TODAY'S TASK. The task itself requires that what you build is compatible with what will be built in 3 weeks. But because you saw "it will not work in 3 weeks", then you concluded that what you have built today satisfies the requirements. It is sometimes the case, it is sometimes not the case. And because you did not let Chet talk, you don't know what he is talking about, so you don't know if he is talking about a future problem or you having failed today's task in a way that will only be visible in 3 weeks.
About "assuming Chet knows more about the project constraints than the project leader": YES. NO ONE. NO. ONE. No one knows the project perfectly. No one will never miss something. When Chet is coming to the team leader and says "I think we may be wrong", listen to Chet. If Chet is incorrect, fine, no harm done. But Chet may not be incorrect. The team leader does not know what they don't know, they should never assume that they know more about the project constraints than the other collaborators.
And again, because I'm sure you have difficulties wrapping your head around this: I don't ignore that not all project are like a car construction. The problem is that your arguments are incompatible with a common situation. The fact that your arguments are not incompatible with some situations does not mean they are correct. The fact that they fall apart in some situations means they are incorrect.
Your argument is always about:
While the situation is: I was Chet at one time and never have someone like the author to rein me in. I get cured from wanting to implement complicated solution when client asked me for demos and I couldn't show anything because I was trying to solve everything. And you're right, they don't care about code. They care about working product, and today, not in 3 weeks. So between A and B, I deliver A first, then worry about B.And when someone higher than you (and better placed to have more information about the constraint of the project) refuses your idea. You ask why, you don't immediately try to prove your position. Imagine doing that in the army.
> While the situation is
BS. You have no idea if it is the case, you don't listen to Chet. You __assume__ that Chet's solution is motivated by a different goal, but you __shut him down before he said so__.
You now invent things that are never described in the scenario, to try to badly justify that somehow the author's ASSUMPTION is justified. But the problem is that even if what you said happened, the author's assumption is still an assumption: the author is a bad lead for not verifying at 100% that Chet is indeed talking about the same B that the author has in mind. And even if the author does it behind the scene, the author is a bad lead for not being fully aware that he should have writing this step explicitly within the scene, as it is a crucial step for the judgement and should be evaluated before acting as he did.
> Now the author knows both A and B
The author SHUT CHET DOWN BEFORE Chat explains what he is talking about. How does the author even know that Chet's complicated solution correspond to B?
I guess you will say "but Chet told him behind the scene" or a bad argument like that. Which is of course changing the scenario as described in the article (something you were incorrectly whining about but have no problem doing it yourself).
But also it justifies my criticism: even if Chet's explanation happened behind the scene, it means that when you read this scenario, instead of thinking "oh, red flag, the author should make sure he understands exactly what Chet is talking about", you just __jumped to the conclusion__ that this situation was a "constraint from a hypothetical future" situation where what you had behind your eyes gave you no indication it was. And you __invented__ without any justification, that elements that are not within the scene occurred just to justify a posteriori your conclusion.
To take a more extreme example: it is like if the article says "and then this black person is arrested", and when someone says "it is strange, I don't understand on which basis this person was arrested", and someone says "well, when reading the article, I just assumed that the black person is a thief and that they saw it behind the scene". This last person reading of the article has highlighted his prejudice, his bias. Same here: you ignored the possibility that it may be a "Task X vs task Y" situation because you __blindly assumed__ it is the situation that YAGNI has put in your head.
> and maybe B was discussed beforehand but Chet don't knows about it
And maybe the unicorns have whispered to the author's ear what Chet was talking about.
You are so full of shit, you are just making excuses and grasping straws to pretend that the terrible judgement of the author was somehow justified behind the scene. Do you even realise that?
> I was Chet at one time ...
I am not surprised at all. But the problem is that not everyone is as bad developer as you are: sometimes, they found __proper problem__. In the exact dialog, the author shuts Chet down before he can explain the problem. Chet even said "you don't understand ...", trying to say to the author that what he is bringing is not what the author seems to understand it is. That in itself should give you pause: "wait, are we sure Chet is not trying to talk about a problem that the author genuinely missed", but it did not because you were unable to mentally conceive it may be the case.
> And when someone higher than you (and better placed to have more information about the constraint of the project) refuses your idea. You ask why,
Again, if you are a team leader and you think that you will never miss anything or that you are the only ones in position to discover things that has been missed, then you are such a shit team leader. With a fragile ego.
> Imagine doing that in the army
WTF? What kind of argument is that? Your argument seems to boil down to "reSPecT my auTHorItaaa". As a team leader, I am smarter than that: I know that sometimes things will be missed, and I know that it is better for everyone to be in a situation where anyone can bring it to attention.
And, yes, sometimes they will bring to my attention things I already know. But I listen to them first. It does not change ABSOLUTELY ANYTHING, and if someone says the opposite, this person is full of shit and does not know what they are talking about.
YAGNI means you ain’t gonna need it. And if you can’t ask why A stays and B can’t be accepted, that just means you believe your reasoning is always the correct one, and your team leader is an wrong to not accept it.
And as I’ve said. If you state something and the person in front doesn’t accept it, you ask for his reasons. You don’t rush to prove yours.
You really can’t accept that the author knows about B and have a valid reason to not choose it, evenk if B is completely valid? Software engineering is all about tradeoffs. And it’s on the leaders to choose some, even if you really believe it must lean the other way.
> And if you can’t ask why A stays and B can’t be accepted, that just means you believe your reasoning is always the correct one
What? Why are you saying "if you can't ask why"? I personally can ask "why", there is no problem with that. I have been in situation where I was the lead and I had to say no to someone like Chet and I've done it after listening to him. And I've been in situation where I was the lead and I listen to Chet and Chet had a good point that was useful, and I used this point to reassess my decision, and sometimes I change my plan, and sometimes I did not. And I've been in situation where I disagreed with the lead but said "ok, you're the lead, we should not flip-flop between captains, we need one person at the driving wheel, so I accept your decision". Why are you inventing that it is a problem to me? Can you provide the sentence I've written that led you to that conclusion?
But in the article, in the scenario, the author never ask "why". Chet arrived and said he thinks there is something suboptimal, and the author did not say "why", he said "YAGNI", and Chet tried to discuss this and the author did not say "why", he said "YAGNI", and Chet tried to have the author explain why, and the author did not say "why", he said "YAGNI".
The author __REFUSED__ the discussion. Chet did not even had the opportunity to say "why".
> If you state something and the person in front doesn’t accept it, you ask for his reasons.
It is what Chet is trying to do. Chet does not say "no, you are wrong", Chet tried to discuss this: he wants to explain his argument to know what are the author reason for possibly refusing. Chet suspects that the author does not understand, he tries to clarify, to give example, but the author just refuses.
> You really can’t accept that the author knows about B and have a valid reason to not choose it, evenk if B is completely valid?
Why are you thinking that? The problem is not that I believe the author is wrong about B. The problem is that the author has assumed Chet was talking about B when this is only an unsubstantiated assumption.
Look at what I've written, I've written explicitly:
> You listen to him, and then you still can decide if it's smarter to do it now or not.
If you decide "let's not do B" and Chet says "no, I refuse to accept that", then Chet is 100% wrong.
The problem is that the author decided that Chet was talking about B __before Chet even explain what he is talking about__.
Again, if the author has good reason to not do B, then, I FULLY AGREE WE SHOULD NOT DO B. The problem is that the author is an idiot: Chet tries to talk to him about something, and the author just assumes, without any proof, that it is about B.
> Software engineering is all about tradeoffs. And it’s on the leaders to choose some, even if you really believe it must lean the other way.
A leader that choose between tradeoffs when he __refused to listen to the information__ is a bad leader, and his work will be poor.
Let's take your logic further: why providing any information to the lead at all? The stakeholders approach the lead and say "hello, we would like to have a feature, this will be ...", lead: "STOP! This will be a frontend interface with an animation of a little frog dancing", stakeholders: "what? no, we would like ...", lead: "no, you want that", stakeholders: "but you don't understand ...", lead: "good meeting, byyyye".
Honestly, your position is so weak. My question is "what's the problem with just listening to Chet to understand what he is talking about", and your position is so poor that the only thing you were able to do is to say "no because if I listen to Chet, it means Chet refuses my decision", which is blatantly incorrect.
> There’s a simple solution for today’s requirement, and there’s a complicated solution that will also solve a future, not existing yet, requirement.
There are tons of examples that show that your reasoning is incorrect.
Let's invent one: you need to build a car. Day 1: put the front left wheel on the frame structure. Day 2: put the front right wheel on the frame structure, Day 3: put the back left wheel on the frame structure, Day 4: put the back right wheel on the frame structure, Day 5: attach that particular motor on the frame.
Now, you are on Day 1, and Chet arrive and say "this wheel will not do, it will never support the motor that we need to install on day 5".
You are telling me that what Chet said is to be ignored because "it is a requirement for day 5". But it is not. What Chet has done is not bringing a requirement of day 5 into day 1, what Chet has done is that it has noticed an incorrect interpretation in Day 1 requirement. The requirement for Day 1 should have been read as "put the front left wheel on the frame structure, but of course, it goes without saying, use a wheel that is compatible with the car we want to build".
You saying that because Chet is using Day 5 information, the point he is making is not about Day 1 requirement is incorrect.
The thing is: Day 1 requirement and Day 5 requirement don't live on their own. Hell, your job is not to "just do Day 1 requirement" and it has never been. No one, absolutely no one, want a frame structure with just one wheel and no motor.
In the article, Chet does that: he tries to send the message "this is the point of the work, we will need it, it is what we plan to build, so you need to take that into account in today's requirement interpretation. If you don't account for it, you better not even do today's requirement".
And, and let me be clear on that, maybe the element that Chet brings will end up being not relevant or not needed. But the problem is that neither you or the author know that yet, and you reject the discussion before you can even discover if it's the case or not. The problem is that author and you just saw "Day 5" or "in 3 weeks" and, because YAGNI is a terrible advance, jumped on the conclusion "it is in the future, so it has nothing today with today's requirements".
(oh, and in practice, the people who says "YAGNI" will then say "well, the problem is Day 1 requirement, each requirement should go into excruciating details to re-explain the whole point of the work, should think of all the possible interpretation and should be written by someone who know better than me how to build the implementation to each line of code, but somehow should waste their time explaining the project to someone less competent".
Again, the problem with this argument is that the solution of "use your brain, build things carefully" creates a way easier and elegant solution than YAGNI+ridiculously unrealistic requirements.)
This is where the disagreement comesfrom. You have a different interpretation of requirements. A requirement is not a list of tasks. It’s a set of needs and constraints that drive a design.
In your example, the general goal could be to do a small sedan car, but then Chet come in and say that we need a more powerful engine as the user may like to go offroad with a trailer. And he’s ready to cancel the order for the standard engine and ready to adjust the chassis, the frame,… for the new engine.
But the thing is that there is no such requirement in the design, no hard data that says that user would like such data. It’s just anticipating needs without proper market research.
And as I’ve said previously, it’s okay to explore design for a more complete solution. It’s not okay to commit to them with just an emphasis on the benefits, nit the cost of maintenance while there’s no value to the business.
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.
That's interesting, because it's not my experience. A lot of the technical debt I see is that someone half-assed something thinking it would be easy to improve later, but the layer violations and inadequate tests make doing so a massive project, once it's become load-bearing.
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.
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.
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.
I would say: if the feature is from a developer, high probability of YAGNI, if the feature is from a user, medium probability of YAGNI.
> 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:
I still prefer the upsides of a shared vocabulary for talking about programming.
The programming language is the shared vocabulary
Everything above are made up leaky abstractions with a handful of exceptions
IMHO that's like saying we mustn't say "roof" because it's made of smaller parts and only those parts are allowed to have names. Not to mention the languages themselves have some of the patterns.
"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.
This was the issue with the early agile-developed systems.
Not that they didn’t write no code, obviously, but they didn’t understand the domain and so YAGNI’d everyone to death. As a result there wasn’t enough code for the system would do what it needed to do.
The code was simple and highly testable, but didn’t actually do the job.
Are you referring to some particular projects, or to the early stages of every project?
The original Agile poster child, Chrysler Comprehensive Compensation System (C3) was never very successful as a project. It achieved only a fraction of its goals and was ultimately cancelled.
YAGNI in that context is hilarious, because they were replacing an existing COBOL based payroll system. They literally needed pretty much everything the old system did to be successful. Part of the failure is because the devs did not understand what they were replacing.
Ah, that sounds like a classic mistake - rewriting a system from scratch without fully understanding what the system actually does.
[flagged]
[dead]