Microsoft patterns & practices Mobile Client Software Factory

I just spent the last 7 months working as a contractor at Microsoft, in their patterns & practices group. They hired me to help create their Moblile Client Software Factory; this project was very rewarding and a lot of fun. They needed an expert on mobile development, which is where I came into the picture. I always wanted to see what it was like to work at Microsoft, and the fact that I live about 1-1/2 miles (as the crow flies) from Microsoft made the transition easy.

This group uses a number of practices that were new to me. All their projects are developed using Agile practices, which includes some of the following areas that were new to me:

• Test-Driven Development
• Pair Programming
• The entire team is in a team room
• Rapid iterations

There are more points, but that should give you a starting point. As a programmer, I've always worked in a private office so I could focus and not be distracted. The idea of working in a team environment, without a quiet place to work, was different than what I was used to, but hey, it was a contract. If I'd come into a full-time job where I wouldn't have my own office, I think I would have been very reluctant to accept the offer. After all, I really need my quiet to focus and get my job done. Or so I thought...

Fast forward 7 months. I proposed a new project in the patterns & practices group and got it funded, so I'm now working on a new project under contract. I was offered the use of someone else's office, but I chose instead to find space in another team room. What's that you're saying? Why would I chose a noisy team room over a quiet office?

The answer is a little complicated, but it's also something everyone else here has discovered. None of the people here wanted to give up private offices. However, now that they've experienced the agile environment, they don't want to go back to private offices. There are several reasons for this.

First, the dynamic of a team environment really does provide better shared knoweledge of the project. You feal more involved because you are more involved. And you have a better sense of how all the pieces fit together and what other people are working on.

However, more importantly is the dynamic of pair programming. Here you have two people on one computer. We've done it where we have two keyboards and mice on a single computer. One person writes a unit test describing what the code should do, and then the other person writes the minimal amount of code to make that unit test pass. Next you switch roles. This process produces simpler, more reliable code than you get from a single programmer, and it also makes keeping your energy level high during the project easier.