11–20 of 151 posts
[flagged]
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.
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”.
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”.
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”.
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.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”.
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.
Usually tech debt is debt—-ie something you take on to ship faster now at the expense of paying it in the long run.
[flagged]
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.
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”.
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.
Hardware has some hard limitations. The reason software was even invented at all was precisely to escape those limitations.
> 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.
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.
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.
Interesting. How do chip companies plan such projects? Do they use agile, waterfall, or some other non-software-industry frameworks?