> Actually your whole post is so relentlessly negative and petty (SCUM? FrAgile?) I won't give it credence. Have a sense of humor. If TDD works for you, conti

> Actually your whole post is so relentlessly negative and petty (SCUM? FrAgile?) I won't give it credence. Have a sense of humor. If TDD works for you, continue using it. I've done TDD before and sometimes still do. Sometimes people are negative for a reason. I've seen enough iterations of these methodologies that I don't think they have any special value. Should a cattle ranch be more "agile?" Maybe, but honestly, I doubt that would end well. That's an extreme example, but even different software products may not necessitate the same workflows that these methodologies are intended to create. The point is there isn't necessarily anything in particular about any of these loosely related methodologies that makes them special or effective for everything. In fact, they fail to live up to their promise quite often because they're treated as if they've been proven to be more effective than hypothetical alternatives, which simply isn't true. > the only justification for a thing is if it works. If they regularly do, as you just acknowledged they do multiple times, they're of value. Yes. However, I've personally never been with an organization that actually attempted to measure whether a methodology was working or not. My guess is, the vast majority of the time, methodologies are a magic talisman to ward off the bad C-level spirits and bring good fortune to middle management, and sometimes make it look like more work is being done than is actually. I'm sure those organizations exist, but if they are actually willing to do such honest self assessment, they're probably capable of arriving at the same place without needing a pre-built methodology to start with.