3 ms·

> Spec-Driven Development changes this: specifications become executable, directly generating working implementations rather than just guiding them. Reminds me

> Spec-Driven Development changes this: specifications become executable, directly generating working implementations rather than just guiding them. Reminds me of TDD bandwagon which was all the rage when I started programming. It took years to slowly die out and people realized how overhyped it really was. Nothing against AI, I love it as a tool, but this "you-don't-need-code" approach shows similar signs. Quick wins at first, lots of hype because of those wins, and then reaching a point where doing even tiny changes becomes absurdly difficult. You need code. You will need it for a long time.

discreteevent 11mo ago
There was a really good article on this here a few days ago that didn't get much traction. It was about how programming is a learning feedback loop and because of that there are good and bad ways to use LLMs: "The readymade components we use are essentially compressed bundles of context—countless design decisions, trade-offs, and lessons are hidden within them. By using them, we get the functionality without the learning, leaving us with zero internalized knowledge of the complex machinery we've just adopted. This can quickly lead to sharp increase in the time spent to get work done and sharp decrease in productivity." https://martinfowler.com/articles/llm-learning-loop.html https://martinfowler.com/articles/llm-learning-loop.html
- dennisy 11mo ago
  This is a great read and one which for me personally really summarises my feeling on developing with LLMs.
lloydatkinson 11mo ago
Well done on conflating BDD and TDD then, I suppose.
CPLX 11mo ago
What's wrong with TDD? This is a serious question, not starting an argument.
- BobbyTables2 11mo ago
  Try it and you’ll quickly see…
  - CPLX 11mo ago
    I have. I don’t hate it, though I don’t think it’s a magic bullet either.
- jmann99999 11mo ago
  My issue with it has always been that I just don't think the way TDD requires. I think in terms of building features. TDD generally requires thinking in terms of proving behavior. I still can't wrap my head around first writing a test that fails and then writing minimal code to make it pass (I know I am simplifying it). Different strokes for different folks. I'm sure it works great for some people but not for me.
  - moi2388 11mo ago
    Well, all it does is basically enforce you code with testing (abstraction) in mind, and only focus on what you need. So you build feature A. Great. Why not write a test to instantiate the feature? It will fail, because you haven’t built it yet. Now go build it. I assume you build the interface first already, before every little detail of the methods? Also, you really don’t have to stick to the TDD principles that much. It’s basically to ensure: 1. You have a test which can fail (it actually tests something) 2. You actually have a test for your unit 3. You actually only code what you’re supposed to This is great for juniors, but as you have more experience, these individual steps lose value, but the principles remain I think. Also, I would never write tests for every method (as TDD might have you believe), because that’s not my “unit” in unit testing.
MoreQARespect 11mo ago
>Reminds me of TDD bandwagon which was all the rage when I started programming. It took years to slowly die out and people realized how overhyped it really was. It never really went away. The problem is that there is a dearth of teaching materials telling people how to do it properly: * E2E test first * Write high level integration tests which match requirements by default * Only start writing lower level unit tests when a clear and stable API emerges. and most people when they tried it didn't do that. They mostly did the exact opposite: * Write low level unit tests which match the code by default. * Never write a higher level tests (some people don't even think it's possible to write an integration or e2e test with TDD because "it has to be a unit test").
- nchmy 11mo ago
  Would you be able to share any links that expand upon your recommended approach? It makes complete sense to me as a self-taught dev, and is what I've always done (most recently, an e2e test of a realtime cdc etl pipeline, checking for/logging and fixing various things along the way until I was getting the right final output). I rarely write unit tests. It would be good to read something more formal in support of what I've naturally gravitated towards
  - MoreQARespect 11mo ago
    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.
    - nchmy 11mo ago
      I just remembered this essay from the creator of HTMX. My approach is very similar. https://htmx.org/essays/codin-dirty/ https://htmx.org/essays/codin-dirty/
- BobbyTables2 11mo ago
  Not even sure the problem is just education. For something complex, it’s kinda hard to write and debug high level tests when all the lower level functionality is missing and just stubbed out. We don’t expect people to write working software that cannot be executed first, yet we expect people to write (and complete) all tests before the actual implementation. Sure for trivial things, it’s definitely doable. But then extensive tests wouldn’t be needed for such either! Imagine someone developing an application where the standard C library was replaced with a stub implementation… That wouldn’t work… Yet TDD says one should be able to do pretty much the same thing…
adastra22 11mo ago
Test-driven development… died out? Have I been living under a rock?

discreteevent 11mo ago

There was a really good article on this here a few days ago that didn't get much traction. It was about how programming is a learning feedback loop and because of that there are good and bad ways to use LLMs: "The readymade components we use are essentially compressed bundles of context—countless design decisions, trade-offs, and lessons are hidden within them. By using them, we get the functionality without the learning, leaving us with zero internalized knowledge of the complex machinery we've just adopted. This can quickly lead to sharp increase in the time spent to get work done and sharp decrease in productivity." https://martinfowler.com/articles/llm-learning-loop.html https://martinfowler.com/articles/llm-learning-loop.html

dennisy 11mo ago
This is a great read and one which for me personally really summarises my feeling on developing with LLMs.

lloydatkinson 11mo ago

Well done on conflating BDD and TDD then, I suppose.

CPLX 11mo ago

What's wrong with TDD? This is a serious question, not starting an argument.

BobbyTables2 11mo ago
Try it and you’ll quickly see…
- CPLX 11mo ago
  I have. I don’t hate it, though I don’t think it’s a magic bullet either.
jmann99999 11mo ago
My issue with it has always been that I just don't think the way TDD requires. I think in terms of building features. TDD generally requires thinking in terms of proving behavior. I still can't wrap my head around first writing a test that fails and then writing minimal code to make it pass (I know I am simplifying it). Different strokes for different folks. I'm sure it works great for some people but not for me.
- moi2388 11mo ago
  Well, all it does is basically enforce you code with testing (abstraction) in mind, and only focus on what you need. So you build feature A. Great. Why not write a test to instantiate the feature? It will fail, because you haven’t built it yet. Now go build it. I assume you build the interface first already, before every little detail of the methods? Also, you really don’t have to stick to the TDD principles that much. It’s basically to ensure: 1. You have a test which can fail (it actually tests something) 2. You actually have a test for your unit 3. You actually only code what you’re supposed to This is great for juniors, but as you have more experience, these individual steps lose value, but the principles remain I think. Also, I would never write tests for every method (as TDD might have you believe), because that’s not my “unit” in unit testing.

MoreQARespect 11mo ago

>Reminds me of TDD bandwagon which was all the rage when I started programming. It took years to slowly die out and people realized how overhyped it really was. It never really went away. The problem is that there is a dearth of teaching materials telling people how to do it properly: * E2E test first * Write high level integration tests which match requirements by default * Only start writing lower level unit tests when a clear and stable API emerges. and most people when they tried it didn't do that. They mostly did the exact opposite: * Write low level unit tests which match the code by default. * Never write a higher level tests (some people don't even think it's possible to write an integration or e2e test with TDD because "it has to be a unit test").

nchmy 11mo ago
Would you be able to share any links that expand upon your recommended approach? It makes complete sense to me as a self-taught dev, and is what I've always done (most recently, an e2e test of a realtime cdc etl pipeline, checking for/logging and fixing various things along the way until I was getting the right final output). I rarely write unit tests. It would be good to read something more formal in support of what I've naturally gravitated towards
- MoreQARespect 11mo ago
  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.
  - nchmy 11mo ago
    I just remembered this essay from the creator of HTMX. My approach is very similar. https://htmx.org/essays/codin-dirty/ https://htmx.org/essays/codin-dirty/
BobbyTables2 11mo ago
Not even sure the problem is just education. For something complex, it’s kinda hard to write and debug high level tests when all the lower level functionality is missing and just stubbed out. We don’t expect people to write working software that cannot be executed first, yet we expect people to write (and complete) all tests before the actual implementation. Sure for trivial things, it’s definitely doable. But then extensive tests wouldn’t be needed for such either! Imagine someone developing an application where the standard C library was replaced with a stub implementation… That wouldn’t work… Yet TDD says one should be able to do pretty much the same thing…

adastra22 11mo ago

Test-driven development… died out? Have I been living under a rock?