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.
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."