11 ms·

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 d

What Beck misses over and over again is there are many domains where there are “table stakes” that simply have to be done. I think a huge amount of technical debt goes straight to YAGNI - devs pretending they are not going to need something that, yeah, they need. YAGNI and related tenets were all excuses for “we are consultants in a field we don’t understand”.

fmbb 3mo ago
All tech debt I have ever seen in my 15 years of professional software development has been someone building too many abstractions or generalizations trying to future proof stuff.
- zeroonetwothree 3mo ago
  That’s the opposite of the typical definition of tech debt. Usually tech debt is debt—-ie something you take on to ship faster now at the expense of paying it in the long run.
  - skydhash 3mo ago
    The tech debt comes after the implementation of the many abstractions. Instead of removing them (which can be really hard), you take the easy option of following the complex design, which also make the removal incrementally harder.
  - rcxdude 3mo ago
    Unused abstractions are tech debt, whether they were previously used or (even worse) never used. They constrain and complicated the addition of other features and abstractions within the code. It's almost always easier to start with a codebase that is simpler and with fewer abstractions and take it in a given direction than it is one with lots of abstractions which don't suit the direction you want to take it. (and of course, everyone imagines that their abstractions will be in the right direction, but this is rarely the case). Unused abstractions are pure waste, because they take effort to make and effort to remove and never produce any value.
- cauch 3mo ago
  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.
- ajb 3mo ago
  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.
dang 3mo ago
"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 https://news.ycombinator.com/newsguidelines.html
gofreddygo 3mo ago
> 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 3mo ago
  I still prefer the upsides of a shared vocabulary for talking about programming.
  - gofreddygo 3mo ago
    The programming language is the shared vocabulary Everything above are made up leaky abstractions with a handful of exceptions
    - actionfromafar 3mo ago
      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.
cauch 3mo ago
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 3mo ago
  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 3mo ago
    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.
bazoom42 3mo ago
YAGNI is not about things you know you need, because then you wouldn’t write any code ever.
- Scubabear68 3mo ago
  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.
  - bazoom42 3mo ago
    Are you referring to some particular projects, or to the early stages of every project?
    - Scubabear68 3mo ago
      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.
      - bazoom42 3mo ago
        Ah, that sounds like a classic mistake - rewriting a system from scratch without fully understanding what the system actually does.

fmbb 3mo ago

All tech debt I have ever seen in my 15 years of professional software development has been someone building too many abstractions or generalizations trying to future proof stuff.

zeroonetwothree 3mo ago
That’s the opposite of the typical definition of tech debt. Usually tech debt is debt—-ie something you take on to ship faster now at the expense of paying it in the long run.
- skydhash 3mo ago
  The tech debt comes after the implementation of the many abstractions. Instead of removing them (which can be really hard), you take the easy option of following the complex design, which also make the removal incrementally harder.
- rcxdude 3mo ago
  Unused abstractions are tech debt, whether they were previously used or (even worse) never used. They constrain and complicated the addition of other features and abstractions within the code. It's almost always easier to start with a codebase that is simpler and with fewer abstractions and take it in a given direction than it is one with lots of abstractions which don't suit the direction you want to take it. (and of course, everyone imagines that their abstractions will be in the right direction, but this is rarely the case). Unused abstractions are pure waste, because they take effort to make and effort to remove and never produce any value.
cauch 3mo ago
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.
ajb 3mo ago
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.

dang 3mo ago

"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 https://news.ycombinator.com/newsguidelines.html

gofreddygo 3mo ago

> 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 3mo ago
I still prefer the upsides of a shared vocabulary for talking about programming.
- gofreddygo 3mo ago
  The programming language is the shared vocabulary Everything above are made up leaky abstractions with a handful of exceptions
  - actionfromafar 3mo ago
    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.

cauch 3mo ago

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

bazoom42 3mo ago

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

Scubabear68 3mo ago
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.
- bazoom42 3mo ago
  Are you referring to some particular projects, or to the early stages of every project?
  - Scubabear68 3mo ago
    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.
    - bazoom42 3mo ago
      Ah, that sounds like a classic mistake - rewriting a system from scratch without fully understanding what the system actually does.