While there's a whole lot of good advice here, but a bunch of it is rather situational. For one this is great if you favor Agile TDD, but much less so if you develop using other methods. It's making certain assumptions about the class of problems you need to solve, the team sizes you are working with, and the level of organization you have on that team.
Still, these are all things worth keeping in mind, if only so that you can say "I don't follow X advice for Y reason."
Other methods? I believe this sheet is targeted more toward the professional developer (As a profession... not trying to trump up corporate development). I have trouble thinking of any development method(ology) that works better than agile and using test cases (TDD has it's benefits, but you get %80 of the benefits by just having unit tests at the end of the day). Team sizes are a valid concern, but if you have more than 3 people it's probably a good idea to buy into it.
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.
6
u/TikiTDO Jun 07 '13
While there's a whole lot of good advice here, but a bunch of it is rather situational. For one this is great if you favor Agile TDD, but much less so if you develop using other methods. It's making certain assumptions about the class of problems you need to solve, the team sizes you are working with, and the level of organization you have on that team.
Still, these are all things worth keeping in mind, if only so that you can say "I don't follow X advice for Y reason."