I have been having issues of late with people interrupting my flow, in an effort to identify these distractions and reduce them I have instituted the Wall of Shame.


Each row is a day of the week with Monday at the bottom and each Post Itâ„¢ is an interruption, listing the person and the reason.

The first and most obvious pattern is that there are far more distractions at the start of the week.

Item Quantity
Sales Call 1
Chase 3rd party support 1
Password and Account issues 3
Email Issues 2
Tennant Issues 4
Personal 2
Equipment Loan 2
Advice on software 3
Edit and Image 2
Meeting Room Setup 4
Printers and Scanners 1
Software Purchasing 1
Restore from backup 1

This is a broad categorisation of the interruptions by task, we can further categorise them thusly

Fix Quantity
Training Issue 9
Remote support 11
Not fixable 9

So we can reduce the distractions significantly by giving users additional training and by encouraging them to raise their issues directly with the remote support team.

I will continue monitoring for a few weeks and see if any further patterns develop.


Yesterday I wrote six lines of code.  Seven if you count the connection string. These are them:

// Retrieve storage account from connection string.
CloudStorageAccount storageAccount = CloudStorageAccount.Parse(CloudConfigurationManager.GetSetting("StorageConnectionString"));

// Create the queue client.
CloudQueueClient queueClient = storageAccount.CreateCloudQueueClient();

// Retrieve a reference to a container.
CloudQueue queue = queueClient.GetQueueReference("formsservicequeue");

// Create the queue if it doesn't already exist

// Create a message and add it to the queue.
CloudQueueMessage message = new CloudQueueMessage(urlEncodedXmlFormData);


I say wrote, what I actually did was copy and paste from the MSDN documentation and make a small change.

The rest of the day was spent figuring out which particular combination of NuGet package and Azure Storage Emulator would work with the old code this was added to and how to add unit tests around it.

In the end I gave up on unit tests and just did some manual integration testing as the original code never had unit test written, is integrated with Dynamics CRM 4.0 Organisation, Discovery and Metadata services, is itself an old SOAP service and is scheduled for replacement in the next few months.

The amount of work required to separate the components, write fakes for all the services and add in dependency injection is just not worth the benefit in this particular case.