4 ms·

> 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

> 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.
- spellboots 13y ago
  Perhaps you haven't seen it work, I have seen it work many times, and like I said, it is about tradeoffs. You trade increased development time for higher quality software. I think it's quite bizarre to be arguing that TDD is not agile when it is an explicitly agile methodology. Kent Beck, the inventor of TDD, is an author of the agile manifesto that you quote. The authors of the document clearly disagree with your interpretation of it. >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. This is a strawman argument. TDD does not imply working out how to machine test something before it's been discussed and planned by a human. If you need to try it agile has a concept of spikes. This is not an argument against TDD because this does not describe TDD. >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? Tests are part of the code. Why write code you don't keep? Yes, you have to throw away tests if you throw away code but this is not a TDD issue. The issue is you're throwing away the code (of which the tests are a part). > 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. No, changing and adapting is easier when you have tests because you can be sure that you haven't broken anything. If tests fail when you change things, either the requirements have changed so you change the tests, or you've accidentally broken something and the tests have caught it. Tests should be written at the same time as the code to validate that the assumptions of the developer at the time the code is written remain true. > Working software is the principal measure of progress The working part is important - if comprehensive tests reduce defects in software - which is a pretty uncontroversial statement, if you disagree with this statement you are at odds with all the published research on the matter I have seen - then writing tests helps your progress by helping to deliver working software. > 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. And again, I repeat, this is an engineering tradeoff. Is speed more important that quality for your business case? Then TDD is a bad fit.

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.

spellboots 13y ago
Perhaps you haven't seen it work, I have seen it work many times, and like I said, it is about tradeoffs. You trade increased development time for higher quality software. I think it's quite bizarre to be arguing that TDD is not agile when it is an explicitly agile methodology. Kent Beck, the inventor of TDD, is an author of the agile manifesto that you quote. The authors of the document clearly disagree with your interpretation of it. >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. This is a strawman argument. TDD does not imply working out how to machine test something before it's been discussed and planned by a human. If you need to try it agile has a concept of spikes. This is not an argument against TDD because this does not describe TDD. >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? Tests are part of the code. Why write code you don't keep? Yes, you have to throw away tests if you throw away code but this is not a TDD issue. The issue is you're throwing away the code (of which the tests are a part). > 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. No, changing and adapting is easier when you have tests because you can be sure that you haven't broken anything. If tests fail when you change things, either the requirements have changed so you change the tests, or you've accidentally broken something and the tests have caught it. Tests should be written at the same time as the code to validate that the assumptions of the developer at the time the code is written remain true. > Working software is the principal measure of progress The working part is important - if comprehensive tests reduce defects in software - which is a pretty uncontroversial statement, if you disagree with this statement you are at odds with all the published research on the matter I have seen - then writing tests helps your progress by helping to deliver working software. > 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. And again, I repeat, this is an engineering tradeoff. Is speed more important that quality for your business case? Then TDD is a bad fit.