Context switching on multiple projects

Recently I had a discussion with a client about project estimation and late delivery on recent projects and I advised them that faults in both these areas could perhaps be attributed to context switching costs caused by working on multiple projects at any one time.

I had recently been studying Team System engineering processes and in the book Software Engineering with Microsoft Visual Studio Team System by Sam Guckenheimer and Juan J.Perez, there is a chapter about value-up processes.
In one section of chapter the book illustrates a famous proposal by Gerald Weinberg in his book Quality Software Management: Systems Thinking:

…he proposed a rule of thumb to compute the waste caused by project switching:

No. Simultaneous Projects	Percent of Time on Project	Loss to Context Switching
1	100%	0%
2	40%	20%
3	20%	40%
4	10%	60%
5	5%	75%

There is no doubt that as a developer working on multiple projects you tend to leak time resources – re-establishing the current state, where you were at, what needs doing.
But the statistics quoted show that this loss is more significant than you might initially think when you go past two projects; it becomes a very big drain indeed.

I believe that one of the integral parts of programming is the fact that you have a lot of information in your head at any one time while you shape your code – wiping this clean as if clearing a whiteboard and then having to effectively having to re-draw it all again at a later date is undoubtedly costly.
A good, well organised developer can minimise this risk so that “writing it up again” takes minimum time, but it cannot be entirely removed.

In The Multi-Tasking Myth blog post from last year by Jeff Atwood (Coding Horror) he goes further to illustrate other forms of “distraction” context switching such as emails and phone calls (there is even a lovely graph!) and he summarises with:

We typically overestimate how much we’ll actually get done, and multi-tasking exaggerates our own internal biases even more. Whenever possible, avoid interruptions and avoid working on more than one project at the same time.

The short of it is that if you are able, stick to one project at a time and spend as much continuous time as possible.
It keeps you far more productive.

Intellisense problem after ReSharper uninstall

After uninstalling JetBrains’ ReSharper tool I discovered that Intellisense wasn’t working and after a little digging around found that it was turned off in the Visual Studio options.
The ReSharper tool does not reinstate those options when it uninstalls (I am assuming it turns those options off when installed to disable native VS Intellisense and provide its own).

I activated it again very simply with
Tools -> Options -> TextEditor -> C#
Under the “Statement Completion” option I ticked the two boxes: “Auto list members” and “Parameter Information”.

Back in business!
I’m about to install DevExpress’ CodeRush and I’m told it is very light and a single install supports all VS versions, including 2008.
It will be intersting to compare this to what I thought was quite a clunky and performance draining add on (ReSharper) that was sometimes very intrusive with auto-completion. I can see it was a very good product, it just wasn’t for me and didn’t suit my style, hence the uninstall.

How to schedule a Team Build

Team builds in TFS2005 do not have a built in automated scheduler available.
Yes, that’s right you read correctly – the tool billed as a continuous integration platform does not provide an easy way to schedule the build types out of the VS environment – that’s crazy!

However, there is a command line tool “TFSBuild.exe” that you can use to start a build.
Therefore you can manually create a windows schedule to kick the build off at set times and here is a quick step guide if you are having problems with this:

1. In the source control folder for the team build type, create a .bat file (e.g. My
2. insert the following in the bat file and check it in:
   TFSBuild start http://192.168.1.x:8080 ProjectName “Build Type Name”
3. Log onto the TFS box and get latest from source control on the team build type
4. Go to Start -> Programs -> Accessories ->System Tools ->Schedule Tasks
5. Set up a new schedule task to run the bat file
6. Ensure that the “Start in” path is set to “C:\Program Files\Microsoft Visual Studio 8\Common7\IDE”

In TFS 2008 this has been addressed and options are available on the right click of the build type in the Builds menu to facilitate this.