For a huge company, I'd say TDD/pair programming etc is also to ensure some productivity from bad programmers.
If one bad programmer writes the unit tests, and another bad programmer writes the code, then you might end up with a mediocre outcome, instead of a bad outcome. Same with pair programming.
Likewise, if you get a good programmer to write the unit tests, then give the programming work to a terrible programmer, given enough time, he'll write a working solution.
Re:Unit testing is not (generally) useful
by biohacker42 on Thursday February 05, 2009 @04:20PM
(#468759)
I'd have to say that two bad programmers are not any better then one bad programmer even with TDD.
But TDD benefits even the best programmers when they are dealing with a huge, ugly, old code base.
When on the other hand you're user testing every day or multiple times a day, like you might with a web startup, then TDD may only slow you down.
Re:Unit testing is not (generally) useful
by abstractbill on Thursday February 05, 2009 @04:49PM
(#468796)
When on the other hand you're user testing every day or multiple times a day, like you might with a web startup, then TDD may only slow you down.
These days I'm at a point where I can usually push 4 or 5 new releases into production every day. It's pretty awesome :-)
I did some testing, but not much when I worked for a startup.