Improving estimates with Planning Poker

I once overheard a comment regarding a last minute request to estimate a piece of work in an area of the code base the developer knew nothing about.  "Whatever you estimate, you'll be held to it.".  It's no wonder developers are often reluctant to provide estimates when there is an unrealistic expectation that estimates are always spot on.  An estimate by its own definition is an approximation and we should therefore anticipate and plan for the possibility that it is going to be incorrect.  What we can do however is employ techniques that help improve the quality and accuracy of estimates so that we can have a higher level of confidence in them.  One such technique is "Planning Poker".

Let's say we've been asked to estimate a particular user story in a large area of the system.  Different developers have had different experiences within this area and so their opinion of the complexity of implementing this user story differs.  Planning poker allows us to identify this and provide a forum for further short discussion; by the end of which we should achieve a more accurate estimate that everybody buys into.  Let's play a short hand to see this by example.

We have five stakeholders playing which consist of a two DBA's and three developers.  They all hold the following standard hand which contain numbers from the Fibonacci sequence.

Image courtesy of Mountain Goat Software

We have been asked to estimate two user stories and we'll play a hand to estimate user story 1 first.  Each stakeholder selects a card that represents their estimate of that story.  What we see after the first round are the following cards selected.  Two 1's, two 2's and a 3.  As the estimates from all were relatively close with no wildly differing opinions, the group decide to take the average(ish) estimate of 2 and move on.

Next we look at the second user story and get the following hand.  One 3, three 8's and a 13.  This time we have quite a split opinion so it is now up to the low and high scoring stakeholders to justify their estimates.  Once each stakeholder has presented, we go through the process of playing another hand, this time considering what we have just heard.  We repeat this cycle until we eventually reach a hand similar to the first where we had similar enough estimates that the group felt comfortable taking the average, if not the same estimate across the board.

As you can see, planning poker has the potential to be an effective tool in collaborative estimation.  It won't guarantee that every estimate will be perfect but it will improve the accuracy and reliability of them and certainly give you every possible chance of avoiding those unfortunate occasions where we get them wildly wrong.

The var keyword in C#. What's in your coding standards?

So this was a subject that led to much debate in the office this week.  When is it acceptable to use the var keyword in C#?  Well, lets start with the obvious situation where everybody will agree it is necessary and we have no choice otherwise.  Anonymous types.  

Take the following example where we have a Linq projection to an anonymous type...

var employeeDetails = from employee in employees

                where employee.County == "Kent" 

                select new { employee.ForeName, employee.Surname };

foreach (var item in employeeDetails)
{
    Console.WriteLine("Name={0} {1}", item.ForeName, item.Surname);
}

var is used twice here.  Once to hold a sequence of anonymous types, then again to iterate through the sequence of anonymous types; but where else is it appropriate for use?  Well actually, most people agreed that it shouldn't be used anywhere else.  It certainly shouldn't be used where it would cause ambiguity, like in the following example... 

var products = _repository.GetProductsByCategory(ProductCategory.Bike);

What is the type of the variable products in the example above?  It's not immediately obvious and requires you to drill down into the method GetProductsByCategory to determine the return type.  Instead, the use of an explicitly typed variable is preferred.  Here is the same example typed correctly. 

IList <IProduct> products = _repository.GetProductsByCategory(ProductCategory .Bike);

Much better.  Also, I don't think var should be used where the type is inferred from the right side of an assigmnet.  i.e...

var age = 31;

Sure, we know the implicit type of the variable age through our own experience, but what about junior members of your team?  Will they know?  Perhaps this was written by a junior.  Did they know the implicit type they would receive when they wrote this?  Were they expecting something else?  Its use here raises too many questions and is best avoided.

I think the biggest split in opinion was around using var when instantiating an object.  To be honest, I've always found C# rather verbose when it comes to this.  For example...

List<Bike> bikes = new List<Bike>();

Isn't there quite a bit of redundancy there?  We explicitly type the variable bikes, then we immediately instantiate that variable, specifying the type a second time.  Personally, I fall into the camp where if the type is specified on the right side of the assignment, use the more concise syntax of...

var bikes = new List<BikeDTO >();

To me, that reads much better.  It's concise and there isn't any ambiguity over the type.  This point however seems to split the room and there seems no way to convince either side otherwise.  I guess this one comes down to what you are used to and what other languages you have had exposure to.  The same verbose declaration in VB for example would look something like...

Dim bikes as List<BikeDTO> = new List<BikeDTO>()

However, nobody would ever use that syntax.  Instead, the norm would be to use the conciser form of...

Dim bikes = new List<BikeDTO>()

...and move on.

Ultimately, the standard you choose should be consistent and not cause the developer to think too much about it, either at the point of variable declaration or variable discovery.  It's important to settle on something that everybody will buy into and adhere to.  I think it's impossible to please everybody on this one so if permitting its usage for the sake of reducing redundancy is going to cause debate and inconsistency within your code base, perhaps go with the safest option and don't permit it.

What do your coding standards say about the use of var?