[joeblau]

I thought the exact same thing, until I was working on a project where we implemented separation of duties (Everyone works in a random pair team for 2 weeks on a few tickets) and rotation of duties (No one on the project owns any piece of code). I was handed another developers code and it was a scary experience. My paired team mate and I were so scared to modify anything because the developer made arbitrary design decisions and never refactored them out of the code. There were tons of unused lines for things that "used to be" there. No one knew what was doing what so, it slowed our velocity, and everyone always asked the original dev what was going on. Eventually, except that dev, everyone quit the company so I'm curious what code quality looks like over there now.

The unit level testing in our other projects helped me figure out very quickly what was going on. I could read the method names and it was the the cliff notes to a book. And then based on those test passing, I would assume the notes were correct. I'm sure the experience isn't the same for everyone and I'm still very new to TDD, but after having one really good experience, I'm all for it. My tests have tests.