Sunday, August 21, 2011

ASP.NET MVC 3 Dependency Injection

ASP.NET MVC 3 added some much needed improvements for dependency injection. With MVC 2, they wanted you to implement the IControllerFactory interface which provided some context and the name of the controller. Redirecting these method calls to a dependency injection framework wasn't hard, but support for DI in MVC 2 could have been better.

MVC 3 introduces the IControllerActivator and IDependencyResolver interfaces. An example implementation can be found here which uses Unity. I've shown you the relevant parts below:
internal class UnityDependencyResolver : IDependencyResolver
{
    private IUnityContainer _container = null;

    public UnityDependencyResolver(IUnityContainer container)
    {
        this._container = container;
    }

    public object GetService(Type serviceType)
    {
        try
        {
            return this._container.Resolve(serviceType);
        }
        catch
        {
            // Return null to indicate that we were unable to create an instance
            return null;
        }
    }

    public IEnumerable<object> GetServices(Type serviceType)
    {
        try
        {
            return this._container.ResolveAll(serviceType);
        }
        catch
        {
            // Return null to indicate that we were unable to create an instance
            return null;
        }
    }
}
Then you just have to register this custom dependency resolver when your application starts.
protected void Application_Start()
{
    AreaRegistration.RegisterAllAreas();

    RegisterGlobalFilters(GlobalFilters.Filters);
    RegisterRoutes(RouteTable.Routes);

    // Register DI container
    ConfigureContainer();
}

private void ConfigureContainer()
{
    IUnityContainer container = new UnityContainer();

    // Register other services here

    // Set the current resolver
    DependencyResolver.SetResolver(new UnityDependencyResolver(container));
}

Nothing ground breaking here. It's the simplicity of it that makes it nice. What I really like is that almost everything is loaded through the current dependency resolver. So what does the IControllerActivator have to do with it? Well, I'm not sure to be honest. If you put a break point in a custom resolver at line 14, you'll see the following things attempting to be loaded:
  • IControllerFactory
  • IControllerActivator
  • HomeController (which controller you have set as your starting point)
  • IFilterProvider 
  • IViewEngine 
  • IViewPageActivator 
  • ... 
When I saw that my controller was being loaded by the dependency resolver. I wondered why I need to have a custom implementation of the IControllerActivator above? I removed my custom controller activator from my DI container and sure enough, my controller was created with dependencies and all. I'm sure there are cases where you may want to do some custom prepping before the controller handles the request. Except for those, I don't see that you need it.

So in the end, if you're using a respectable DI framework, IDependencyResolver is all you need.

Wednesday, May 4, 2011

TFS Build Explorer

I came across a tool from Inmeta that allows you to organize build definitions into folders. This is one of those features that should have been there from day one. I'm glad to see someone stepped up and wrote one. It installs fast, is easy to setup, and works great! You can download it here.

Tuesday, April 5, 2011

How many hours are in a story point?

One of the questions people tend to have when thinking about story point estimation is how many hours are in a story point. With some people, they say they're trying to estimate the stories in hours, and then figure out how many story points they are from the hours estimate. I don't have a problem with that, as long as they really understand how story points relate to hours. When they don't understand the relation, they tend to think a simple conversion like 5 hours per story point is sufficient for estimating in points this way. I disagree.

I came across a Mike Cohn's blog entry titled How Do Story Points Relate to Hours? where he discusses the relationship between story points and hours. To summarize his thoughts, he states that the bucket for x-story-point estimates represents a distribution of hours. For example, the five-story-point stories estimated by a particular team would relate to a range between 15 and 30 hours. The hours distribution for one-story-point stories is going to be different than the distribution for the eight-story-point stories.

What this also means, is that the distribution in the smaller story point estimates should be much tighter than the distribution in the larger story point estimates. Estimating the size of a story that asks for a new label and a new entry box on a web page should be much easier to estimate than a story that asks for adding single-sign-on support across multiple web applications. To illustrate this concept to my team, I decided to collect data from our last 6 iterations and graph the different story point estimates against both the estimated hours, and the actual hours.



If you were to take a collection of estimated stories from a team and come up with a number like 5 hours per story point, then you would be assuming that all stories are estimated with the same level of accuracy. In practice, the larger stories contain more unknowns and therefore suffer from less accurate estimations than the smaller stories. The graphs above demonstrate this and tell me that each story point level (1,2,3,5, etc) has it's own level of accuracy and using a single conversion for estimation is not a good idea. Other than helping me illustrate the hours relation to my team, how else can this information be used? It can be used to show product owners how important it is for us to break stories down into smaller (hopefully easier estimated) stories.

You can download my spreadsheet here. I've provided a legacy xls format here. Just plug in your team's numbers and see how it looks.

Friday, March 25, 2011

Ramblings on Story Point Estimation

One of my favorite agile planning techniques is to use story points for story estimation. In a nutshell, story point estimation means the team decides on the size of the story, rather than how long it will take to get the story done. The size of the story is represented by a unit of measure that is decided upon by the team. You could use units like [tiny, extra small, small, medium, large, extra large]. I personally prefer numerical sizes like [1, 2, 3, 5, 8, 13, 20, 40] that spread as the number gets higher. The idea is it should be a unit is not described by time (i.e. hours or days) but is defined by its relation to itself (I'll explain what I mean by that a little later).

Whenever I've introduced this concept to developers, it usually goes something like this:

Tom: "So if you're saying we should estimate in story points, how long is a story point?"
Me: "How long is a mile?"
Tom: [Blank stare]
Me: "A story point isn't something based on time, but rather on size. You wouldn't tell me that a mile is about 1 minute would you?"
Tom: "No."
Me: "Why not?"
Tom: "Because how long a mile is in terms of time depends on your velocity."
Me: "So based on what you just said, how much time it takes to complete a story point depends on the team's velocity?"
Tom: [Pause] "Yeah, I suppose so. But when you ask me how many story points I think a story is, how am I supposed to know the answer if I don't know what a story point is."
Me: "We all find a story that we choose to be 5 story points, and estimate the other stories relative to that one. If the next story seems like less effort, then give it a number less than 5; if it's more effort then give it a number more than 5. A story point is defined by it's relation to other story points."

Even after this discussion and during planning poker I hear people saying things like, "That one isn't a 5, there's no way you can get that done in 5 days!". I have to constantly remind people to stop thinking about the stories in terms of time. What's interesting, is that the people that have this problem are those that have been working with the code longer and have been doing estimates in hours for a long time. The new guys don't have any idea how long it's going to take to write code within a system that they've had very little exposure to and therefore are left with only estimating effort relative to other efforts.

I had a developer whose first day on the job happen to be our planning day. His manager was telling me that he should just observe because he doesn't have any basis for estimating the work yet because he's new. I disagreed and said if he's part of the team, he's part of the team and he estimates with us. We do planning poker so there's no way his estimates were being influenced by others. When it came time to show cards, his first few estimates were not inline with the team. However, after a few stories he was able to pick numbers that were in line with the team; you never would have been able to tell that it was his first day.

I've seen the above incident happen on more than one occasion and believe it's a good indication that story point estimation is a fast and reliable way to estimate stories. But how is this used outside of iteration planning and into release planning? The product owner should be looking at how many story points were burned during an iteration to get an idea what the teams current story point velocity is. They can then use this velocity to figure out how many iterations it's going to take to complete a given set of stories. For example, if my team burns 100 story points an iteration on average, and I have 550 story points worth of stories in my backlog, I can reasonably say that it'll take 6 iterations to complete all of those stories. If the iterations are 2 weeks each, then I can tell upper management that the next release is 14 weeks out (6 iterations * 2 weeks each = 12 weeks + 2 "just in case" weeks).

From my experience, the concept of story points, velocity, and release planning are something that untrained product owners know little about. They keep trying to do funny math with story points to come up with hours per story point then use those hours to plan longer term goals; not once looking at the team's actual velocity. I'm not a product owner and will admit that I don't understand the level of pressure that comes from the business, but I do know from experience that using story points without understanding how to plan releases with them, has caused frustration and tension between the development team and the business.