4 ms·

Is TDD really about never figuring out unknowns using untested code? What about using diagrams? Or white boarding? Test first design makes a lot of sense, but

by bvirb 5y ago

Is TDD really about never figuring out unknowns using untested code? What about using diagrams? Or white boarding? Test first design makes a lot of sense, but when you’re unsure about the design using code to figure it out seems just as reasonable as any other method. If not what’s left? Do everything waterfall?

ipaddr 5y ago
I would like to see waterfall make a comeback. No one agile's alone but many waterfall.
- Jtsummers 5y ago
  Waterfall does not need to make a comeback, it never died. It's still a gross and stupid process for anything but trivial projects or well-understood (by the developers) domains. If you're working on a large scale project, it's one of the worst ways to work. The next worst is to just type on a keyboard and hope you manage to write code and somehow trigger the build and deploy commands.
- duped 5y ago
  Waterfall is alive and well, most places just refer to it as something else like "agile" or "scrum."
  - thibauts 5y ago
    When tests amount to specs waterfall tends be be referred to as TDD.
    - Jtsummers 5y ago
      No, because TDD (at least as defined) does not have you spend months to years up front just writing tests. You write them at the same time as (well, in strict TDD just prior to) writing the code and (possibly) other artifacts. Waterfall says, "Spend a stupidly long amount of time coming up with detailed requirements and specs and a hyper-detailed, and likely wrong, development and test plan. Then don't receive any feedback until you test, which is verification and conducted after the development is done, and deliver, which is validation." TDD at least has you do the verification part throughout the development process.
      - thibauts 5y ago
        You’re right, I pushed it a bit too far. What I was feeling and trying to convey is how it flips the design process from bottom up to top down, by forcing the design of the interface first. From my experience you miss a lot by doing that. The reason is when you start from the code interface based on some requirements you most often find an impedance mismatch when you reach the bottom AND you don’t get the chance to tweak or rethink the requirements from straight, simple bottom-up code. Requirements being natural language and by nature informal and incomplete (else they would be code), building on them is risky. Building on the software APIs you stand on (starting at the bottom) is much less prone to change. This is the sound approach in my opinion from an engineering perspective. You start from what exists and what you stand on and grow you software by aiming for the requirements, trying to land the closer you can to them. This process of discovering natural interfaces that emerge when you specialize a lower software layer API is the most profound and impactful realisation (and huge boost in both productivity and quality) I had in 25 years of programming. Everything starts to fit, have easy path forwards, becomes easy to maintain and evolve. I think the gut feeling I have when I see people advocating for TDD is that. I feel it will prevent proper co-evolution of code and requirements, and lead to the usual mess.

by bvirb 5y ago

ipaddr 5y ago

I would like to see waterfall make a comeback. No one agile's alone but many waterfall.

Jtsummers 5y ago
Waterfall does not need to make a comeback, it never died. It's still a gross and stupid process for anything but trivial projects or well-understood (by the developers) domains. If you're working on a large scale project, it's one of the worst ways to work. The next worst is to just type on a keyboard and hope you manage to write code and somehow trigger the build and deploy commands.
duped 5y ago
Waterfall is alive and well, most places just refer to it as something else like "agile" or "scrum."
- thibauts 5y ago
  When tests amount to specs waterfall tends be be referred to as TDD.
  - Jtsummers 5y ago
    No, because TDD (at least as defined) does not have you spend months to years up front just writing tests. You write them at the same time as (well, in strict TDD just prior to) writing the code and (possibly) other artifacts. Waterfall says, "Spend a stupidly long amount of time coming up with detailed requirements and specs and a hyper-detailed, and likely wrong, development and test plan. Then don't receive any feedback until you test, which is verification and conducted after the development is done, and deliver, which is validation." TDD at least has you do the verification part throughout the development process.
    - thibauts 5y ago
      You’re right, I pushed it a bit too far. What I was feeling and trying to convey is how it flips the design process from bottom up to top down, by forcing the design of the interface first. From my experience you miss a lot by doing that. The reason is when you start from the code interface based on some requirements you most often find an impedance mismatch when you reach the bottom AND you don’t get the chance to tweak or rethink the requirements from straight, simple bottom-up code. Requirements being natural language and by nature informal and incomplete (else they would be code), building on them is risky. Building on the software APIs you stand on (starting at the bottom) is much less prone to change. This is the sound approach in my opinion from an engineering perspective. You start from what exists and what you stand on and grow you software by aiming for the requirements, trying to land the closer you can to them. This process of discovering natural interfaces that emerge when you specialize a lower software layer API is the most profound and impactful realisation (and huge boost in both productivity and quality) I had in 25 years of programming. Everything starts to fit, have easy path forwards, becomes easy to maintain and evolve. I think the gut feeling I have when I see people advocating for TDD is that. I feel it will prevent proper co-evolution of code and requirements, and lead to the usual mess.