4 ms·

TDD is an implicit repudiation of Agile. One of the principals of the original Agile manifesto was "working software over comprehensive documentation". After al

by yyyk 5y ago

TDD is an implicit repudiation of Agile. One of the principals of the original Agile manifesto was "working software over comprehensive documentation". After all, a test is a form of documentation, albeit one that is more suited to a programmer's tastes. Agile places software and documentation at opposition - TDD tries to tie them together.

dragonwriter 5y ago
> TDD is an implicit repudiation of Agile. TDD was developed in the 1990; Agile was articulated in 2001. Were they actually opposed, “Agile is a repudiation of TDD” would be more defensible. But your basic premise is wrong... > Agile places software and documentation at opposition No, the “X over Y” statements in the Manifesto aren't about opposition, they are about subordination. ”over” can be substituted with “should shape the use of” rather than “should exist instead of”
- yyyk 5y ago
  You're right about the historical chronology, but TDD adoption IMHO came much later, after Agile exploded in popularity. Maybe it's just my neck of the woods, but I heard of TDD only much later. As for the "X over Y" statements, well, it's a rhetorical style which definitely creates an implicit opposition. Subordination makes no sense here. Our job and the business value is in working software, of course we want that most of all. Why mention it over something unless that something is in the way and we want to discourage it? Let's say I told people "Crossing the road over obsessively looking at both sides of the road"*, and kept referring to "obsessive looking" while barely mentioning people should look at all. As guidance this is horrible, for reasons I believe are obvious. If I said later "I only meant obsessive looking" and "you should adjust your crossing process so it suits you" it wouldn't make my advice right, would it now? * Documentation is of course much less necessary, I'm just taking an extreme example to show the rhetorical style.
  - Jtsummers 5y ago
    > That is, while there is value in the items on the right, we value the items on the left more. The value of the items on the right (per the manifesto, if you disagree on the relative values that part can be debated) is lower than the value of the items on the left, but it is not zero or negative.
    - yyyk 5y ago
      I think I've alrady explained why I don't find that adequate at all. If we were to declare doing X as contrary to getting the job done, always describe X with demeaning or excessive terms, and give no limiting principal when X is actually important, we shouldn't get shocked when people read what we wrote, and decide X is at best unimportant, because that's what we really wrote whatever we intended. Sure, we could later write a blog saying 'we never actually told you not to do X' and be technically correct, but in reality we gave bad guidance that drove people away from X even when X was actually important.

by yyyk 5y ago

dragonwriter 5y ago

> TDD is an implicit repudiation of Agile. TDD was developed in the 1990; Agile was articulated in 2001. Were they actually opposed, “Agile is a repudiation of TDD” would be more defensible. But your basic premise is wrong... > Agile places software and documentation at opposition No, the “X over Y” statements in the Manifesto aren't about opposition, they are about subordination. ”over” can be substituted with “should shape the use of” rather than “should exist instead of”

yyyk 5y ago
You're right about the historical chronology, but TDD adoption IMHO came much later, after Agile exploded in popularity. Maybe it's just my neck of the woods, but I heard of TDD only much later. As for the "X over Y" statements, well, it's a rhetorical style which definitely creates an implicit opposition. Subordination makes no sense here. Our job and the business value is in working software, of course we want that most of all. Why mention it over something unless that something is in the way and we want to discourage it? Let's say I told people "Crossing the road over obsessively looking at both sides of the road"*, and kept referring to "obsessive looking" while barely mentioning people should look at all. As guidance this is horrible, for reasons I believe are obvious. If I said later "I only meant obsessive looking" and "you should adjust your crossing process so it suits you" it wouldn't make my advice right, would it now? * Documentation is of course much less necessary, I'm just taking an extreme example to show the rhetorical style.
- Jtsummers 5y ago
  > That is, while there is value in the items on the right, we value the items on the left more. The value of the items on the right (per the manifesto, if you disagree on the relative values that part can be debated) is lower than the value of the items on the left, but it is not zero or negative.
  - yyyk 5y ago
    I think I've alrady explained why I don't find that adequate at all. If we were to declare doing X as contrary to getting the job done, always describe X with demeaning or excessive terms, and give no limiting principal when X is actually important, we shouldn't get shocked when people read what we wrote, and decide X is at best unimportant, because that's what we really wrote whatever we intended. Sure, we could later write a blog saying 'we never actually told you not to do X' and be technically correct, but in reality we gave bad guidance that drove people away from X even when X was actually important.