One of my favorite ancedotists, (that’s a word, right?), Josh Heyer, tweeted this recently, about people:
If you want sourdough, you don’t need to create bread yeast. You just need to arrange for conditions where it will thrive.
Josh Heyer, aka Shog9, on cultivating culture
People are like this too. If you want collaboration, create an environment where it thrives. If you want violent anarchy, make it seem like a viable option.
Besides being right, it got me to thinking about more productive teams and how that relates to Test Driven Development.
TDD by itself is sort of like a Ferrari engine sitting on blocks. It looks pretty but it’s not going to do you much good sitting on those blocks.
Some of the things that make the conditions right for TDD are:
- Setting up Continuous Integration and Automated Builds
- Architecture that takes TDD into account
- Intra-team communication and pairing
- Small-ish features
If these conditions are present, teams end up embracing TDD more naturally, and the success they receive from TDD multiplies.
When learning Test Driven Development, I missed out on all of these factors and only came to realize them after much trial and error and after being part of different kinds of teams, some of which embraced some of these principles, some that embraced all, and some that eschewed these principles. This is why my course on TDD takes all of these factors into account, and isn’t strictly about TDD. It’s about how to learn TDD and apply it successfully with your .NET Software project team. If that sort of thing interests you, sign up to receive updates on the course. As a special thank you, you’ll receive a subscriber’s only discount only available to… well. subscribers.