Slight silence due to React and new Visual Studio

A very quick update – not that anyone reads this – but I’ve been up to the eyeballs in React for the last couple of weeks.

It’s very impressive and I’m definitely planning on writing a blog post or two on it, but not in the short term.

I’ve also been more that a little distracted with the new .NET and Visual Studio – http://blogs.msdn.com/b/dotnet/archive/2015/07/20/announcing-net-framework-4-6.aspx.

Await in catch and finally blocks in C# 6

This is the fifth part of a series of posts I’m making into Upcoming Language Feature Changes in C# 6.

This is definitely not syntactic sugar and if you’re doing any asynchronous programming you’ll be very pleased with this new feature.

    public async Task<int> CharacterCountAsync(string file)
    {
        int count = 0;

        try
        {
            using (var reader = new StringReader(file))
            {
                var contents = await reader.ReadToEndAsync();
                count = contents.Length;
            }
        }
        catch (Exception exc)
        {
            // C# 6 allows this
            await Logger.LogAsync(exc);
            throw;
        }
        finally
        {
            // C# 6 allows this
            await Logger.LogAsync("CharacterCountAsync Finished");
        }

        return count;
    }

I was toying with not posting about it as the name is very descriptive and the code is pretty self explanatory, so hopefully I haven’t missed anything!

Exception filters in C# 6

This is the fourth part of a series of posts I’m making into Upcoming Language Feature Changes in C# 6.

I must admit, I didn’t initially understand the fuss with exception filters. I saw a few tweets from along the lines of “finally, C# gets exception filters like VB.NET and F#” but didn’t understand the excitement. I saw code examples like the following and dismissed it.

    public void Demo1(int randomNumber)
    {
        try
        {
            if (randomNumber % 2 == 0)
            {
                throw new Exception("Even");
            }
            else
            {
                throw new Exception("Odd");
            }
        }
        catch (Exception e) when (e.Message == "Even")
        {
            // Extra logging because something evil happens when Even
            Console.WriteLine("Extra Logging");
        }
        catch (Exception e) when (e.Message == "Odd")
        {
            throw;
        }
    }

The change looks to be quite simple and pretty much syntactic sugar to save us putting “if/else” or “switch” statements inside a catch block, but it’s actually much more useful and subtle.

Important yet subtle improvements

First, you can put anything inside the “when” statement as long as it returns a bool. True means the exception is caught inside the corresponding catch block, false means the exception is passed to the next catch block.

Second, and more importantly, exception filters are checking the exception before it’s caught. This means the stack trace is not unwound, preserving the line number the actual exception occurred, rather than reporting the line of the subsequent “throw” statement.

Let’s look at some code to explain that in more detail.

As usual, it’s difficult to come up with something meaningful yet simple enough to fit on one screen, so please go with it and hopefully your imagination will stretch to see how this could happen in a real code base!

Demo – Extra Logs – without exception filters

Sticking with the above example, let’s imagine something strange happens when the method receives an even number, so you decide to add some extra logging inside the catch block and re-throw:

public void WithoutFilters(int randomNumber)
{
    try
    {
        if (randomNumber % 2 == 0)
        {
            throw new Exception("Even");
        }
        else
        {
            throw new Exception("Odd");
        }
    }
    catch (Exception e)
    {
        if (e.Message == "Even")
        {
            Console.WriteLine("Extra Logging");
        }

        throw;
    }
}

You get the desired result, but the stack trace reports the exception coming from the final “throw” statement which isn’t exactly helpful.

Demo – Extra logs – With Exception Filters

Let’s update the code to use exception filters, taking advantage of the fact we can put a method in the “when”:

public void WithFilters(int randomNumber)
{
    try
    {
        if (randomNumber % 2 == 0)
        {
            throw new Exception("Even");
        }
        else
        {
            throw new Exception("Odd");
        }
    }
    catch (Exception e) when (Log(e))
    {
        // as log returns false, this never gets run
    }
}

public bool Log(Exception e)
{
    // Log something
    if (e.Message == "Even")
    {
        Console.WriteLine("Extra Logging");
    }

    return false;
}

Here, the Log method is called for every exception but as it returns false, the corresponding catch block is never entered. This means we get the logging required but the exception isn’t re-thrown, so the stack trace contains the correct line number.

I also think this is easier to read and should hopefully lead to less cut-and-paste code inside catch blocks.

Summary

Although not obvious benefit of exception filters, if used wisely, this new language feature should lead to better exception handling, a better debugging experience and more maintainable code.

I suspect I’ve missed other uses for this change, so let me know in the comments below if I have!

Index Initializers in C# 6

This is the third part of a series of posts I’m making into Upcoming Language Feature Changes in C# 6.

This is another syntactic sugar feature, this time making initializing objects with indexers more elegant. Most of the examples I’ve seen are using it on Dictionary<Tkey, Tvalue>, for example:

    // prior to C# 6
    var previously = new Dictionary<string, string>
    {
        { "FirstName", "Fred" },
        { "SurName", "Blogs" },
        { "Age", "12" },
        { "Data", "Some other text here" },
    };

    // New C# 6 syntax
    var newExample = new Dictionary<string, string>
    {
        ["FirstName"] = "Fred",
        ["SurName"] = "Blogs",
        ["Age"] = "12",
        ["Data"] = "Some other text here",
    };

Not a massive change and I imagine some people like it and some don’t.

I think a better use of this is initializing JSON data as it really aids readability:

    // prior to C# 6
    var json1 = new JObject();
    json1["FirstName"] = "Bob";
    json1["SurName"] = "Geoffs";
    json1["Age"] = 12;

    // New C# 6 syntax
    var json2 = new JObject() {
        ["FirstName"] = "Bob",
        ["SurName"] = "Geoffs",
        ["Age"] = 12
    };

Again, it’s not a big change, but imho makes json2 much more readable.

Limitations?

I’m not sure if this is really a limitation, but it should be noted that you can’t use this new syntax when initializing a list, unless passing another list to the constructor.

Confused? Hopefully the following code clears that up

    // this is fine, obviously
    var currentList = new List<int> { 5, 6 };

    // can't do this 
    // var notAllowedList  = new List<int> {[0] = 5,[1] = 6 };

    // but you can do this
    var allowedList = new List(currentList ){[0] = 15,[1] = 16 };

I don’t know for certain, but I’m guessing the old syntax created the object – List, Dictionary etc – then called .Add() for each of the initializers. The new syntax appears to do something during object creation as the debugger states “notAllowedList” is null.

Either way, I don’t see why you would try something like the above so it’s not a big deal.

Static Members in C# 6

This is the second part of a series of posts I’m making into Upcoming Language Feature Changes in C# 6.

This feature definitely fits in the syntactic sugar category and will should result in less typing as it allows you to drop the class prefix from any static members. For example, by changing “using System.Math” to “using static System.Math” at the top of your classes, you can call the “Sqrt” method without prefixing it with “Math.”

Let’s take a simple static class called “StaticClass” that defines an enumeration and a static method.


using System;

namespace CSharp6Features
{
    public class StaticClass
    {
        public enum DaysOfTheWeek {
            Monday,
            Tuesday,
            Wednesday,
            Thursday,
            Friday,
            Saturday,
            Sunday
        }

        public static void ShoutIfMonday(DaysOfTheWeek today)
        {
            if (today == DaysOfTheWeek.Monday)
            {
                Console.WriteLine("IT'S MONDAY");
            }
        }
    }
}

Normally if you want to use either of these two, you would need to prefix the call to “ShoutIfMonday” with “StaticClass.” and “Monday” with “StaticClass.DaysOfTheWeek.”, but with the new feature, the code becomes:

using static CSharp6Features.StaticClass;
using static CSharp6Features.StaticClass.DaysOfTheWeek;

namespace CSharp6Features
{
    public class UsingStatics
    {
        public void UsingStaticsExample()
        {
            // Before C# 6
            StaticClass.ShoutIfMonday(StaticClass.DaysOfTheWeek.Monday);

            // Using C# 6 "using static" language feature
            ShoutIfMonday(Monday);
        }
    }
}

As you can in the code above, just because you’ve added “using static” doesn’t prevent you from using the old syntax.

Warning: Do not over user

This is obviously great if you’re working with a lot of the Math methods, or want to drop “Console.” from all your code, but I think there’s a danger this can be used too much.

Having an enumeration for the days of the week and using “Monday” is just as readable, if not more so, than “DaysOfWeek.Monday”. But for obscure things, say in state machines, “MoveToConfirm” is a lot less readable than “AcceptingInput.MoveToConfirm”. To find out what the current state is, you’d have to move to the top of the class and inspect the using statement or hover over it.

Not the end of the world, but I suggest some caution.

Auto-Property Changes in C# 6

This is the first part of a series of posts I’m making into Upcoming Language Feature Changes in C# 6.

In this post, I’m looking at the Auto-Property changes in C# 6. It’s probably going to be one of the larger posts as it covers 3 new language features:

  1. Auto-property Initializers
  2. Getter-only Auto-Properties
  3. Constructor assignment to getter-only auto-properties

The first can be classified as syntactic sugar, but the other 2 are really nice for immutable types. I may be wrong, but I think I’ll probably use these the most of all the new features. I’ve been playing with React a little bit recently, so I’m using immutable types more and more and I can see me using them in C# more often too.

Auto-Property Initializers

C# 3.0 added “auto-implemented properties” which made declaring properties easier. Instead of us adding the backing field, the compiler creates a private, anonymous backing field automatically.

Auto-Property Initializers takes this one step further, by initializing this backing field directly during declaration. This means we don’t have to initialize the properties inside the constructor.

public class AutoProperty
{
    // Before C# 6
    public int AutoPropOld { get; set; }

    public AutoProperty()
    {
        AutoPropOld = 5;
    }

    // C# 6
    public int AutoProp { get; set; } = 6;
}

Less typing and more readable, especially if you have a lot of other code between the property declaration and the constructor.

Getter-only Auto-Properties

Prior to C# 6, if you declared an auto-property it had to include both a getter and setter. This often isn’t what you want the public API of your types to be, so you could declare the setter to private. Unfortunately that doesn’t stop you writing to the property elsewhere in the same class. That isn’t necessarily a big problem, but in a shared codebase, someone might change the value of a property intended to be read-only causing weird bugs.

This “Getter-only Auto-Properties” feature closes that loop-hole. The following code shows just that and if you comment out the “NotPossible” method, you get a compilation warning – “Property or indexer ‘AutoProperty.GetterOnlyProp’ cannot be assigned to — it is read only”.

public class AutoProperty
{
    # Before C# 6
    public int GetterOnlyPropOld { get; private set; }

    # C# 6
    public int GetterOnlyProp { get; }

    // Compilation Error
    //public void NotPossible()
    //{
    //    GetterOnlyProp = 5;
    //}
}

Constructor assignment to getter-only auto-properties

I don’t know, but I imagine this final feature is there so you can write to Getter-Only properties without using “Auto-Property Initializers”. The name is very self explanatory, so I’ll just include some code.

public class AutoProperty
{
    public int CtorAssignment{ get; }

    public AutoProperty()
    {
        CtorAssignment = 6;
    }
}

Immutable Objects

Combining these changes together now lets you create immutable types much easier. You don’t need to manually declare a readonly backing field, use it in the Property getter and write directly to it in the constructor. It can now be achieved in much less code.

Instead of all this:

public class ImmutableExampleOld
{
    private readonly int _immutableBackingField;
    public int Immutable
    {
        get { return _immutableBackingField; }
    }

    public ImmutableExample()
    {
        _immutableField = 5;
    }
}

You can now write just:

public class ImmutableExampleCSharp6_Option1
{
    public int Immutable { get; } = 6;
}

Or if you want to initialize in the constructor:

public class ImmutableExampleCSharp6_Option2
{
    public int Immutable2 { get; }

    public ImmutableExampleCSharp6()
    {
        Immutable2 = 6;
    }
}

Summary

These three changes are small, but I imagine once you’ve used them for a while, you’ll be using them all the time. If you’re working with immutable types, you’ll be especially pleased.

Let me know if I’ve missed the point or got anything plain wrong.

Upcoming Language Feature Changes in C# 6

If you’re a C# programmer and haven’t been living in a cave, you’ll know big changes are coming. Now the Visual Studio 2015 Release Candidate is available to download, I figured it was a good time to jump on board and see what all the fuss is about.

Visual Studio 2015 isn’t just an IDE update. It seems almost everything is being updated, changed or replaced for vNext! One of the bigger updates is the new Rosyln compiler, which among a host of news tricks, are the new language features in C#. It’s here that I decided to start my playing.

I’m not going to write anything earth shattering, and there are lots of (better) blog posts on these changes, but I find the things I’ve written about not only stay in my head longer, but it helps me dig deeper that if I just played with it. I haven’t tried all of the features yet, and I may well miss the point of a few of them, but we’re all learning right?

This post will act as an index to the other posts, but for the moment I’m planning posts on the following features and their uses:

  1. Auto-Property Changes
  2. Static Members
  3. Index Initializer
  4. Exception filters
  5. Await in catch/finally
  6. Expression Body members
  7. Null-conditional operators
  8. String interpolation
  9. nameof operator

Please note, these changes aren’t being forced on you when you upgrade to VS2015. But playing with “new and shiny” is high up on every ones priorities so give them a try.

Cumulative Flow Diagram from TFS Data

One of the teams I’ve worked with frequently ended a sprint with 2 or more user stories “almost” ready. To them “almost” meant less than 2 hours, but in reality, due to sprint planning, task breakdowns etc, we more often than not finished those user stories on day 2 of the next sprint.

There were a number of reasons for this, but to aid in our investigation into why, I used a Cumulative Flow Diagram (CFD) each sprint.

There are any number of ways of creating CFDs and some people are lucky enough to be using a tool that does it for you. Unfortunately TFS, the tool I was using, wasn’t one of them. After some searching I eventually found a great post called Cumulative Flow Diagram – How to create one in Excel 2010

It was almost exactly what I wanted, but because it needed manual data entry, I was manually digging through TFS searching for the right info. That’s not too bad if you remember to do it every day, but I’d often not be able to due to meetings or some other commitment, let alone illness or annual leave.

What I wanted, was a way to extract the information on a daily basis without me having to open a web browser.

Less Manual Approach

Part 1 – What data do I need

This was fairly simple as I realised I need to know:

  • The User Story ID
  • Who the User Story is assigned to? That way I know if it’s in “Development” (not the testers or product owner), “Testing” (one of the testers) or “Ready” (the product owner)
  • The State, which is one of “Committed”, “In Progress”, “Done”

That way, I can calculate the current status of a User Story by the logic in the following table:

State Assigned To Status
Committed Empty To Do
Committed A Tester Testing
Committed Product Owner Ready
Committed Anyone Else In Progress
Done n/a Done

Part 2 – Write TFS Query

Getting the data out of TFS is relative simple. In the web interface, go to Work->Queries, create a new “My Queries” called CFD and fill it out as below, where “Iteration Path” is your current iteration:

CFD TFS Query Configuration

CFD TFS Query Configuration

It doesn’t matter how you configure the column options for this query as we’ll be extracting things via C# next.

Part 2 – Command Line Tool

Running the above query from C# is also simple. The below code clearly has a lot to be desired, but it was a quick 5 second proof of concept and as it’s been “good enough” I’ve never tweaked it.

using Microsoft.TeamFoundation.Client;
using Microsoft.TeamFoundation.WorkItemTracking.Client;

using System;
using System.Configuration;

namespace CFDConsoleApp
{
    class Program
    {
        static void Main(string[] args)
        {
	    var tfsServer = ConfigurationManager.AppSettings["TFS_SERVER"];
            var projectName = ConfigurationManager.AppSettings["PROJECT_NAME"];
            var queryFolder = ConfigurationManager.AppSettings["QUERY_FOLDER"];
            var queryName = ConfigurationManager.AppSettings["QUERY_NAME"];

            // Connect to the work item store
            var tpc = new TfsTeamProjectCollection(new Uri(tfsServer));
            var workItemStore = (WorkItemStore)tpc.GetService(typeof(WorkItemStore));

            // Run a saved query.
            var queryRoot = workItemStore.Projects[projectName].QueryHierarchy;
            var folder = (QueryFolder)queryRoot[queryFolder];
            var query = (QueryDefinition)folder[queryName];

            var queryResults = workItemStore.Query(query.QueryText);

            for (int i = 0; i < queryResults.Count; i++)
            {
                Console.WriteLine(
                    "{0},{1},{2}",
                    queryResults[i].Id, 
                    queryResults[i].Fields["Assigned To"].Value,
                    queryResults[i].State);
            }

            Console.ReadLine();
        }
    }
}

As you can see, I’ve placed some stuff in the App.config under App.Settings, but otherwise it’s very simple.

Part 3 – Scheduled Tasks

So I don’t have to remember to run this every day, I set up a scheduled tasks to run every morning at 8am, running the following command to output to a file called the current days date and time.

cfd_console.exe > %date:~10,4%_%date:~4,2%_%date:~7,2%__%time:~0,2%_%time:~3,2%_%time:~6,2%.txt

This way, for whatever time period you want, you just have to use those files. No outlook reminders or alarms!

Part 4 – Cumulative Flow Diagram from TFS Data

When you have a period of time you want to produce a CFD chart for, simply take the relevant .txt files and import the data into the excel template from the above post.

I’m sure this could be automated also, but as it only takes a few minutes every iteration I haven’t bothered.

Summary

The above way is still fairly manual, but it’s quicker than looking at PBIs and Tasks in TFS regularly. There’s also a lot to be desired with the coding, but it serves its purpose!

I could of course make this into an Excel app and possibly automate the whole thing, but for now, it’s more than good enough for my needs. One day maybe that will change, but in the meantime, feel free to take the above and adapt it to your needs.

Finally, if you’re not already creating a CFD for each sprint, I highly recommend you do. It’s a great easy way to explain to both the team and any stakeholders the work in progress and how it affects throughput.

Retrospective Idea – Question All Meetings

A colleague of mine has been commenting on the “cost” of some of the meetings we have each sprint. To be fair, a whole team sat in a room for an hour is expensive so it got me thinking. Lean, highly influential on Agile, has the concept of cutting away everything that isn’t need, so I wondered if our meetings were value for money and if not, what could be cut away.

I obviously didn’t want to dictate my thoughts to the team, so I tried to come to up with a retrospective technique to get the teams thoughts. As usual, it followed the 5 steps:

Question All Meetings Retrospective

Set the Stage

I set the stage as the team investigating “do we get value for money from our regular events”? I introduced the GIFTS acronym with respect to the daily stand-up. If you’re not familiar with this, I first read about it from Martin Fowler in his post It’s Not Just Standing Up. In short, it stands for:

  • Good start – to the day
  • Improvement – chance for the team to highlight possible improvements
  • Focus – for the team for the day ahead
  • Team – as in building
  • Status – so everyone knows what everyone else is doing

Before getting into it, to warm us up, I asked everyone to predict which meeting was going to be the worst and made a note of the results. This was mainly to get everyone to speak at least once.

Gather Data

As I’m in a big team, I split them into 3s and asked them to pick two of our regular meetings and come up with a similar acronym of what we should be getting from them and an opinion of whether we are.

Generate Insights

Each team presented their acronym and opinion of whether we get them. The whole team were then encouraged to discuss whether that was accurate.

Decide What To Do

If there are any perceived problems with the meetings, i.e. we’re not getting the values identified in the previous stages, talk about them and decide what we can do to change it.

Close the retrospective

I closed the retrospective by thanking everyone for their time and asking them all to provide me with some feedback on how they would rate the retrospective.

Result

The retrospective went “Okay” as it didn’t flow particularly well or feel like there was enough material for a whole retrospective. Saying that, we did get some useful ideas and have drastically changed some meetings, so it couldn’t have been totally bad.

To be honest though, that was probably due to my team being very good and effectively rescuing me from a bad retrospective, rather than my skills, but I’m happy!

Overall, I wouldn’t recommend this technique as is to a new Scrum Master or a new team, but I think there’s a good retrospective technique in here somewhere waiting to come out.

Warning

I don’t think you should consider drastically changing or completely dropping one of the regular scrum events. Also, please be very careful to monitor the reaction and changes in the team if you make any.

Basically, not all ideas are good ones, but have the courage to try something “out there” if the team reach a consensus on trying it.

Personal Retrospective

What went well

  • We got some good ideas on how to tweak a couple of the regular events and these changes have improved the teams opinion of them.

What could I have done better?

  • Asking people to make up acronyms in a short space of time didn’t work out particularly well. Maybe just the core values would be better.
  • Asking the teams to pick two meetings was a chance for them to all pick the same things. Assigning them felt wrong, so I need to think of a better way.

What should I not do again?

  • Expect all of my ideas to be amazing first time.
  • Asking the team to warm up with a prediction for the worst meeting was a bit naff

The importance of backlog refinement

Backlog refinement isn’t a prescribed meeting, instead the Scrum Guide states:

The Scrum Team decides how and when refinement is done.

Perhaps that’s why it’s not taken as seriously as the other scrum events, or worse, forgotten or ignored. I’ve lost count of the number of project managers (or “non-agile” people) ask “why are you spending time talking about the PBIs again?”. Maybe it’s external pressure making teams drop refinement, but either way, it’s a big mistake.

The team I’m currently working with have seen some real benefits from backlog refinement, so I thought I’d get my thoughts down for the next time someone asks “what are you doing?”.

What is Backlog Refinement?

I won’t go into depth as to what backlog grooming is as there are numerous guides out there. Instead I’ll use the classic iceberg metaphor, i.e. the backlog has epics and the bottom, almost ready Product Backlog Items (PBIs or user stories) in the middle and some ready PBIs at the top:

Product Backlog Iceberg Metaphor

Product Backlog Iceberg Metaphor

Basically, the meeting is for the team to help the product owner move user stories up the Product Backlog. This raises awareness of the upcoming story and helps the Product Owner break the larger items down into user stories that the team feel could pull them into the next sprint.

As a rule (which isn’t always possible for whatever reason), I like my teams to have a “buffer” of at least 2 sprints worth of Ready PBIs. Any less makes the next sprint planning problematic and any more I find priorities change and/or the team forget the details.

How long is Backlog Refinement?

Again, there isn’t a hard and fast rule for how long this event should be. The Scrum Guide says (emphasis mine):

Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.

As with everything scrum, it’s about finding a number that is just enough for your team to get the most amount of benefit and no more.

When should we do Backlog Refinement?

The current team I’m working with have tried lots of things. We’re currently have 2 regular events:

  1. An hour every week where the whole team sits down together and the Product Owner guides us through the backlog.
  2. Each team member is encouraged to spend at least 30 minutes each week going through the backlog on their own. (This started off as a meeting set in their calendars but we couldn’t find a time that suited everyone, so the team are trusted to do this whenever it’s convenient).

As long as it gets done, and the team are seeing the benefits, I prefer to let the team decide.

The importance of backlog refinement

There are many more reasons to perform backlog refinement than I’m going to list, but for me, the main benefits are:

  • Increased awareness of upcoming work. This leads to greater team buy-in and morale benefits
  • Smoother planning meetings (important if you have stakeholders attending)
  • Better understanding. The team can plan better, leading to less conflicts and an increased velocity
  • Fewer mid-sprint surprises like “we didn’t realise it was this complicated”.

I’ve read recently how Developers shouldn’t measure twice, cut once and I think for the really excellent teams who know their code base inside out this may hold true. But for the rest of us, a little preparation can go a long long way.