I think TDD is most effective in "state machines" like cook([ingredients]) => dish, witch should be avoided if possible as they are very bug prone.
An External Replication on the Effects of Test-driven Development [pdf]
201–210 of 332 posts
Re: An External Replication on the Effects of Test-driven Development [pdf]
#202The title of this post is very misleading. TDD in opposition to ITL has little to no impact, the title suggests that the testing itself does not have any impact.
This is just click baiting...
Re: An External Replication on the Effects of Test-driven Development [pdf]
#203Earlier quoted context omitted.
If studies don't need to be rigorous, what's the point of doing them? Why not just write a persuasive essay instead? Is the format of a "study" just a rhetorical device, a glammed-up appeal to authority? The whole point of careful statistics and well-designed experiments is so that we can learn whether a premise is true or not. Without rigor, we prove nothing; this study for example, neither proves NOR disproves anyt…
While I can see your point of view, perhaps that is an ideal and not a realistic view of how science actually works. Similarly, someone might have an ideal view of software development, but if they saw how it actually worked and read actual in-production code ... and I think that describes every profession. Science does work pretty well; it predicts things with accuracy and reliability otherwise unknown by humanity (…
You're conflating the "hard" sciences (which rely on reproducible experiments to explore natural laws) with the "soft" sciences (which rely on studies to explore human behavior). The track record of the latter is significantly worse than that of the former. Software engineering, and by extension this study, falls firmly into the soft sciences territory.
You should be a lot more sceptical of supposed facts in soft sciences than in hard sciences. Not because of prejudice or arrogance, but because it's much harder to be reasonably certain about anything in a soft science than in a hard science.
Re: An External Replication on the Effects of Test-driven Development [pdf]
#204This study, like most software development studies I've seen, is seriously flawed. It doesn't justify the sensational title here on HN. * The sample size was tiny. (20 students) * The participants were selected by convenience. (They were students in the researcher's class.) * The majority of participants had no professional experience. (Six students had prior professional experience. Only three had more than two year…
Promotion of schemes akin to TDD tend to build their foundations on even smaller sample sizes, usually of those close in some fashion to the new wheel's reinventor; the naïve solving text-book-example problems.
But maybe I missed something.
Re: An External Replication on the Effects of Test-driven Development [pdf]
#205Earlier quoted context omitted.
It's a total waste of scientific resources to insist every study requires an army of test subjects, and the top statisticians of the times to apply the latest modeling, to work blind and replicated independently before publication. There are limited resources to do research. You can get insights into how the world works much cheaper if you use critical thinking and facts outside the controls. Casually dismissing ever…
If studies don't need to be rigorous, what's the point of doing them? Why not just write a persuasive essay instead? Is the format of a "study" just a rhetorical device, a glammed-up appeal to authority? The whole point of careful statistics and well-designed experiments is so that we can learn whether a premise is true or not. Without rigor, we prove nothing; this study for example, neither proves NOR disproves anyt…
How short the internet's memory is.
Le mieux est l'ennemi du bien. It was right here not a couple of days ago.
Sheesh why do I bother?
Re: An External Replication on the Effects of Test-driven Development [pdf]
#206This study, like most software development studies I've seen, is seriously flawed. It doesn't justify the sensational title here on HN. * The sample size was tiny. (20 students) * The participants were selected by convenience. (They were students in the researcher's class.) * The majority of participants had no professional experience. (Six students had prior professional experience. Only three had more than two year…
Most importantly, their solutions didn't need to actually work in the real world. If that wasn't the case, one would find that there are often massive rewrites (not "refactors") when software is in embryonic form and/or users are giving it a try. A major advantage and disadvantage with TDD approach is that you pay the price upfront to avoid more charges letter. But if your features, business model and code is still haven't taken solid form then your upfront payment gets wasted.
Re: An External Replication on the Effects of Test-driven Development [pdf]
#207This study, like most software development studies I've seen, is seriously flawed. It doesn't justify the sensational title here on HN. * The sample size was tiny. (20 students) * The participants were selected by convenience. (They were students in the researcher's class.) * The majority of participants had no professional experience. (Six students had prior professional experience. Only three had more than two year…
But you have same variation in professional environment as well. It well could be that TDD is not that much of a gain if it gets lost in the noise of confounding factors that easily.
Re: An External Replication on the Effects of Test-driven Development [pdf]
#208No TDD discussion is complete without a reference to Sudoku debacle.
Re: An External Replication on the Effects of Test-driven Development [pdf]
#209Long story short: if you don't have coders who take their product as a matter of personal pride, or are inexperienced, or are mediocre, no methodology in the world will save you. None. I realize my statement is anecdotal, but I'm writing from decades of experience working with people who did not take any pride in their work, and still view programming as a trade rather than art, or view programming as an art where "spaghetti code is beautiful". No methodology, no technology, no management technique, and no programming language saved them or the company. The builds are still a mess. The code is still a mess. The bodies of code require endless babysitting and endless hacking.
Re: An External Replication on the Effects of Test-driven Development [pdf]
#210Earlier quoted context omitted.
The conversation around TDD is tired, and the conclusion is always the same: "it depends." It depends on the person writing the code, the type of problem they're tackling, the language they're using, the needs of the business, etc. This study doesn't bring anything new to the table except: "in this manufactured environment we found a single point of data that equates to noise." I'm guessing the only reason the story…
the conclusion is always the same: "it depends." Er, no. The studies I've read all end up showing that principled testing helps, but test-first and TDD (strict red/green cycle, code only enough to pass the new test, etc) provide no additional benefit over anything else that gets the tests written. The "it depends" always comes from the echo chamber trying to justify their desire to believe that TDD isn't completely u…
I really don't believe any study or meta-study could come close to being able to suss out the nuance of when TDD may provide an advantage and when it doesn't.
I'd rather just trust programmers to consider what approach works best for their problem and mindset and go from there.
I personally don't TDD most things, but it's a tool I have available and I bring it out when a situation arises.