Martin's comment on an old post reminded me that I really ought to come clean. I said in that post that I was going to stick with TDD despite its unclear benefits. I didn't. Our Bejeweled Blitz: Live contract came along, and the other programers weren't into TDD - I put some tests on a few bits here and there but that was pretty much it.
So I was pretty much broken, and with sixty second shooter I didn't even bother. I just wanted to get that game done as fast as possible and was willing to do a half assed job. (BTW, I slaughtered a sacred cow there: it's generally true in our industry that polish is king and that a great, late game will do better than a game that's on time but not-fully-baked. But Farmville shows it's at least possible to ship a half-baked game and make it better afterwards.)
With both those games, by the way, I'm pretty pleased with the non-bugginess. It's hard to really tell with sixty second shooter since I didn't hire a QA team or anything, but one interesting way to tell your game doesn't have a lot of bugs is if everybody is reporting the same ones. It's a much smaller game than Schizoid or Bejeweled Blitz, but the bugs-per-capita seem great.
What I chalk that up to is not TDD but being a better programmer. Maybe not quite as sharp (Guys my age start losing their edge at chess, etc, and having kids and cats wake you up in the middle of the night almost every night doesn't help) but I'm almost religiously not cacheing state in my code these days and there's just a lot less room for bugs to creep in.
Recent Comments