Here's a thread about TDD. A lot of technical coaches want you to do things a certain way. Others focus strongly on delivering customer value. My goal as a tech coach is to help you reduce the stress of your job. If that's not interesting, skip the rest of this.
As a developer, I've found that TDD reduces the stress of the job. It has benefits for other audiences, too. Karl Scotland and I did a management-focused presentation in 2008 to demonstrate how TDD affects things like project budgets & timelines and total cost of ownership of SW.
I know developers are interested in delivering customer value and all that. But they're even more interested in minimizing their own work-related stress. Here's a screencast I made to call out some of the personal benefits of TDD for developers.
People often point out that TDD is OK for greenfield development, but in reality we work with existing code far more often. Dave Farley has a two-part series of videos demonstrating how to incorporate TDD with other techniques when refactoring legacy code.
Seems to me very few developers use TDD or even understand it. They reject it based on limited knowledge/experience. It's like the Monty Python "How to Do It" sketch. How to play the flute: Blow in one end and move your fingers up and down the outside.
At the risk of being blunt let me say that's not enough basis to make a professional judgment. As a coach I don't "want" you to use TDD. I want you to learn enough to make an informed professional judgment. I've worked with people who chose not to use TDD in their work...
...after they had learned enough to know how to make such a decision in an informed way. As a coach, that's a "win" for me. I want you to be able to make sound professional choices independently, rather than choosing or rejecting practices and tools based on too-little knowledge.
You can follow @davenicolette.
Tip: mention @twtextapp on a Twitter thread with the keyword “unroll” to get a link to it.

Latest Threads Unrolled: