MoreQARespect

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.

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.

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.

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.

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.

Iterate on the design til the snapshots look the way the design team wants.

That's just an extended red where you get feedback from elsewhere.

Um, show the snapshot to a designer? When it feels right, lock in the snapshot ("green") and then move on to refactor.

Or, probably more likely a group of snapshots.

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.

https://hitchdev.com/hitchstory/approach/snapshot-test-drive...

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.

That is a flaw with unit tests written at far too low a level, not with TDD.

You would have the same problem if you wrote tests like that after the code.

TDD has no opinion about the level at which you wrote your test, it just assumes it's the correct one.

This is the number one biggest misconception about TDD which I keep seeing repeated on hacker news.

https://news.ycombinator.com/item?id=46810793

https://news.ycombinator.com/item?id=45113016

The problem with gherkin is that it was a badly designed language.

The general idea of "readable specification language" was an inspired one but it failed on execution - it has gnarly syntax, no typing and bad abstractions.

This results in poor tests which are hard to maintain and diverge between being either too repetitive to be useful or too vague to be useful.

The ecosystem is big but it's built on crumbling foundations which is why when most people used it most of them got frustrated and gave up on it.

Annoyingly there's a certain amount of gaslighting around it too ("it didnt work for you coz you werent using it correctly") which is eleven different kinds of wrong.

Yes, except a test can be turing complete - i.e. code.

An executable spec like gherkin or hitchstory is config - it has no loops or conditionals. There are a number of rarely recognized benefits to this.

Ive almost never worked on a project where there was the right number of QAs who were doing the right thing.

Usually there either arent any in which case bugs get missed or there are 5 very cheap ones running mindless scripts who are standing in for the devs' inability or unwillingness to write decent automated tests but dont catch the really deep level thorny stuff.

Really? The best people I worked with were never QA.

Moreover, the best QAs would almost always try to be not QA - to shift into a better respected and better paid field.

I wish it werent so (hence my username) but there is a definite class divide between devs and QA and it shows up not just in terms of the pay packets but also who gets the boot in down times and who gets listened to. This definitely affects the quality of people.

I think it's overdue an overhaul much like the sysadmin->devops transition.

I never said he was "truly independent" nor meant to imply it.

Nonetheless it looks like he was both willing and able to push back on a good deal of the AI stupidity raining down from above and then he was removed and then, well, this...

It operated with an independent CEO for a long while.

When I saw his interview: https://thenewstack.io/github-ceo-on-why-well-still-need-hum... i thought "oh, there is some semblance of sanity at Microsoft".

This was after seeing those ridiculous PRs where microsoft engineers patiently deconstructed AI slop PRs they were forced to deal with on the open source repos they maintained.

When he was gone a few months later and github was folded into microsoft's org chart the writing was firmly on the wall.

This makes much more sense as an zoom-buys-keybase style acquihire. I bet within a month the astral devs will be on new projects.

Bundling codex with uv isnt going to meaningfully affect the number of people using it. It doesnt increase the switching costs or anything.

any of them.

Putting LLMs on a pedestal is very much in vogue these days.

Humans have the ability to retrospect, push back on a faulty spec, push back on an unclarified spec, do experiments, make judgement calls and build tools and processes to account for their own foibles.

I've been trying to push people to use hitchstory or similar to generate docs from specification tests precisely to avoid that redundancy but most people just look blankly at it and go "why don't you just do that with AI?"

Youve been able to hire a dirt cheap Indian or fillipino living on poverty wages in those countries to knock out cheap crap for a long time.

This is all good advice.

I find that 80% of the time the assumptions i made doing detailed planning are invalidated when doing the actual work.

Usually whole subtasks need to be junked and others created.

The basic premise of TDD, for those unaware, is that one first writes a unit test that verifies the expected behavior for some function

No, not "some function". The tests should mimic the expected behavior of a scenario using the app.

Only if the function is acting as a close approximation of the app itself do you get any benefits out of TDDing it.

90% of the shitty tests I've ever seen in my life - whether written with TDD or without - have been written as a result of a mid level developer thinking that the test should "surround some function" (they dont seem to think it matters which ones you pick) rather than reflecting an actual user story.

This blog post is a reflection of that same attitude.

Testing is probably my favorite topic in development and I kind of wish I could make it my "official" specialty but no way in hell am I taking a pay cut and joining the part of the org nobody listens to.

This paper has 7 references and 4 of them are to a single google blog post that treats test flakiness as an unavoidable fact of life rather than a class of bug which can and should be fixed.

Aside from the red flag of one blog post being >50% of all citations it is also the saddest blog post google ever put their name to.

There is very little of interest in this paper.

Coz while devs with specialties usually get paid more than a generalist, for some reason testing as a specialty means getting a pay cut and a loss in respect and stature.

Hence my username.

I wouldnt ever sell myself as a test automation engineer but whenever i join a project the number one most broken technical issue in need of fixing is nearly always test automation.

I typically brand this work as architecture (and to be fair there is overlap) and try to build infra and tooling less skilled devs can use to write spec-matching tests.

Sadly if i called it test automation i'd have to take a pay cut and get paid less than those less skilled devs who need to be trained to do TDD.

no, but i have a feeling i should write one because i keep running into this misunderstanding.

it makes it really hard to recommend TDD when people believe they already know what it is but are doing it ass backwards.