Inertia

For the past year or so I have been suffering from the worst case of Inertia. I was generally dissatisfied with my job and wanted to do something more or something different, generally something that would challenge me. But, I was comfortable where I was. I was doing something I knew, drawing a paycheck & working with people I knew & liked. But, I was still dissatisfied.

That is at an end now. I have finally made the break. I have bid ThoughtWorks adieu. I'm leaving the comfort of the salaried class to the dark, scary, but definitely exciting world of the entrepreneur. I am forming, along with Niranjan, an offshore Rails services firm called C42 Engineering.

I will miss ThoughtWorks a great deal. I learnt a lot from there. I think I was incredibly lucky to be able to join it straight out of university.

Here's to breaking Inertia.

Introducing Azazel

Azazel is a new application launcher for windows. It started with me experimenting with WPF and then deciding to build an actual application. I had been using both Colibri & Launchy and loved the fact that I could use my computer using just my keyboard, and also wouldn't have to hunt for programs in my start menu. It fixes some things about those two other programs that annoyed me. Also, being in .Net it lets me plug in to it.

Give it a go and let me know what you think. I will be refining it and adding more features to it in time. Also, I will be posting instructions on adding your own plugins soon.

Technorati Tags: azazel,wpf,opensource

Daily Pair Switching Part 2

In a previous post I talked about the issues I faced in two separate projects where we had implemented daily pair switching. In this post I'll talk about an alternate strategy and how we would go about fixing the issues that prompted us to use daily pair switching in the first place.

On obvious thing that needs to be done (which in fact is something you need to have regardless of your strategy) is to have small cards. The ideal size would be day-long cards which is difficult in real life and so a realistic maximum size for a card would be around 4 days, 5 would be just about stretching it.

That being said the pair switching strategy that has most worked in projects I've been on are where a pair sticks together for a complete story at which point they switch. If another pair happens to finish at that some point or will relatively soon they can just swap. Of course, this doesn't happen all the time and the team needs to be able to break apart another pair even if they're story isn't completed.

One problem which creeps into a team when switching happens less frequently is you find favourite pairs, by which I mean two developers who are always pairing together (albeit with breaks of pairing with others). This happens because there are certain developers who are naturally more compatible with each other and enjoy working together. But, in the longer this adversely affects the team because of reduced distribution of knowledge. If this turns out to happen on your team you could introduce a pairing matrix. Essentially, a developer/developer chart to see if people have reasonably evenly been distributing their time.

The second most common problem is similar to the first one and the solution is also quite similar. What happens is get a lot of domain (or technology) experts. Although, people cite this as a reason to adopt daily switching, I find it happens just as often in daily switching teams. The solution is to again have developer/domain matrix to see who's worked on what. This is consulted when deciding which story to pick up from the card wall. I find this to be the perfect balance of spreading the knowledge and having developers learn quickly (by actually touching all the layers of the application while implementing one story fully).

I started off by saying that stories can't be longer than a week. But, invariably there are some (hopefully just some) stories that go on for longer than a week. At this point, a switch has to be forced, because if that does not happen the pair just stagnates.

Technorati Tags: xp,extreme programming,pair programming

Need help with WPF storyboards

I'm trying out an application using WPF forms and involves some amount of animation. I've been using Expression Blend to build the animations and it generates storyboards like below:

        <Storyboard x:Key="Parameter">
            <DoubleAnimationUsingKeyFrames BeginTime="00:00:00" Storyboard.TargetName="canvas" Storyboard.TargetProperty="(FrameworkElement.Height)">
                <SplineDoubleKeyFrame KeyTime="00:00:00.0000000" Value="36"/>
                <SplineDoubleKeyFrame KeyTime="00:00:00.5000000" Value="72"/>
            </DoubleAnimationUsingKeyFrames>
            <DoubleAnimationUsingKeyFrames BeginTime="00:00:00" Storyboard.TargetName="selectedCommand" Storyboard.TargetProperty="(FrameworkElement.Width)">
                <SplineDoubleKeyFrame KeyTime="00:00:00.0000000" Value="480"/>
                <SplineDoubleKeyFrame KeyTime="00:00:00.5000000" Value="240"/>
            </DoubleAnimationUsingKeyFrames>
        </Storyboard>

A storyboard contains a set of frames of various controls on your screen and the framework draws the intermediate frames. The actual version that I have has about ten different DoubleAnimationKeyFrames elements. The problem is I need a storyboard which will reverse the animation I did previously and I can't seem to get the internal members representing the DoubleAnimationKeyFrames from code on the Storyboard object. Consequently, every time I make some minor change to the original storyboard I have to make a similar change to the reverse storyboard.

It seems weird that this isn't possible, because surely you should be able to create storyboards from code. While Xaml is well and good, there are times you just want to dynamically build animations. I must be missing something. Please let me know if anyone has solved this problem.

Technorati Tags: wpf

Daily pair switching Part 1

One of the motives of pair programming is to promote knowledge sharing. To this end pairs need to switch out regularly so that they get to work with more and more people. The issue is about how often developers switch pairs.

Most developers I have spoken to about this seem to prefer switching pairs daily. The reasoning behind this is twofold. 1) You don't have as high a concentration of knowledge of domain & technologies in a few people who happened to have worked on a card in a particular area & 2) With more developers looking at the code you get the best solution and if a certain pair stagnates on a story it will be at most for a day. Both valid points. Unfortunately, I have never seen daily pair switching working out for the team and in fact I have seen it introduce problems.

The first problem I have seen it create a lot of bugs. The bugs I have noticed are story bugs (as against regression bugs). What seems to happen is that at the time of switching over all the knowledge isn't transferred. In a couple of extreme cases an entire task has been missed out. We had to bring in a practice of maintaining a list of tasks and dev's ticking them off as and when it was completed which helped somewhat but there were still more bugs than there should have been. Also, there wasn't ownership of a story so that pair would feel responsible to complete it with no bugs.

The second problem was that new people (especially junior people) on the team were taking longer to start contributing. The problem was, the newer developers were seeing bits and pieces of the application and never had the experience of following the code from GUI to database and hence couldn't put the technology stack together. This was having the opposite effect of what was intended with most of the knowledge being concentrated on the more senior developers or the ones that had been the longest.

The third problem isn't really related to velocity or team dynamics. This isn't the case with everyone but at least I never felt the satisfaction of starting a card and seeing it through to completion. The daily context switching wasn't really helping my efficiency.

In this post I have discussed what I consider the problems are with pair programming. In Part 2, I will talk about what can be done to mitigate the negative aspects of not switching pairs daily.

Technorati Tags: thoughtworks,xp,pair programming