What Beck misses over and over again is there are many domains where there are “table stakes” that simply have to be done.

I think a huge amount of technical debt goes straight to YAGNI - devs pretending they are not going to need something that, yeah, they need.

YAGNI and related tenets were all excuses for “we are consultants in a field we don’t understand”.

▲ fmbb 3 hours ago | parent | next [-]

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.

	▲	ajb 3 hours ago \| parent \| next [-]
		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.
	▲	zeroonetwothree 3 hours ago \| parent \| prev \| next [-]
		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.
	▲	cauch 3 hours ago \| parent \| prev [-]
		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.

▲ cauch 3 hours ago | parent | prev | next [-]

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.

▲

MoreQARespect 3 hours ago | parent [-]

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.

▲

cauch 2 hours ago | parent [-]

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.

▲

MoreQARespect 2 hours ago | parent [-]

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.

	▲	cauch 16 minutes ago \| parent [-]
		> 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.

▲ gofreddygo 3 hours ago | parent | prev | next [-]

> we are consultants

This is the key insight. Design patterns were developed by a set of consultants. Promoted by other consultants. Consultants have perverse incentives, like bankers.

Realizing this made me critical of the design pattern kool aid. I've come to terms that these are going to be around longer than I'm going to be employed writing code. i keep the criticism to myself and avoid them when i dont see fit. Works ok.

As Hoare said:

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

	▲	actionfromafar 3 hours ago \| parent [-]
		I still prefer the upsides of a shared vocabulary for talking about programming.

▲ dang 3 hours ago | parent | prev | next [-]

"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

▲ bazoom42 3 hours ago | parent | prev [-]

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

	▲	Scubabear68 an hour ago \| parent [-]
		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.