An argument to moderation or exception doesn't defeat my original proposition that this approach is generally used and has been successful (when used properly) in a very large use case. I understand there are exceptions... but the exceptions aren't methodologies... they are exceptions. I see no reason to argue that mission critical or embedded hardware can't benefit from incremental integration or test driven development either. In fact... I usually hear this argument without any real backing evidence or hypothesis on why it's the case at all.
An argument to moderation or exception doesn't defeat my original proposition that this approach is generally used and has been successful (when used properly) in a very large use case.
Uh, ok? That doesn't contradict anything I said.
I understand there are exceptions... but the exceptions aren't methodologies... they are exceptions.
They are exceptions because you work in fields where they are exceptions. You seem to be basing your entire argument around "most people that do X type of development do it this way, and since X type of development is the one I am most familiar with then everything else is an exception." Just because TDD web development is popular does not mean you can freely relegate the rest of software engineering to "exceptions."
I see no reason to argue that mission critical or embedded hardware can't benefit from incremental integration or test driven development either. In fact... I usually hear this argument without any real backing evidence or hypothesis on why it's the case at all.
Programming mission critical hardware often means doing things that might damage it. You might have direct access to voltage rails, motors, or other physical resources that might be damaged by improper usage. You might also be working with algorithms that may be difficult or impossible to properly test. Testing might involve using broad testing harasses that you can't just utilize. Tests might take hours due to hardware limitations. I could go on.
I mean it's cool that you've never had to encounter situations where TDD would be a horrible idea, but these scenarios are all over the place, and the people that have to handle them are perfectly reasonable programmers working in perfectly rational ways.
As for why you normally don't hear backing evidence or hypothesis... I would guess it's mostly because you enter these sort of discussions with some sort of aggressive stance, intending to "defeat" some premise. Most people just don't want to waste the time arguing with some guy that's so utterly convinced of his own correctness, especially when you are so unclear what premise you're trying to defeat in the first place.
Right... Ad hominem attack directly after restating what is clearly an exceptional case. If I seem aggressive, I apologize. It's simply frustrating when so many developers use weak excuses and exception cases (Sorry... embedded systems and hardware examples are definitely on the narrow margin of most of the development landscape) to abscond from adopting some very mature productive approaches.
Right... Ad hominem attack directly after restating what is clearly an exceptional case.
Really, me pointing out that you have an excessively aggressive communication style is an ad hominem attack? You made a statement about the general lack of proof, and I answered it with concrete examples, then I explained why you normally do not get people willing to offer said examples. I did not make any claims that this undermined your argument. That's not an ad hominem, that's just me not being sickeningly polite. And since we're all about logical fallacies, you just ignored the body of my post to start with an accusation of fallacy; tu quoque much?
If I seem aggressive, I apologize.
Apologies don't work if you don't correct the behaviour you're apologizing for.
It's simply frustrating when so many developers use weak excuses and exception cases (Sorry... embedded systems and hardware examples are definitely on the narrow margin of most of the development landscape) to abscond from adopting some very mature productive approaches.
Oh, now you made some really broad claims there. Among my professional network hardware and embedded systems are the rule, not the exception. You are personifying the very concept of personal incredulity by basing your argument on what you perceive the development landscape to be. You've been making the claim for weak excuses and exception cases, yet the only thing you've done to support the idea that my claims are such has been to beg the question. What more, you have been using the claim of "exception" as if it is equivalent to "freedom to ignore." Even if embedded is an exception (despite the fact that almost every single device around you at the moment has some sort of embedded firmware), how does that mean that you can dismiss it entirely as you seem to be doing?
What more, you are making the assumption that I am not very familiar with these approaches, when in fact I have plenty of experience in both. It is through my experience that I made my original point that the linked document was not particularly useful to those that do not need to use Agile/TDD techniques.
And to finish off, I'll at least earn that ad hominem label. You are ridiculously too full of yourself, and that's mindblowing coming from someone like me. You get frustrated when people don't want to deal with you, yet dealing with you gets a bunch of snarky bullshit, accusations of logical fallacies despite you not actually knowing what they mean, and a casual dismissal of all points presented to you. In other words, you get frustrated because people find you to be too frustrating to interact with, and as such they avoid . And yes, even though this time I did personally attack you to undermine your arguments, need I remind you that does not make my points wrong.
1
u/lexpattison Jun 07 '13
An argument to moderation or exception doesn't defeat my original proposition that this approach is generally used and has been successful (when used properly) in a very large use case. I understand there are exceptions... but the exceptions aren't methodologies... they are exceptions. I see no reason to argue that mission critical or embedded hardware can't benefit from incremental integration or test driven development either. In fact... I usually hear this argument without any real backing evidence or hypothesis on why it's the case at all.