3 ms·

My problem with TDD is that it, fundamentally, isn't agile. It either relies on a waterfall-like process where the full design is known before-hand and therefor

by sambeau 13y ago

My problem with TDD is that it, fundamentally, isn't agile. It either relies on a waterfall-like process where the full design is known before-hand and therefore what tests have to be written, or it locks a programmer (and designer) into a position where to iterate and/or backtrack would require not only new code to be written but new tests. It it is very hard for a designer to ask for changes once tests are written. I much prefer a looser arrangement where code (and design) are gradually locked down after prototyping, backtracking and iteration. Code gets thrown away and rewritten but tests are only created once — after the implementation (and by definition the design) is locked-down. It is the very generation of the tests that tells the world that this design is unlikely to change and documentation is safe to create, performance tests & optimisation passes are able to be made. Of course, after tests are created, a programmer is free to refactor safely and replace all the code as long as the tests continue to pass. There are occasions where it makes good sense though. For instance, if you are writing a Maths library or the core business logic of an accounting app. However, these are both essentially examples of a waterfall-like development process.

spellboots 13y ago
It's not true to say that TDD isn't agile. They are orthoganal - you can be agile and do TDD and you can do waterfall development and not do TDD. The fact that you need to change tests to change the software is the whole point - if you change the functionality, you change the tests. In fact, it's not wanting to change the tests that causes the problem here. Perhaps you have been on bad projects where TDD has been used improperly. However every single agile development team I have worked with has used TDD, and it certainly does not limit things in the way you suggest. Ironically, Extreme Programming [1], one of the first of the agile methodologies, and many other agile methodologies since, include TDD as a core tenet. So in fact by saying "TDD isn't agile" you are perhaps demonstrating a misunderstanding of what "agile" development was designed to be. [1] https://en.wikipedia.org/wiki/Extreme_Programming https://en.wikipedia.org/wiki/Extreme_Programming
- sambeau 13y ago
  In fact, it's not wanting to change the tests that causes the problem here This is the point I was making. Programmers never want to change the tests as, often, it has taken as long to create the tests than it did to write the code. It adds a layer of syrup to the whole process. You can no longer be nimble as you are carrying the weight of the tests. And, yes, I've worked with precious designers who don't want to change their design when a first iteration clearly shows that it isn't working. But to be truly agile (and I'm not talking about some written methodology here — I mean agile as in nimble) you need to work quickly, try things out and make mistakes. Writing your tests first is a encumbrance. Perhaps you have been on bad projects where TDD has been used improperly This is what everyone says the moment their dogma is questioned. I've read the books, I've been on the training courses and I have certificates in my drawer. My experience is, if you want to create anything well-designed you need to iterate and there is no point in writing tests until your design is fixed it just slows everything down.
  - spellboots 13y ago
    > But to be truly agile (and I'm not talking about some written methodology here — I mean agile as in nimble) you need to work quickly, try things out and make mistakes. Writing your tests first is a encumbrance. Perhaps it makes sense to be explicit about this when talking about it, as "agile" has a commonly accepted meaning in software development terms and this is not it. > This is what everyone says the moment their dogma is questioned. You have said "TDD is that it, fundamentally, isn't agile" and have asserted that you can't use it to be agile. I have stated (in a sibling comment) that TDD is a business decision, where you trade increased development time for higher software quality, and cited a study on the matter that is non-anecdotal. Your position is the dogmatic one by the commonly accepted definition of "dogmatic".
    - sambeau 13y ago
      OK lets examine the commonly accepted meaning of Agile Development and see where TDD fits in. TDD is at odds with half of the Agile Manifesto, namely: * Individuals and interactions over processes and tools * Responding to change over following a plan You should first try stuff out and discuss it rather than working out how to machine test it before its been tried by a human. Having tests first is clearly having a plan first. TDD also rubs up against two principals of the Agile Manifesto, namely: * Welcome changing requirements, even late in development * Regular adaptation to changing circumstances It's hard-enough to welcome changing requirements when you have to rewrite software without having to rewrite all the tests too. Why write tests for code you don't keep? Changing and adapting is harder when you are encumbered by tests. Tests should be written once you've agreed that what you have now is what you are going to keep. TDD adherents I have worked with in the past also rub up against this one: * Working software is the principal measure of progress Tests are not 'working software', they are a protective covering you put over working software to make sure it doesn't get ruined as people work around it. At its heart Agile is about being adaptive: evolutionary changing plans, iteration, rapid and flexible response to change. TDD brings overhead: tests that needn't ever have been written; tests that needn't ever have been re-written. They hamper iteration and flexible response as they make it more costly to change plans.
majelix 13y ago
> It either relies on a waterfall-like process where the full design is known before-hand and therefore what tests have to be written, This is that fuzzy line between behavior driven development and test driven development. Sure, you may not be able to write cukes to test how that your social mortgage site is going to work, but you probably should be writing tests to ensure that your internal compound interest code is correct.
- sambeau 13y ago
  I say exactly that in my comment. I'm not suggesting that tests shouldn't be written — I'm suggesting that tests shouldn't be re-written without just cause.
mattmanser 13y ago
What designer? The front end guy? The PM? What are you talking about? Have you got an architect making edicts from high? That in itself sounds like it is fundamentally not agile. I'm not especially a fan of TDD, but this comment makes no sense to me, it doesn't marry with my experience creating software. TDD is around individual methods, trying to make them decoupled. It is around unit tests. Changing the design simply means deleting those methods and throwing away those unit tests. Which you would do anyway.
- sambeau 13y ago
  What designer? Small agile teams don't have a designer and a 'front-end guy' and a 'PM' and an 'architect'. They often only have one and in my case he (I) is also the PM (or PO in our case). Design-led software requires a designer. In large projects you might break this up into lots of different roles with trendy titles but they are all just designers, just as a database programmer and a graphics programmer are just programmers. Changing the design simply means deleting those methods and throwing away those unit tests. Which is wasted work, wasted time and totally dispiriting for a developer.

by sambeau 13y ago

spellboots 13y ago

It's not true to say that TDD isn't agile. They are orthoganal - you can be agile and do TDD and you can do waterfall development and not do TDD. The fact that you need to change tests to change the software is the whole point - if you change the functionality, you change the tests. In fact, it's not wanting to change the tests that causes the problem here. Perhaps you have been on bad projects where TDD has been used improperly. However every single agile development team I have worked with has used TDD, and it certainly does not limit things in the way you suggest. Ironically, Extreme Programming [1], one of the first of the agile methodologies, and many other agile methodologies since, include TDD as a core tenet. So in fact by saying "TDD isn't agile" you are perhaps demonstrating a misunderstanding of what "agile" development was designed to be. [1] https://en.wikipedia.org/wiki/Extreme_Programming https://en.wikipedia.org/wiki/Extreme_Programming

sambeau 13y ago
In fact, it's not wanting to change the tests that causes the problem here This is the point I was making. Programmers never want to change the tests as, often, it has taken as long to create the tests than it did to write the code. It adds a layer of syrup to the whole process. You can no longer be nimble as you are carrying the weight of the tests. And, yes, I've worked with precious designers who don't want to change their design when a first iteration clearly shows that it isn't working. But to be truly agile (and I'm not talking about some written methodology here — I mean agile as in nimble) you need to work quickly, try things out and make mistakes. Writing your tests first is a encumbrance. Perhaps you have been on bad projects where TDD has been used improperly This is what everyone says the moment their dogma is questioned. I've read the books, I've been on the training courses and I have certificates in my drawer. My experience is, if you want to create anything well-designed you need to iterate and there is no point in writing tests until your design is fixed it just slows everything down.
- spellboots 13y ago
  > But to be truly agile (and I'm not talking about some written methodology here — I mean agile as in nimble) you need to work quickly, try things out and make mistakes. Writing your tests first is a encumbrance. Perhaps it makes sense to be explicit about this when talking about it, as "agile" has a commonly accepted meaning in software development terms and this is not it. > This is what everyone says the moment their dogma is questioned. You have said "TDD is that it, fundamentally, isn't agile" and have asserted that you can't use it to be agile. I have stated (in a sibling comment) that TDD is a business decision, where you trade increased development time for higher software quality, and cited a study on the matter that is non-anecdotal. Your position is the dogmatic one by the commonly accepted definition of "dogmatic".
  - sambeau 13y ago
    OK lets examine the commonly accepted meaning of Agile Development and see where TDD fits in. TDD is at odds with half of the Agile Manifesto, namely: * Individuals and interactions over processes and tools * Responding to change over following a plan You should first try stuff out and discuss it rather than working out how to machine test it before its been tried by a human. Having tests first is clearly having a plan first. TDD also rubs up against two principals of the Agile Manifesto, namely: * Welcome changing requirements, even late in development * Regular adaptation to changing circumstances It's hard-enough to welcome changing requirements when you have to rewrite software without having to rewrite all the tests too. Why write tests for code you don't keep? Changing and adapting is harder when you are encumbered by tests. Tests should be written once you've agreed that what you have now is what you are going to keep. TDD adherents I have worked with in the past also rub up against this one: * Working software is the principal measure of progress Tests are not 'working software', they are a protective covering you put over working software to make sure it doesn't get ruined as people work around it. At its heart Agile is about being adaptive: evolutionary changing plans, iteration, rapid and flexible response to change. TDD brings overhead: tests that needn't ever have been written; tests that needn't ever have been re-written. They hamper iteration and flexible response as they make it more costly to change plans.

majelix 13y ago

> It either relies on a waterfall-like process where the full design is known before-hand and therefore what tests have to be written, This is that fuzzy line between behavior driven development and test driven development. Sure, you may not be able to write cukes to test how that your social mortgage site is going to work, but you probably should be writing tests to ensure that your internal compound interest code is correct.

sambeau 13y ago
I say exactly that in my comment. I'm not suggesting that tests shouldn't be written — I'm suggesting that tests shouldn't be re-written without just cause.

mattmanser 13y ago

What designer? The front end guy? The PM? What are you talking about? Have you got an architect making edicts from high? That in itself sounds like it is fundamentally not agile. I'm not especially a fan of TDD, but this comment makes no sense to me, it doesn't marry with my experience creating software. TDD is around individual methods, trying to make them decoupled. It is around unit tests. Changing the design simply means deleting those methods and throwing away those unit tests. Which you would do anyway.

sambeau 13y ago
What designer? Small agile teams don't have a designer and a 'front-end guy' and a 'PM' and an 'architect'. They often only have one and in my case he (I) is also the PM (or PO in our case). Design-led software requires a designer. In large projects you might break this up into lots of different roles with trendy titles but they are all just designers, just as a database programmer and a graphics programmer are just programmers. Changing the design simply means deleting those methods and throwing away those unit tests. Which is wasted work, wasted time and totally dispiriting for a developer.