Kanban Land is wonderful

Original: http://blog.crisp.se/2009/06/26/henrikkniberg/1246053060000

So, what's your team's bus factor?

5whys.com is a site I've been enjoying recently and anyone interested in team leadership should check it out. I've just been reading one of Roy's posts about something called 'Bus factor'.

Bus factor: An irreverent measurement of concentration of information in a single person, or very few people. The bus factor is the total number of key developers who would need to be incapacitated, as by getting hit by a bus, to send the project into such disarray that it would not be able to proceed.

My team's daily stand ups, pair programming and the willingness for team members to share their knowledge means we certainly have a bus factor > 1. So, what's your teams bus factor?

Continuous Integration and Jenkins

I found this old draft post hanging around on blogger and it reminded me to a time long ago before CI servers were a part of my dev life, so I decided to post it...

Jenkins (formerly Hudson) is an open source continuous integration server and assists the development team by allowing us to easily integrate changes into our software projects from our source control with confidence. Jenkins can be automated to build, test and deploy any type of software automagically. Jenkins doesn't require bucket loads of learning before you start using it and it's very easy to set up. It's also super extensible and caters for a wide variety of programming languages/testing frameworks etc and there are a lot of plugins available - and I mean a lot.

Feedback is key. If Jenkins has any problems building, testing or deploying any projects it can alert the development team in a number of ways (e.g. through a GUI, email, twitter and many more). So as soon as the build or any tests fail we get alerted and the team react to fix those changes - it's never broken for long.

As you can imagine, once we made the effort to set up our software projects in Jenkins, it has improved our 'quality of dev life' dramatically. Automating the building, unit testing, integration testing and deployment straight to our staging environment for every check-in means we are more confident, less stressed and a lot more productive. Once happy with our staging environment we can one click an application release to live. So our application users are getting newer features faster than ever. Ignoring IDEs and source control, I'd argue a CI server is probably the next most fundamental tool in a developers tool belt.

Jenkins! How did we ever live without you?!

XP2011 International Agile Conference (Madrid)

I'm lucky I work for an employer that recognises the value in sending the development team members to conferences ever year. Since I started at Esendex, I've been to a number of conferences over the years, most of them focused on the coding aspect of development; new frameworks, IDEs, tools etc. This year I was hungry for something more focused on the management practices and processes in agile software development, something that I felt I need to add to my skillset as an aging developer (I may not look it, but I'm 27!).

The team at work had been discussing conferences and XP2011 came up, when I investigated the conference program it sounded promising; just what I'd been looking for infact. Add to the mix that it was in beautiful Madrid and I was sold.

Conference format

The conference is designed to bring agile researchers and practitioners together. The first and last days are dedicated workshops and tutorials for discussing hot topics in the world of agile. The 2 days between are the core conference days and the programme offers 5 parallel sessions; 3 focused sessions plus invited talks and reports from industry. They also offer time for OpenSpace on the Thursday, for attendees to create their own sessions/discussions.

What was it like?

Good, very good. I wasn't sure what to expect to be honest, but the venue and food was great, people were friendly and everything seemed well organised. The session and workshop speakers were generally very good and knew their subject material well. You'd see the speakers attending lots of other sessions and discussions as attendees, they were approachable too, giving the conference that bit more of a community feel to it. Everyone seemed friendly, approachable and open to discussing their own agile perspectives and challenges they've faced; which I particularly found value in. One of the most enjoyable aspects of the conference were the sessions with lightning talks (10-20 min condensed talks). The speakers that I found particularly interesting were Ken Power, Esther Derby, Emily Bache, David Anderson, Mike Hill and Liz Keogh. Expect to see some posts related to the more interesting topics I attended at the conference over the coming weeks.

The social events were also well organised and there were plenty of complimentary drinks and food for everyone. The Wednesday night geek disco was a particular highlight :)

Any complaints? Well, a few of the sessions based on research papers were presented by the researchers themselves, who seemed a little inexperienced at presenting and as a result the session wasn't enjoyable. You can have the most interesting material in the world but if you don't deliver it well, you don't engage me or the rest of the attendees and it's a bit of a waste of time.

Conclusion

I enjoyed it and I'd recommend it to others looking for a conference of this type. The attendees are  passionate about the subject matter and it's infectious. If the subject material for XP2012 (Sweden) grabs me, I may well return to satisfy my agile appetite.

Mock ControllerContexts in ASP.Net MVC

After performing an upgrade to MVC 2 for a web application last week, I had a number of tests failing. This gave me an opportunity to refactor some controller tests and create a base class for my controller test classes. This new base class is straight forward and allows me to mock HttpRequestBase and HttpSessionStateBase easily on the mock ControllerContext - it also has an overload for mocking AJAX requests too. I expect this class to grow in time but it serves my needs for now:

public class TestController
{
 public static ControllerContext GetMockControllerContext()
 {
  return GetMockControllerContext("GET", false, null, null);
 }

 public static ControllerContext GetMockControllerContext(string httpMethod, bool isAjaxRequest)
 {
  return GetMockControllerContext(httpMethod, isAjaxRequest, null, null);
 }

 public static ControllerContext GetMockControllerContext(Mock httpRequestBase, Mock httpSessionStateBase)
 {
  return GetMockControllerContext("GET", false, httpRequestBase, httpSessionStateBase);
 }

 public static ControllerContext GetMockControllerContext(string httpMethod, bool isAjaxRequest, Mock httpRequestBase, Mock httpSessionStateBase)
 {
  var headerCollection = new NameValueCollection();

  // Add header value for ajax requests
  if (isAjaxRequest) headerCollection.Add("X-Requested-With", "XMLHttpRequest");

  if (httpRequestBase == null)
  {
   httpRequestBase = new Mock();
   httpRequestBase.Setup(r => r.HttpMethod).Returns(httpMethod);
   httpRequestBase.Setup(r => r.Headers).Returns(headerCollection);
   httpRequestBase.Setup(r => r.Form).Returns(new NameValueCollection());
   httpRequestBase.Setup(r => r.QueryString).Returns(new NameValueCollection());
  }

  if (httpSessionStateBase == null)
  {
   httpSessionStateBase = new Mock();
  }

  var mockHttpContext = new Mock();
  mockHttpContext.Setup(c => c.Request).Returns(httpRequestBase.Object);
  mockHttpContext.SetupGet(c => c.Session).Returns(httpSessionStateBase.Object);

  return new ControllerContext(mockHttpContext.Object, new RouteData(), new Mock().Object);
 }
}

When a Stand-Up Becomes a Sit Down

I'm not always a morning person, so when the morning stand-up meeting becomes extended I get a little frustrated.

To me the daily stand-up should take place every morning, within an hour but not first-thing (this gives people a chance to gather their thoughts/make coffee and wake-up). The meeting itself should be kicked off by the last person to attend, it should involve us standing in our project teams and involve us going around each team in turn. One member from each team have 3 questions to answer:

• What have you done since yesterday? "Yesterday we did X"
• What are you planning to do today? "Today we plan to do Y"
• Do you have any problems preventing you from accomplishing your goal? "We currently have no problems" - (hopefully)

The stand-up is great for a brief update on what is happening in the team and the 3 questions should be answered clearly and concisely within 60 secs (no room for waffle and unnecessary details). The stand-up is also great for people to make commitments. So if a team says "Today we plan to complete X" ... the development team will be expecting that that team tomorrow to say "Yesterday we completed X" – it helps people realise commitments.

How to know when your stand-up ceases to be (a stand-up)...

• The three questions aren't answered concisely and it takes > 60 secs
• There is a discussion between two people resulting in ‘spectators’
• People start losing interest and start staring out the window
• Someone sits down ;)

These things ruin stand-ups, the rhythm that's supposed to be associated with it and an extended stand-up is detrimental to its purpose!

Testing Private Methods in .Net

Some developers seem to be against testing private methods, that if you need to test private methods there is a design issue. I don't think I agree in all cases and extracting some method logic into another method for further testing seems valid to me. Having to make that method public (against it's design) just for testing purposes doesn't sit right, so I test private methods using the PrivateObject class found in the Visual Studio TestTools library...

[TestMethod]
public void IsValidInput_NumberString_ReturnsTrue()
{
 // Arrange 
 var myClass = new MyClassWithPrivateMethod();
 var privateObject = new PrivateObject(myClass);

 // Act
 bool result = (bool)privateObject.Invoke("IsValidInput", new object[] { "123" });

 // Assert
 Assert.IsTrue(result);
}

Resx Resource Problems when Unit Testing

If you use resx files for something like translations in your web apps, you'll notice problems when unit testing as your web app won't be running in its natural state and those resources won't be loaded as normal. Typically you'll get the error...

Could not load file or assembly App_GlobalResources

I'm yet to find a decent solution for this problem but here's how I currently get around it in MVC apps. Here I'm replacing my dependency on Strings.resx in App_GlobalResources.

First thing to do is to create a ResourceManager property and make use of this instance within the class you're testing. Now whenever you need to make use of the resource you have to replace the normal syntax of Strings.FieldYouWant with StringsResource.GetString("FieldYouWant") as shown in the method MethodBeingTested().

public class MyController
{
   public ResourceManager StringsResource
   {
      get;
      private set;
   }

   public MyController()
       : this(Strings.ResourceManager)
   {}

   public MyController(ResourceManager stringsResourceManager)
   {
      StringsResource = stringsResourceManager;
   }

   public object MethodBeingTested()
   {
      return new ContentResult( StringsResource.GetString("FieldYouWant") );
   }
}

In your test project you'll need to create a Strings.resx mirrored source file and make use of this when testing MyController class. Do this by instantiating with a resource from the calling test assembly...

var stringsResource
   = new ResourceManager("test.assembly.Strings", Assembly.GetExecutingAssembly());
var controller = new MyController(stringsResource);

...not pretty, but at least you can run your unit tests without an exception slapping you around the face. Any one got a better solution?

Hudson as an Alternative to TFS

I've been looking at alternatives to Team Foundation Server for my latest project's continuous integration tool... and I think I've found it!

Hudson was suggested to me by a colleague (Jonathan Relf) after his attempts with Cruise Control became a little frustrating.

You'll have Hudson installed and building your projects in under an hour unless you're stupid or get carried away with the large number of plugins, including a Chuck Norris plugin ;)

I particularly enjoyed...

• VERY easy to setup
• LOADS of plugins
• Setup, monitioring and configuration is all through a nice web based interface

I'll keep you posted with how I get on.

Unit Test Naming Conventions

Unit test names can be horribly long and misleading at times. I particularly hate...

AMethod_That_IS_Long_n_HasUnderscores_AT_Random_Points

Naming them in a concise, clear manner is important but consistency is the key. I use a simple convention to help me with naming my test methods that I've seen others use.

// MethodNameBeingTested_Input_Output
ToySearch_WhenNoToysFound_ReturnsZeroToysFoundView

Steve Sanderson suggested (on his blog) that we call this naming convention SSR (Subject, Scenario, Result), sounds good to me :)