Software by Rob : Using Technology to Fight Poverty
The Bowling Game Kata
Several years ago, I attended the SD West conference. One of the most memorable things I did there was a hands-on session with "Uncle Bob" Martin on TDD and pair programming. Everyone brought their laptops, and for 3 hours we learned how TDD works. The Bowling Game Kata was the example he used as the attendees 'paired' with Bob. He drove, we made comments.
After the Bowling Game example, he had us divide up into pairs and work on a few other sample problems. I ended up pairing with someone several years older than me, a very experienced developer who had never used Java - which is the language we were using for the exercise. I was skeptical at first, but by following the steps - write a test, see it fail, make it pass, repeat - we were able to get good solutions to 2 problems in a short period of time. And each time we were surprised at how simple and elegant the resulting code turned out to be.
I remember coming back from the conference all charged up about pair programming and TDD, and tried to spread that enthusiasm to my team. It didn't work. I kept saying to myself "I need to set up a meeting so we can all do this exercise together, then they'll get it." But everyday work always seemed to get in the way. We didn't have time to spend 3 hours learning something new. Kinda like that old story about the guy who doesn't have time to sharpen his saw, because he's too busy cutting down trees...
I'm glad I'm starting to actually do it now. It takes time to learn, and you have to keep doing it, but it pays off. You get better, things go faster. Keep at it.
You don't have time to NOT do TDD
I just read a short article on Bob Martin's blog that I think helps describe why TDD is so important for developing software. He relates how brain surgeons spend 99% of an operation setting up guides to make sure they are doing the operation in the right place. The actual 'operation' only takes a second, but setting it up takes a long time. You see this in other areas as well. Woodworking comes to mind, since that is something I have experience in. Many times, if you need to do something (drilling holes for shelf pins in a bookcase, for example), you have to first build yourself a jig. Something to guide your work. Making the jig might take more time than the operation itself, but if you don't make the jig you will either take a long time to do the job right, or you will do a very poor job. Same for unit tests, integration tests, acceptance tests, etc. You can skip that step and just start drilling, but you'll probably regret it later.