Human Task Switching is Horrible for ROI

Some people get it, some companies do, some other don’t, and it really goes to show on the company’s bottom line.  One can literally make major decisions about a company based upon what they expect from their employees in the way of task switching.  There are of course levels, but I’ll lay some descriptions out real quick for more context on what exactly I’m talking about.

Task-switching is when an employee literally stops one task to begin working on another task.  Rule out multi-tasking, that is a myth to begin with.  Task-switching is a part of everyone’s daily work.  The impact of task switching is directly related to the number of tasks.  I’ve created a quick little spreadsheet based on some of my research to show how exponential multiple tasks decrease worker productivity.  It is truly scary how fast someone can start producing nothing by trying to or being forced to attempt to produce too much!

So here is a quick “spreadsheet” run down of how quickly tasks will fall apart with the addition of more tasks.  With 7 tasks equating to the loss of diminishing returns and the fall into negative productivity.  Some of this loss, albeit not much, can be stemmed with effective and proactive management.  Basically take a percentage, of the percentage of time task switching, and effective management can remove that workload to decrease the task switching impact.

Other References for this Topic

http://weblogs.asp.net/erobillard/archive/2005/07/20/420022.aspx

http://www.joelonsoftware.com/articles/fog0000000022.html

Heavy Duty Scientific References

http://citeseer.ist.psu.edu/654767.html

http://www.apa.org/releases/multitasking.html

http://www.psychologymatters.org/multitask0306.html

http://www.ncbi.nlm.nih.gov/sites/entrez?cmd=Retrieve&db=pubmed&list_uids=11976394

A No-no of Task Switching Items

  1. More than one “status report” a week.  Each additional status report added is a large % increase to the task switching effort.  Often times a written status report done a daily basis will have the reverse effect if done in a SCRUM type fashion.  But if the status report is too excessively detailed, even a weekly written status report, it often leads to de-motivation and a significant decrease in productivity.
  2. More than 15 minutes in a meeting.  As minutes are added, the return to work is exponentially more time consuming.
  3. No more than 2-3 meetings in a day.  Each one will increase the task switching time for returning to task efforts.
  4. Don’t make administrative staff do things they aren’t trained to and don’t turn developers and highly paid professionals into administrative staff.  Admin staff are for paperwork, developers are for developing, DBAs are for database administration, don’t get the titles into a spaghetti mess or the chart above becomes an extremely optimistic estimate in productivity loss.
  5. Management should also work diligently to keep the aforementioned “creative professional” interested in what they’re doing.  Work with them in this factor.  If you don’t, forget the 7 task maximum, think more around the 2 task is a red line limit.  They will get bored, they will lose productivity, and they’ll eventually leave or get fired.

For more elaboration on this topic definitely check out the two first blog entries I mentioned above from Joel on Software and Ero Billard.

SharePoint?

Over the last several years I’ve noticed SharePoint actually getting its act together.  The URIs have gotten a little better and the interface has changed ever so slightly for the better.  There are however still gaping issues with certain parts of it.  This however is expected, being the flexibility of the application.

At work I’ve become glued to SharePoint a large part of the day for document management and versioning, forms that can easily be created in SharePoint also are easy to make and somewhat easy to maintain.  Even the reporting on those things is pretty good.  As I notice I’m more engulfed in the whole SharePoint world I’ve come up with some questions, mostly related to resources.

  • Where is a good real development resource online?  One that provides insight on how to actually add packages or modules to the site when needed.  How to really dig in and setup solutions that are highly customized.- What is a good source for end users of the SharePoint system.  Who out there has good how to docs and other such things, and I’m not talking about those pay me a zillion bucks.  Reasonable prices or free are what I’m looking for.- What are the ideal patterns and practices for SharePoint?  What are the ideal or suggested reporting types or uses for SharePoint?

So with those questions in mind I set out on a search for some solid resources.  The following is what I’ve found so far, if anyone else has any suggestions or addition please comment!

Anyway, that is currently it for my construction of a SharePoint list.  As I mentioned, if anybody else has any good links, please leave comments and I’ll collate an even bigger list at some point.

Technorati Tags: SharePoint,Administration

del.icio.us Tags: SharePoint,Administration

Unit Tests Don't Work on Cubes

I’ve been building web sites for a while now.  I’ve been writing code, object oriented style for the better part of a decade.  Unit testing I’ve been doing for all of about 1-2 years to various degrees.  Nothing super advanced yet, and slowly I’m getting some of the more advanced unit testing methods figured out.  Not so much advanced, but just newer methods for testing in different situations.

So now I’ve figured out web service unit tests, database unit tests, and all sorts of other ways to unit test things.  So my question is, how does one unit test a cube?

An SSAS (SQL Server Analysis Services) Cube can be built and then exported out into XMLA for running against another server to create the cube.  Also it is good for a kind of backup mechanism.  Cubes also can have MDX segments, which might be easier to test.  But amid all of these pieces, and all of the “code” written for cubes, what is a good way to test a cube?  How does one break the parts of a cube into units to be able to test in the first place?

Off hand I’m just going to trace over some ideas I stumbled into while riding the bus out to Scott Hanselman’s talk on ASP.NET MVC.

The First Unit Testing Idea for Cubes

I could develop a custom framework using ADOMD.NET that would literally test points of the cubes, dimensions, and such things like that.  Adding the ability to just insert attributes onto classes that are utilizing the cube or some other such association.  Building something like that would work well if one was writing code directly to the cube.  However…

The Second Idea is an MDX Test Framework

This idea sounds much better, but I actually don’t have the first idea on how I would prospectively implement it.  Anyone out there ever try to implement such a thing with MDX?

So that is my first two ideas…  and I’ve arrived at my destination, thus am done thinking of idea for this entry.

Does anyone else have any ideas or thoughts?

kick it on DotNetKicks.com

Technorati Tags: unit test,business intelligence,MDX,MDX Unit Tests

del.icio.us Tags: unit test,business intelligence,MDX,MDX Unit Tests

Tech Second

If you read my transit blog you probably know, if not, here goes.  A break in frequency is to be had for me over the next few weeks.  I’ve got so much to do and some upgrading to do on the site that I’m taking a slight break from the daily regular that I had been posting.

So stay tuned for a return of more regular entries, for now you’ll just have to read the infrequency.

Just an FYI.