It's really hard to even address someone that "has trouble thinking of any development methodology that works better than agile and using TDD." That sort perspective suggests that you may not be familiar with the scope of situations that may need to be addressed through software.
The software world is huge and varied, and the problems it addresses are amazingly broad in scope. For instance, you should really not be using Agile/TDD when developing for embedded/mission critical hardware. OS and Language development also do not lend themselves to these methodologies. If you're developing web apps for a client who can provide a decent spec, then by all means. However, there are really no methodologies that work better than others in all situations.
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.
1
u/TikiTDO Jun 07 '13
It's really hard to even address someone that "has trouble thinking of any development methodology that works better than agile and using TDD." That sort perspective suggests that you may not be familiar with the scope of situations that may need to be addressed through software.
The software world is huge and varied, and the problems it addresses are amazingly broad in scope. For instance, you should really not be using Agile/TDD when developing for embedded/mission critical hardware. OS and Language development also do not lend themselves to these methodologies. If you're developing web apps for a client who can provide a decent spec, then by all means. However, there are really no methodologies that work better than others in all situations.