That’s an awfully persnickety correction attempt for someone that replaced an opening capital letter and period with parentheses. That’s far more grammatically lax than using slang.
Americans and especially corporate culture America likes to do this all the time:
The ask instead of request is an example. I just politely use the words I prefer when that happens.
Our new promotes for this year.
etc.
I read from a linguistic source that it's a feature of English and the Brits do it as well.
There are plenty of alternatives for git hosting. The last thing which needs to be migrated before we get an exodus off this vibe coded monstrosity is reputation (i.e. github stars) which are inherently sticky.
I don't think GitHub stars are what makes GitHub sticky. Having a single UI / account and being able to jump between work projects, private projects and random open source projects where I want to open a quick issue or submit a PR is much more sticky.
The reason why GitHub is sticky was exactly this. It’s easy to fork, make a change, and submit a PR to another project. It’s the same interface for your code vs another person’s. It’s a simple, consistent interface to submit an issue.
You can argue that the lack of diversity in infrastructure is bad, and I wouldn’t disagree. I think we should have more projects to explore better ways of working. But, the tradeoff is that when you have a centralized system, like GitHub, you also have less friction. The learning curve is small when everything uses the same tools.
Git doesn't even need to be "hosted" anywhere. That's the point of it being distributed. What needs to be hosted somewhere are all the barnacles (like issue tracking, code reviewing, CI, and so on) that have grown out around git, that people and businesses have become dependent on.
It doesn't have to be. But without a hosted "source of truth", it's kinda hard to actually distribute it, and have a way to accept pull/merge requests/patches.
Which is why they cleverly moved the central story of a software change from the commit to the PR. Commits migrate automatically with the repo. But migrating PR descriptions and comments takes engineering effort.
Rhetorically, why can't folks add the feature of PRs to Git? Git is fundamentally just a graph manipulation engine and data structure. It would just be another object type, in a layer which sits above the normal commit graph. Obviously there is no "just make X" in software, but this feels reasonably achievable, and would have tremendous benefit for the cost.
some investors use stars (and star growth velocity) to determine which projects they invest or don't invest in. (not saying it's good or bad - just saying it's a real thing.)
Email can't really change much. The protocol is too old.
It would be better if we came up with new protocols that solve the email messaging problems and then gradually wean ourselves off email rather than trying to "fix" email.
In a sense this is already happening although instead of migrating to open protocols which solve the email problems we're migrating a lot of messaging to walled gardens which solve the problems (e.g. WhatsApp).
I guess that was google wave and yea it was a horrorshow.
I had hoped that something useful would come out of blockchain technology that would allow for a better messaging protocol that was spam resistant, e2e encrypted and decentralized by design but I didnt see anything.
>Email can't really change much. The protocol is too old. It would be better if we came up with new protocols that solve the email messaging problems and then gradually wean ourselves off email rather than trying to "fix" email.
I don't think so. Natural language is vague and repetitive.
I used hitchstory (YAML based stories) for doing this coz it's terse and typed.
I've tried using cucumber before and it reminds me of COBOL - which also had the same idea of making code more accessible via a "natural language-ish" interface.
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.
> 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.
This study seems to be mainly about the value of vibe coded tests and not at all about TDD.
Perhaps unsurprisingly it found that vibe coded tests suck. As a card carrying member of the "church of TDD" (I do think it is practical), this is an empirical result I certainly would agree with.
yes, there is some yak shaving necessary to make writing tests possible.
There is often a tension between delivering fast and high quality/bug free and what is necessary for medical software or financial calculations might not be necessary for games.
The question of whether to write tests at all is not really about TDD though.
set up a rendering profile and preconditions that generates a minimal snippet of images/video using a predefined GPU profile.
then test for either a pixel perfect reproduction of the correct behaviour or for the properties you're looking for (if it doesnt reproduce deterministically).
this is one way. i also subscribe to the view that if the type system is modified to become stricter in such a way that it can fail reliably in the presence of this type of bug that this is also good enough.
some people might argue that these arent "strictly" TDD by some definition but they set out a path to follow red green refactor and confer identical benefits so my view is who gives a duck?
I don't have enough domain expertise to know which variant of these approaches is best but I'm enough of a TDD expert to know that what you're implying isnt possible is actually something you would would probably derive a lot of value from if you did it.
snapshot test driven development again. i already wrote a similar answer in response to your other comment.
it follows the definition of TDD and it works really well (with some caveats) but again some people get hung up on what their impression of TDD is (e.g. unit tests checking to see if a car object has a steering wheel or whatever...) rather than what it actually is and what about it is that actually works.
The search box is gone and you're supposed to ask Rufus now.
reply