I worked on the roman numerals kata this week with danp, and learned some new things about TDD and approaching a problem. Where you start with TDD and what kind of insights you can draw from a domain before you start really effect your direction. As I'm typing this it seems incredibly obvious, but it was still a good lesson for me to learn.
We started the kata few times and scrapped our code each time as we started realizing our approach wasn't quite what we were looking for. Honestly if I hadn't had a pair, I probably wouldn't have started over so many times, or pushed quite so hard to find a better way to look at the problem.
What did we start with? We started with the tests. Each time we tried the problem, we picked what we thought was the simplest test and then picked what we thought was the next simplest test. What we found was that we were backing ourselves into corners in our implementation because our tests weren't actually very good starting points.
I'm thinking TDD is like a hill climber where you start really matters. In a way that is the challenge TDD presents you with: What is simplest thing to start with?
No comments:
Post a Comment