IMHO TDD, like a lot of the agile stuff, is a good idea with solid foundations that people get wrong all the time and end up making things worse with.
So one could reasonably suspect that people who "get agile" are just talented and would be good developers anyway. Occam's razor invites us to assume that agile has no effect. Are there any scientific studies on the effectiveness of agile (or TDD), or is this just a homeopathy situation?
If you're going to ask that, you should tell us which studies you used to select the other techniques you use.
(It turns out that there are, tons actually, but software engineering a difficult topic to study and I wouldn't draw any conclusions from them. The vast majority of controlled software engineering studies I've seen are conducted on students using problems of trivial scope. The uncontrolled ones aren't much better. Basic questions like "what do you mean by productivity" have yet to be answered well.)
Are there any scientific studies on the effectiveness of agile (or TDD), or is this just a homeopathy situation?
Yes (and yes) on TDD. None of the ones discussed in Making Software: what really works and why we believe it were done particularly well, and the less bad ones tended to show no effect or contradictory mixed results (ie, disagreed on what went better vs what went worse).
"Agile" is far too ill-defined to actually study usefully. Specific variants or individual practices could be studied.
nonsense. I'm not an advocate of large process by any means, but a number of principles of the agile movement can benefit developers of any skill level or experience. and more importantly it can help a team collectively more than it can help the individual. the trick is imposing these principles carefully, which almost every agile leader I've met fails to do.
I've never seen anything wrong with more communication between stakeholders and adapting a solution to meet their ever-changing needs.
I've never seen anything wrong with more communication between stakeholders and adapting a solution to meet their ever-changing needs.
Surely there's a point where more communication starts being detrimental. Reducing it to the absurd: if you spend 100% of the time communicating then you have no time left to actually build the thing. So there's a trade-off, as usual.
It could also be argued that ease of communication to deal with "ever-changing needs" encourages more superficial requirements and less deep thinking about the actual problem, leading to wasted effort and lower quality results.
Maybe you are right, maybe the above paragraph is right. I don't know and neither do you. Replying "nonsense" is not really an argument.
I've never seen anything wrong with more communication between stakeholders and adapting a solution to meet their ever-changing needs.
There is an effect where people who are invited to second-guess themselves become less happy with their initial decisions. There is another effect where cost or price or effort or social-standing is associated to quality.
If you give the impression of falling over yourself to serve the whims of your stakeholders, you're doomed. If you set reasonable limits... well that requires experience to do properly, and that same experience could be used to twist a more traditional methodology into something useful.
Perhaps agile has a stronger sink-or-swim learning curve? You either learn quickly and succeed very well, or you never figure out what went wrong.
Comments
So one could reasonably suspect that people who "get agile" are just talented and would be good developers anyway. Occam's razor invites us to assume that agile has no effect. Are there any scientific studies on the effectiveness of agile (or TDD), or is this just a homeopathy situation?
If you're going to ask that, you should tell us which studies you used to select the other techniques you use.
(It turns out that there are, tons actually, but software engineering a difficult topic to study and I wouldn't draw any conclusions from them. The vast majority of controlled software engineering studies I've seen are conducted on students using problems of trivial scope. The uncontrolled ones aren't much better. Basic questions like "what do you mean by productivity" have yet to be answered well.)
Are there any scientific studies on the effectiveness of agile (or TDD), or is this just a homeopathy situation?
Yes (and yes) on TDD. None of the ones discussed in Making Software: what really works and why we believe it were done particularly well, and the less bad ones tended to show no effect or contradictory mixed results (ie, disagreed on what went better vs what went worse).
"Agile" is far too ill-defined to actually study usefully. Specific variants or individual practices could be studied.
nonsense. I'm not an advocate of large process by any means, but a number of principles of the agile movement can benefit developers of any skill level or experience. and more importantly it can help a team collectively more than it can help the individual. the trick is imposing these principles carefully, which almost every agile leader I've met fails to do.
I've never seen anything wrong with more communication between stakeholders and adapting a solution to meet their ever-changing needs.
Surely there's a point where more communication starts being detrimental. Reducing it to the absurd: if you spend 100% of the time communicating then you have no time left to actually build the thing. So there's a trade-off, as usual.
It could also be argued that ease of communication to deal with "ever-changing needs" encourages more superficial requirements and less deep thinking about the actual problem, leading to wasted effort and lower quality results.
Maybe you are right, maybe the above paragraph is right. I don't know and neither do you. Replying "nonsense" is not really an argument.
I've never seen anything wrong with more communication between stakeholders and adapting a solution to meet their ever-changing needs.
There is an effect where people who are invited to second-guess themselves become less happy with their initial decisions. There is another effect where cost or price or effort or social-standing is associated to quality.
If you give the impression of falling over yourself to serve the whims of your stakeholders, you're doomed. If you set reasonable limits... well that requires experience to do properly, and that same experience could be used to twist a more traditional methodology into something useful.
Perhaps agile has a stronger sink-or-swim learning curve? You either learn quickly and succeed very well, or you never figure out what went wrong.