When was the last time you sat down and talked to your team about problems?  What was the last task or procedure you changed because it was a bad fit for the project?  The longer you wait, the worse it gets because the longer a team works together, the less likely someone is going to mention a difficulty or a frustration.  Once people get used a routine that is bearable, they will learn to live with it even though it’s uncomfortable, and it’s this situation which leads to frustration, turnover and burnout.

I am fortunate to have a team who is vocal and willing to discuss issues.  The team is relatively good working through development scenarios where issues might arise.  Code deployments are automated, database updates are tested multiple times in varying scenarios, and every time an issue occurs that a change in process could help, we look at implementing it.  For a long time, we were diligent at applying this test and fix approach to everything except ourselves, and that is when the unexpected happened.  My team member completely shocked me and let me know that our communication with him was poor and he didn’t feel included.  He works remotely most of the time, and for the most part he was the only one.  The rest of the team would have conversations in hallways, etc., and to us this was the course of a normal day.  His knowledge and insights were being excluded, simply because we were making decisions about things we didn’t feel warranted an official meeting.

This left us in an awkward position.  We either needed to end the possibility of working remotely, or we needed to rethink how we communicated on a daily basis.  Our problem was that most of us didn’t even know we had a problem, and that certainly meant we didn’t know how to fix it.  Most organizations handle problems like this by minimizing scenarios where they have issues.  We took the opposite approach and forced ourselves to confront it, understand it, and from this we created a new policy; all people must now work remote at least one day a week.  Why did we take this approach?  We understood that remote work is too important to give up. We also understood that unless we analyzed what was wrong it would never improve.  In the end, we would rather take time to fix a problem than keep suffering through it.  This approach to helped not only communication with but showed us other areas for improvement as well.


For us to solve the problem, we must first all understand what it is.  With all people working away from the office, we can all see what problems there are with communication.  Each person can now look at how the team functions and provide a unique perspective on how to make it better.   We found that not only our communication with people off site improved, but with people on site as well.  We are now much more diligent about communicating ideas and decisions with everyone and we are much more cognizant about recording information where it can be accessed anywhere at any time.


Despite any attempt at quiet working conditions, most offices are a chaotic place.  Programming requires concentration and several tasks are only easy to accomplish when someone can have several hours of uninterrupted work.  Common pieces of advice include, “put on headphones” or “book a meeting room and close the door.”  These are fine, but there is always the possibility people will cause interruption.  While at home, coworkers cannot do this allowing greater relaxation which leads to an easier ability to focus.  Now that each team member has at least one day where work can be uninterrupted, they commonly save long tasks for when not at the office.

Disaster Recovery

Being able to access key internal systems from home is not just for people who live too far away to be on location.  We depend on it in cases when people can’t drive to the office, or when emergencies arise when we don’t have time to make the commute.  During a crisis is not the time to find out your equipment doesn’t function.  With each member testing remote access on a weekly basis, we have a relativity high certainty that it will work when we need it to.   This is a tool used in emergencies just like redundant servers, or a secondary site.  You can always hope it works when necessary, but you won’t know until you try.


Trust is something which everyone wants to believe exists but is often in short supply.  Most places have the capability to allow people to work remotely, but leaders often joke about their employees watching television instead. (I actually interviewed at a company where the hiring manager threateningly said that he’ll know if people aren’t doing work while they are remote.)  Allowing employees to work at home when necessary shows a level of implicit trust.  It tells employees management has enough faith in their work ethic that if its only once in a while the project won’t suffer too much.  Forcing someone to work remotely changes the narrative.  It becomes a common occurrence, and shows everyone they are trusted enough to do what they need to do.  Trust among a team is key.  It allows people to be open about issues and ideas for improvement, and without it teams will fail to improve.


I have been fortunate enough to be allowed to speak at Indy.Code() which really means I’m grateful to get the chance to listen to all the other speakers. If you live anywhere around the Midwest, or can travel to Indianapolis, I highly recommend you come and watch the talks. It’s going to be an amazing event with some unbelievably great speakers. A fun time will be had by all. (Unless you hate fun, then you probably won’t like it so much. For everyone else, it’ll be pretty great!)

C# 7 Additions – Tuples

In C# 7 Microsoft has introduced an updated Tuple type. It has a streamlined syntax compared to it’s predecessor making it fall it look more like F#. Instead of declaring it like previous versions, the new Tuple type looks like:

Likewise to declare it as a return type, the syntax is similar to declaring it:

The first thing to note about the new type is that it is not included automatically in a new project. If you immediately use it, you’ll see the following error.

As of VS 15 preview 4 (not to be confused with VS 2015), you must include the System.ValueTuple Nuget package to take advantage of it.

This raises the question about how the new Tuple type and the previous one included since .NET 4 are related? They’re not. They are treated as two different types and are not compatible with each other.  System.Tuple is a reference type and System. ValueTuple is a value type.

So what are advantages over the previous version? The syntax simpler, and there are several other advantages.

Named Properties

In the System.Tuple version, properties of the return object were referenced as Item1, Item2 etc. This gets confusing when there are multiples of the same type in the Tuple as you have to know what position had which value type.

Now it’s possible to explicitly name the item types to reduce confusion.

The Item properties (Item1, Item2, etc.) have also been included allowing methods to be updated to the new type without breaking code based on it’s predecessor.

It’s also possible to explicitly name the values when creating the object:


It is now possible to name and assign variable values upon creating (or returning) a tuple. Although not necessary, it reduces the amount of code necessary to pull values out of the type.

It’s not certain if C# will get wildcards like F# to automatically discard values which aren’t needed. If they are allowed then it’s possible to only create a variable for the name like so:

Updating Values

System.Tuple is immutable.  Once created it’s not possible to update any of the values.  This restriction has been removed in the new version.  From a purely functional perspective this could be considered a step backwards, but in C# many people find this approach more forgiving and beneficial.

Like all value types, when it is passed into a method, a copy of the tuple is created, so modifying it in the in the method does not affect the original.

However if you compare two different tuples and they have the same values, the Equals method compares the values in each and if they are all equal, it considers them equal.

Integrations with Other Languages

Unfortunately, C#’s new tuple type doesn’t automatically allow it to translate tuples from F#.

F# can’t desconstruct the values like it can with it’s native tuples, and to return it, you have to explicitly instantiate the object type and add the values.

Either way, the translation to F# isn’t horrible as it acts like any other object passed to it by C#.

Adding New Web Applications

Using PowerShell to create new web applications with the IIS PowerShell Snap-In is incredibly easy. Just use New-WebApplication and specify

  • Site : Site to put it under
  • Physical Path : The directory path to the folder where the application will reside
  • Application Pool : The application pool running the web application
  • Name : The name of the application (what appears in the URL)

The physical path, application pool and site must be in place before running the cmdlet. It won’t create them automatically and will fail the install if they aren’t present. Conveniently, there are cmdlets to handle creating these as well:

Creating a new directory:

Creating an application pool:

Ne App Pool PowerShell

App Pool IIS

Creating a new site:

powershell created site

IIS Site

PowerShell doesn’t let you customize much during the default install (Restart schedules, application pool user, etc.), but it is easy to modify them after creation. Use the Set-ItemProperty (Alternatively, you can use Get-ItemProperty to look at the configuration values in IIS).

Unless you specify the Force parameter, old web applications won’t be overwritten by new ones. In order to test them before making the update specify the conditional using Test-Path:

Removing a web application is just as easy as creating one too. Just provide the name of the web application and the site it runs under: