Extreme musings pt. 1

The main reason I started this blog was to chronicle my thoughts as I transitioned not only to a new job but to an entirely new development style. Since I'm approaching the 2 month mark, I figured now was a good time to check in.

To recap, I'm now doing fairly strict XP - pair programming full time, test driving everything, and an engaged customer whose job it is to manage our backlog. Previously I was doing some sort of half-assed scrum/agile where our biggest victories were having CI, sprint planning meetings, and short (2 week) releases.

Pairing

One of the biggest changes and something I've written about before is pair programming. I had done some pair programming before both in school and professionally, but only when tackling an especially hard problem. Doing it for a full 8 hours every single day is a different beast entirely.

It probably goes without saying that the most critical piece of the pair programming equation is who you are pairing with. I've had the opportunity to pair with 6 people in the past 2 months and each person has been radically different than the last. I could probably write an entire post about different pair personalities, but to keep this at a high level, I think there are 2 main points I've discovered: There are people I really enjoy pairing with and it's been equally helpful to pair with everyone on the team. (To be fair, I haven't paired with anyone I've disliked, but inevitably you'll work better with some than others.)

Obviously it sounds like it would be great to pair with the people you really click with, and it is. But I think that pairing with the other people is equally important. There are always things to learn from pairing with someone new, and I've found it's very important when working on a team to understand the position of all team members on the project. Most of the time when developing, you're spending your brain cycles figuring out how pieces of the application should go together, and the more people you've paired with, the better your understanding of the pieces will be.

Tests f-ing rock

Having a full test suite on your application is awesome. I really can't say that enough. Having a full test suite on your application is awesome. There, I said it again.

I've been writing unit tests for a few years and before doing full time BDD I always felt like I was missing an important piece of why tests are useful. I get it now. When you truly have complete test coverage of your application you are in a position of great power and flexibility. Refactoring, even scary refactoring, is suddenly conquerable. Bugs are more often "oops, we forgot about..." instead of "dude, did you even run this before you committed?!"

The thing about tests is that if you don't have full coverage, you're only getting a fraction of the benefit. It's not until you can reliably count on your tests catching any bugs that you can reach the full potential of a test suite. I do think that some tests are better than no tests, but once you hit the magical full coverage mark, it's an exponential growth in what you get out of them.

(By "full coverage" I don't necessarily mean every single line is directly tested, but that the intent of each method and class is covered. Think BDD instead of TDD, although I'm sure more "pure" TDD can have the same benefits as well.)

...

This post started to get a bit longer than I originally expected so I'm going to break it up into more parts... installment 2 coming soon :)