The joy of a little pair programming

We have been working with Agile methodology for a year and a half, we do scrums, two-week sprint, some TDD, but until two weeks back we started trying pair programming.

I did not like the idea at the beginning since I got used to the fast movement I usually make at work. But I was willing to share with others in the team, so I did not deny it as well. Two weeks passed, it turned out to be quite positive:

• We have a lot of discussions when we pair program.  The result is very obvious. Everybody on the team gets to the same page. Even if I do not read detail implementations, I have all the changes in my picture. Same to others. We did not have much design sessions before and there were no code reviews, now pair programming addresses those issues.
• We learned more on TDD. When working solo, it is easy to bypass writing unit tests. We are working on UI framework, a lot of tests are hard to write. When working in group, we find it is a fun to share thoughts not just on design, but also on how to create tests. 
• We learn "tricks" from each other. I use shortcuts a lot and this time I share many of them with other two developers. Same time I learned several from them.

Since each developer in the team has his own special responsibilities, we divide work into prototyping and implementation. Everyone is involved in the prototyping, but implementation may go to one single developer when others are busy with other tasks.

I think one reason it works well in our team is because each developer in the team is really good. Everybody is very close, either in programming skill or in analytical skill. When you have multiple bright brains think hard on the same issue, you can only increase the quality of the software!

Reflection on our MVVM implementation

We are refactoring existing framework to use MVVM these days. Everything worked out greatly and so far we have not found the need to check what third-party MVVM libraries would provide.

There were several things that I feel it's worth to write down for this work:

• Who's creating the objects. ViewModel was supposed to do that. We use XML to define dataset definitions like where to get data and how to save data. We create ViewModel inside the View (XAML), and it's a different stage where the data would be created. So I created a service controller class which is dedicated for creating the data. We later injected the data into the ViewModel.
• One or more data models. We have a lot of grids in the view (that's very common in business apps). It's very natural to model grid row data into a data model (i.e., an object class). However, there might be other models you want to model in the view... . Originally I created a model list to hold all possible data models for the view, I mean the data models on view level (not the row level). It looked good to me, but not to others when I explained to them. So I decided to make things simple -- all other properties that I want the View to bind to would be defined in the ViewModel, without introducing view level data models.
• Issue on child collection. We all know that we use ObservableCollection for list of child objects, e.g. if our data model is class A, it contains ObservableCollection<T> ChildB. The question is do I need to fire property changed for ChildB itself (not the items inside ChildB)? That's still not clear and it seems to be working without doing that.