3 ms·

> Just because a methodology appears to work for one or even multiple organizations doesn't mean it's going to work in every case the only justification for a

> Just because a methodology appears to work for one or even multiple organizations doesn't mean it's going to work in every case 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. > and no one has demonstrated actual cause and effect If repeated success S correlates with repeated use of methodology M, that's a damn strong sign of causation, and if it isn't, I'd still use it. Actually your whole post is so relentlessly negative and petty (SCUM? FrAgile?) I won't give it credence. I personally use for my own projects TDD and plenty of comments in my code and it works (or correlates if you prefer...) very well with good results.

ravenstine 4y ago
> 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.
peoplefromibiza 4y ago
> If repeated success S correlates with repeated use of methodology M, that's a damn strong sign of causation, and if it isn't, I'd still use it. the problem is that several different methodologies "worked multiple times" in practice, over the time, often in the same company, and every time the managers of the era sold it as "a great innovation" and abandoned it for the new trendy fad few years later or because the new manager had different ideas and brought a different "culture" (scrum masters that charged thousands euro/day COUGH COUGH). See many Google engineers that considered agile nonsense (for Google), no more than 3-4 years ago. So basically it doesn't matter which one you chose.

ravenstine 4y ago

> 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.

peoplefromibiza 4y ago

> If repeated success S correlates with repeated use of methodology M, that's a damn strong sign of causation, and if it isn't, I'd still use it. the problem is that several different methodologies "worked multiple times" in practice, over the time, often in the same company, and every time the managers of the era sold it as "a great innovation" and abandoned it for the new trendy fad few years later or because the new manager had different ideas and brought a different "culture" (scrum masters that charged thousands euro/day COUGH COUGH). See many Google engineers that considered agile nonsense (for Google), no more than 3-4 years ago. So basically it doesn't matter which one you chose.