That's true (Especially for contract workers), but I think that the advice is more general. It doesn't matter what specifically the costs of failure are. They may be lost sales to unhappy customers, they may be bad reviews/press, or even insurance or being sued.
What matters is that you sit down before trying to create a system, you do good old fashioned cost/benefit analysis. What techniques get your team from point A to point B, and leave you with the most resources at the end of the day? Maybe automated Test::* based design is the way to go. Or, maybe the benefits of that method outweigh the cost of both training your team to implement and actually implementing it. You know your people best, and therefore you are the only one equipped to make that choice.
I think that BrowserUK and I disagree on the usefulness of Test::*. Maybe it is because he's a more experienced programmer than I and it just represents overhead for him. I don't know. I think we do, however, agree on the fact that you need to think about what you are doing and whether or not it makes sense to you, rather than burning a pig in a hut/cargo culting/whatever you want to call "pick whatever is popular and just do it."
In reply to Re^2: "Practices and Principles" to death
by amarquis
in thread "Practices and Principles" to death
by ack
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |