Mark Needham

My former colleague Greg Gigon has written an interesting blog post where he talks about the pain that we cause ourselves by multi-tasking, a point which Kevin Fox also makes on the Theory of Constraints blog.

I think the overall point that he makes is very true:

We can switch our attention quickly from one task to another. But … is it good for our brain? Is it good for the work we are doing? Are we really more productive?

I’ve often found that when I try and switch between multiple different tasks I end up finishing none of them and it’s certainly true that twitter, facebook and emails can be amazingly distracting.

Hopefully those types of distractions are less of an issue when working on a software development team, particularly if the team are pair programming.

Project influenced context switching

While I agree with Greg that it’s good to try and make sure that we’re only working on one task at a time, I think that to an extent there is always going to be some context switching involved if we have a group of people working together.

Greg touches on this briefly in his post:

When we are in a despair and need answers we are not worrying about anyone else. The goal is to ask or tell to achieve whatever we are after. We are not taking into consideration that we might be disturbing someone else Flow.

To me it seems that focusing on the flow of an individual individual/pair is a bit of a local optimisation when we’re talking about software teams.

For example if a pair are working on a piece of functionality orthogonal to what another pair are working on then should they interrupt that pair if they need to talk about something?

Interrupting them possible would break their ‘flow’ but it might give one or both pairs an insight into the problem which they wouldn’t have otherwise had.

From my experience pairs interrupting each other often helps reduce the amount of time that we spend building the wrong thing.

An alternative way to still gain this knowledge without interrupting people straight away would be to delay the conversation until a later time but perhaps the best moment for gaining that knowledge has now gone?

Counter productive context switching

The only time when interrupting a pair does seem counter productive is if you’re doing so to ask a question whose answer could easily be found out with a quick bit of Googling.

In that case I completely agree with Greg that we should first think about the impact our interruption will have on our colleagues.

Overall

The topic of flow/context switching is an interesting one but I think we need to be careful about having it as our main goal on software delivery teams.

I wrote about pair flow a while ago where I described some ways to achieve more ‘flow’ within a pair but my current line of thinking is that we’ll still have some interruption between pairs and that’s not necessarily a bad thing.

An approach to ponder…

Mike Wagg once suggested that pairs should work in 25 minute pomodoros and only be interruptible when they’re on a break from one.

This seems like an interesting idea but communication would end up being much more structured/time boxed/weird?!

One of the most common discussions that I have with my colleagues is around designing bits of code in the simplest way possible.

I’ve never quite been able to put my finger on exactly what makes a design simple and there is frequently disagreement about what is even considered simple.

On the last project I worked on we had an interesting problem where we wanted to partially update different parts of an object from different pages of the application.

We had access to the id of the object from the URL so my initial thought was that when we submitted each page we could load the full object from the database and update it with the values that had just been submitted from that page.

The problem with that solution was that it meant we needed to make another database call without any real benefit from doing so.

We had already created objects representing the data submitted from these pages so Christian suggested that an alternative approach would be to create NHibernate mappings for those objects instead so that we could just map the updated values straight to the database.

We had bit of duplication in our objects as we had one object representing every bit of data the user had provided so far and then two smaller objects just representing the data provided for each of the pages.

public class TheObject
{
	public string Page1Property { get; set; }
	public string Page2Property { get; set; }
}

public class PartialObject1
{
	public string Page1Property { get; set; }
}

public class PartialObject2
{
	public string Page2Property { get; set; }
}

We then created NHibernate mappings for each of those objects:

public class TheObjectMapping : ClassMap<TheObject>
{
	Map(x => x.Page1Property);
	Map(x => x.Page2Property);
}

public class PartialObject1Mapping : ClassMap<PartialObject1>
{
	Map(x => x.Page1Property);

public class PartialObject2Mapping : ClassMap<PartialObject2>
{
	Map(x => x.Page2Property);

When loading the object from the database onto the page we used ‘TheObject’ and its associated mappings and when updating the object from the individual pages we could use the partial object mappings.

I think this was quite a neat approach as it allowed us to reduce the complexity of our controller code when updating an object as well as removing the need for one trip to the database.

The trade off was that we ended up writing more mapping code but that seemed to be a reasonable trade off to make.