Services Are Not Objects

Many .NET applications I see that have a so-called Service-Oriented Architecture (SOA) use a technology such as Windows Communication Foundation (WCF) to treat services as if they were local objects. You call methods on the remote object in the same way as you would call a local object, only rather than executing locally, the request is sent to a remote service for processing which may then return a response. This is known as a Remote Procedure Call, or RPC. Often these calls can cause the application to hang while waiting for a response. The usual way to handle this is to call the service method asynchronously, providing a method to call when a response comes back. This allows your application to continue processing after the request is made.

Sounds simple enough, but I have found these direct request-response calls can lead to a fragile and unreliable application that is tightly-coupled to the services it calls. If for some reason a service is not available, your application may stop functioning. Sure, you can build in error-handling, but it then becomes the responsibility of your application to manage the dependency on the service.

Recently, Jennifer Smith and I were discussing the unreliable nature of these architectures on Twitter, when Udi Dahan, SOA specialist and creator of NServiceBus, pointed us to a recent blog post of his that explains why we shouldn’t call services as if they were real objects. Udi suggests that there is a better way to handle calls to services and that is to use a message queue. He also makes the point that we need to stop treating services as local objects and use messaging as in integral part of the application architecture:

A queue isn’t an implementation detail. It’s the primary architectural abstraction of a distributed system.

So, if you’re developing a distributed application, use a message bus to communicate between applications. The message bus is responsible for transporting messages between applications. When you use a message bus, the application that sends a message is no longer coupled to the receiver.

I am currently converting a fragile request-response service-based application to use messaging with the NServiceBus message bus. I hope to significantly improve the performance and robustness of the application by making messaging a first-class citizen in the architecture, and not just an abstraction.

For more information on messaging and NServiceBus, check out:

• An overview of NServiceBus
• Udi Dahan’s blog

This book also contains excellent information on designing and developing messaging solutions:

• Enterprise Integration Patterns

Features and Specs

I’m going to take a short diversion from my series on BDD with ASP.NET MVC to talk about the difference between Features and Specs in Behaviour-Driven Development.

I am currently reading the beta version of The RSpec Book. This is an excellent book that covers doing BDD in Ruby using RSpec and Cucumber. From reading this book, I have come to realise there is a distinct difference between higher-level user acceptance criteria (features) and and lower-level context-specifications (specs).

Features

Features are the things that the customer is likely to be most concerned with. They are high-level behaviours that are derived from the acceptance criteria of a user story. They are purely concerned with how the user interacts with the application and don’t provide any details of implementation.

Features can be used to facilitate communication with the customer on what business objectives the application should achieve.

A feature consists of a user story and one or more example scenarios, which serve as our acceptance criteria. An example of a feature would be:

Story: Account Holder withdraws cash

  As an Account Holder 
  I want to withdraw cash from an ATM
  So that I can get money when the bank is closed

  Scenario 1: Account has sufficient funds 
    Given the account balance is $100
    And the card is valid
    And the machine contains enough money
    When the Account Holder requests $20
    Then the ATM should dispense $20
    And the account balance should be $80
    And the card should be returned

Features can be turned into automated acceptance criteria. In Ruby, we can use Cucumber to parse a plain-text file and run each scenario against the application. These are usually slow-running, end-to-end integration tests. In .NET we would use a BDD framework such as NBehave, or a standard unit-testing framework to implement the features as automated acceptance criteria.

Recently, I have been using Cucumber for automating the acceptance criteria for a .NET application, using Waitr to drive the browser. With IronRuby, we will be able to access our .NET objects directly from Cucumber. As of this post date, IronRuby does not work with Cucumber, but a fix should be out very soon.

Specs

When we have defined a new feature, we must create the objects required to implement it. To do this we need to “drop-down” to the object-level and use a context-specification style to define how these objects should behave.

Specs are implemented as fast-running, unit-level tests with stubbed dependencies. In Ruby, RSpec is used to define the specs. In .NET we would use a standard unit-testing tool, such as NUnit.

A spec consists of an action on an object, within a certain context, and the observations made from that action. An example of a spec would be:

When ATM requests withdrawal and account has sufficient funds
  Should check account balance
  Should send “Please wait” message to screen
  Should begin transaction
  Should withdraw funds from account
  Should dispense cash
  Should end transaction
  Should return card
  Should send “please take your card” message to screen

These steps describe the interaction between our object and its dependencies. They do not necessarily reflect the user’s observations (e.g the user doesn’t observe a transaction taking place).

We are not as concerned about testing the state of an object as we are about defining how it interacts with other objects. For instance, using the Model-View-Controller pattern, if we’re specifying a controller, we want to make sure an action sends a certain “message” to the view, rather than testing how it affects the state of the view. By specifying interaction over state, we are better able to define the roles and responsibilities of our objects.

I will try to incorporate some of this into the PlaylistShare sample application to demonstrate the distinction between Features and Specs.

Using Behaviour-Driven Development with ASP.NET MVC – Part 2

In part one, I introduced the PlaylistShare project, created some initial user stories, defined the acceptance criteria and created a template for writing executable specifications. In this part, I am going to write some executable specs for viewing playlists and implement the behaviour to make them pass. You can download the source code at the end of this post.

There a couple of approaches you can take when writing specs for an ASP.NET MVC user interface. Either you can run them directly against the UI from inside a browser, using a tool such as WaitiN. Or, you can drop in just below the UI and run the specs against the controllers. I prefer running them against the controllers as they run much faster and are not susceptible to changes to the HTML elements. However, you may find some aspects are better specified using a UI testing tool, such as behaviour that relies heavily on client-side scripting, which the controllers know nothing about.

I will be starting with the executable specification template I created in part one:

namespace view_playlist_specs

{

    namespace scenario_of

    {

        public abstract class listener_views_playlists : Specification<PlaylistController>

        {

            protected override PlaylistController create_subject()

            {

                // Create the system under test

                return new PlaylistController();

            }

            protected void given_a_list_of_playlists()

            {

                // Establish a list of playlists

            }

        }

    }

    namespace viewing_a_list_of_playlists

    {

        [TestFixture]

        public class when_the_listener_views_the_playlists 

            : scenario_of.listener_views_playlists

        {

            protected override void setup_scenario()

            {

                // Arrange

                given_a_list_of_playlists();

            }

            protected override void execute_scenario()

            {

                // Act

            }

            [Test]

            public void should_display_a_list_of_playlists()

            {

                // Assert

            }

            [Test]

            public void playlists_should_be_ordered_by_date_submitted_from_newest_to_oldest()

            {

                // Assert

            }

        }

    }

}

The first scenario we are going to implement is:

Story: Listener views playlists

As a playlist listener, I can view a list of playlists that have been submitted, so that I can find a playlist I might enjoy.

Scenario 1: Viewing a list of playlists

Given a list of playlists

When the listener views the playlists

Then should display a list of playlists

  And playlists should be ordered by date submitted from newest to oldest

First, lets create a new ASP.NET MVC application and add a PlaylistController to give us a subject to work with.

[HandleError]

public class PlaylistController : Controller

{

    public ActionResult Index()

    {

        return View();

    }

}

Now that we have a controller, let’s specify the first outcome of the scenario.

[Test]

public void should_display_a_list_of_playlists()

{

    the_view_model.should_be_equivalent_to(playlists);

}

The outcome states that a list of playlists should be viewed on the page.

the_view_model is a property on the spec base class that wraps calls to ProductsController.ViewData.Model. This makes the code slightly more readable. We can use ViewData.Model on the controller to pass data back to the view. In this case we want to pass back a list of Playlist objects.

You will notice I have used a method called should_be_equivalent_to to verify that the_view_model contains the same elements as playlists. This is an extension method defined in a SpecificationExtensions class I have added to the project. This class contains some helpful extension methods that wrap-up calls to NUnit assertions. This enables us to assert conditions directly on the objects, producing slightly more readable outcomes. Again, this is a personal preference and you can use ordinary Assert calls if you wish.

Running this spec should result in a failure, as we are not yet returning any playlists from the Index() controller method. We need to provide the controller with our list of playlists. To do this, we need to somehow pass a list of Playlist objects to the controller. The best way to do this is to use Dependency Injection and Mocking to pass a Repository containing our Playlist objects into the controller. Woah! Sounds complicated. But, it’s actually quite simple…

Let’s modify the PlaylistController to take an IPlaylistRepository and initialise a field in the constructor.

[HandleError]

public class PlaylistController : Controller

{

    private readonly IPlaylistRepository _playlistRepository;

    public PlaylistController(IPlaylistRepository playlistRepository)

    {

        _playlistRepository = playlistRepository;

    }

    public ActionResult Index()

    {

        return View();

    }

}

Now we need to pass an instance of this repository when we create the PlaylistController in our specs. To do this I am going to generate a stub using RhinoMocks. This creates a runtime implementation of the IPlaylistRespository that we can pass into the controller.

protected override void setup_scenario()

{

    playlist_repository = MockRepository.GenerateStub<IPlaylistRepository>();

}

protected override PlaylistController create_subject()

{

    return new PlaylistController(playlist_repository);

}

The setup_scenario method gets called right before create_subject, so we can use this to create any dependencies before the PlaylistController gets instantiated. Any scenarios can create additional context by overriding the setup_scenario method.

Now we need to add a GetAll() method to IPlaylistRepository that allows the PlaylistController to retrieve a list of Playlist objects.

public ActionResult Index()

{

    var playlists = _playlistRepository.GetAll();

    return View(playlists);

}

Back in our specs, we can now tell the stubbed playlist_repository to return some Playlist objects whenever the GetAll() method is called.

protected void given_a_list_of_playlists()

{

    playlists = new List<Playlist>

                    {

                        new Playlist(),

                        new Playlist(),

                        new Playlist()

                    };

    playlist_repository.Stub(r => r.GetAll()).Return(playlists.ToArray());

}

Our spec should now be passing! We have now confirmed the controller is passing a list of playlists to the view to display on the page.

So, let’s write an assertion for our next outcome: “playlists should be ordered by date submitted from newest to oldest”. Here we verify that the Playlist objects sent to the view are ordered by date-submitted in a descending order.

[Test]

public void playlists_should_be_ordered_by_date_submitted_from_newest_to_oldest()

{

    the_view_model.should_be_ordered_by_descending(p => p.DateSubmitted);

}

For this to compile we need to add a DateSubmitted property to the Playlist object.

I have created a helper method called should_be_ordered_by_descending that will verify that the playlists are ordered correctly. It’s really useful to create extension methods for complicated assertions to better explain what is being verified.

We can now make this spec pass by using LINQ to order the list of Playlist objects in the controller action before they are returned to the view.

public ActionResult Index()

{

    var playlists = _playlistRepository.GetAll();

    return View(playlists.OrderByDescending(p => p.DateSubmitted));

}

Here is the output from the Resharper test runner:

Using these naming conventions means that if a spec fails, it’s easy to identify what behaviour is causing the problem. You also get clear, concise, executable documentation that describes how your application behaves.

You might have noticed that I have been implementing the playlist controller without even running the web site. By implementing the controller first, we can focus on the core behaviour of the application without being concerned about how it is presented. In the next part, we will create the view that displays the playlists on the page.

Download the source code for Part 2

Using Behaviour-Driven Development with ASP.NET MVC – Part 1

Introduction

Welcome to the first post in a series where I hope to demonstrate creating an ASP.NET MVC application using Behaviour-Driven Development (BDD).

I agonised over how to introduce this blog post. In the end, I figured it would be best just to get straight into it! There are plenty of excellent articles that introduce the concepts behind both BDD and ASP.NET MVC, so I won’t bother repeating it here. I will explain core concepts along the way and provide links to further information. If you feel that I haven’t explained something properly, or have missed something, then please post a comment and I’ll try to elaborate further.

Right, let’s get started. The application I am going to build is a playlist sharing web site aptly called PlaylistShare (slightly unimaginative, but if you have a better name, let me know! . Music streaming services like Spotify are becoming increasingly popular and a number of sites have sprung up that allow you to share playlists with other people. I don’t intend this example to be anything unique or new, but I thought it would be an interesting subject and not yet-another-storefront example.

I will provide a link to download the source code at the end of each post. I have also created a Google Code project to host the source code.

It All Starts With a Story

BDD is an outside-in development process. We start by identifying goals and motivations, then drill down to the features that will achieve those goals. So, I’ve come up with a few user stories to get us started.

Story: Listener views playlists

As a playlist listener, I can view a list of playlists that have been submitted, so that I can find a playlist I might enjoy.

Story: Listener views playlist details

As a playlist listener, I can view the playlist details, so that I can get more information about the playlist.

Story: Contributor submits a playlist

As a playlist contributor, I can submit a playlist, so that others can listen to it.

There are a lot of other features I can add, but as a “business”, these are my top priorities and will allow me to get something functional delivered first.

Defining Acceptance Criteria

In order to determine what behaviour to implement, we need to create a list of acceptance criteria for each story. The acceptance criteria allows us to define when a story is “done”.

Note: this is a very important stage. It allows all members of the team to share a common understanding of what the system is meant to do. It is tempting to jump straight to writing the executable specifications, but this stage needs to be carefully considered and have input from the customer and testers.

We will define the acceptance criteria as example scenarios using a given/when/then vocabulary.

Story: Listener views playlists

Scenario 1: Viewing a list of playlists
Given a list of playlists
When the listener views the playlists
Then should display a list of playlists
  And playlists should be ordered by date submitted from newest to oldest

Story: Listener views playlist details

Scenario 1: Viewing playlist details
Given a playlist
When the listener views the playlist details
Then should display the playlist details
  And should display a link to listen to the playlist

Story: Contributor submits a playlist

Scenario 1: Submitting a playlist
Given a playlist
When the contributor submits the playlist
Then should submit the playlist
  And should display a message confirming the submission was successful

Scenario 2: Submitting a playlist without a name
Given a playlist without a name
When the contributor submits the playlist
Then should display a message saying the name is required
  And should not submit the playlist

Now that we have defined some acceptance criteria, we can create the executable specifications used to drive the implementation (a fancy way of saying, “write some tests!”). As we go forward we will probably identify other features we would like. We will make a note of these then add them to our next “iteration”.

Writing Executable Specifications

In BDD, tests are called specifications. This is mainly to get away from the notion that we are “testing”. Rather, we are defining behaviours that will drive the development process. We will still end up with a full suite of automated tests, but this is merely a very handy side-effect, not the goal, of BDD.

There are a number of BDD frameworks available for .NET, the most well-known of these being NBehave. However, these frameworks can be difficult to get started with and can distract us from the main purpose of BDD, which is to effectively describe the application behavior. This is not because these frameworks are bad, but is more to do with the constraints of the C# language. BDD frameworks are much more effective in languages like Ruby, where the syntax makes it very easy to write readable specifications using frameworks such as RSpec and Cucumber. For this example, I am going to stick with using NUnit and structure the test classes and member names to enable us to write BDD specifications. It will be a glorious day when when eventually see RSpec and Cucumber working on IronRuby and integrated seamlessly with our .NET applications. Until then, this is my current preference for writing BDD-style specifications in real-world applications.

I use a common Specification base-class to provide a framework for writing the specifications. This simple class contains the NUnit setup/teardown methods, handles exceptions and coordinates the various stages of executing a scenario.

These are a few conventions I use when writing BDD-style specifications:

• Specification names are lowercase with underscores. This_is_to_make_the_specifications_more_readable. It is a personal preference, but I find PascalCaseNamingBecomesHardToReadForLongSentences (see what I did there… heh).
• One test-fixture per scenario. Each test fixture represents a scenario of the story.
• Each test-fixture is wrapped in a namespace that describes the scenario. This allows us to easily navigate the scenarios and prevents naming conflicts with other actions. This becomes important when we have the same action in different scenarios.
• Each test-fixture name defines the action. An action is the “when” part of a scenario. It is the event that causes the behaviour.
• Each test-fixture derives from a base class that describes the story. By inheriting from a base class, we can provide common set up data that is shared across all scenarios in the story. It also provides us with a handy reference back to the original story.
• The context is set before executing the action. The context is the “given” part of a scenario. The context sets the state of the system-under-test and its dependencies before the action is invoked. Wrapping setup code in helper-methods makes it easy to see what context we are creating and to reuse common setup steps.
• One test per outcome. An outcome is the result of an action, the “then” part of a scenario. We may have many outcomes from an action, but we should only be testing for one thing per outcome. So try to only make one assertion per test method. Test for other outcomes in separate test methods.

The outline for the first scenario looks like this:

namespace view_playlist_specs

{

    namespace scenario_of

    {

        public abstract class listener_views_playlists : Specification<PlaylistController>

        {

            protected override PlaylistController create_subject()

            {

                // Create the system under test

                return new PlaylistController();

            }

            protected void given_a_list_of_playlists()

            {

                // Establish a list of playlists

            }

        }

    }

    namespace viewing_a_list_of_playlists

    {

        [TestFixture]

        public class when_the_listener_views_the_playlists 

            : scenario_of.listener_views_playlists

        {

            protected override void setup_scenario()

            {

                // Arrange

                given_a_list_of_playlists();

            }

            protected override void execute_scenario()

            {

                // Act

            }

            [Test]

            public void should_display_a_list_of_playlists()

            {

                // Assert

            }

            [Test]

            public void playlists_should_be_ordered_by_date_submitted_from_newest_to_oldest()

            {

                // Assert

            }

        }

    }

}

Download the source code containing the outline for the first scenario.

I hope this has been a helpful way to get started. I will explain a lot more about writing specifications in upcoming posts. Please feel free to post any questions or comments. In the next part of this series, I will begin implementing a playlist controller and passing the scenarios.

Becoming a Polyglot Programmer

We .NET developers have always had the security blanket of a general purpose language like C# or VB.NET that we’ve been able to use for pretty much anything we need. However, it is becoming increasingly important for a developer to know several languages covering different paradigms and to have the ability to choose the best language for the problem at hand.

The Pragmatic Programmer recommends learning a new language every year. I’m currently taking that to the extreme and have several languages on the go.

C

I never learned C. I went straight from a basic understanding of Java to ASP/VBScript (ah, those were so not the days). So now I’m playing catch-up, learning about exciting things like pointers and memory allocation – all things that I have heard about many times, but never fully understood.

I’m current reading The C Programming Language, which is a very concise (only 274 pages) and superbly written book. If you know C#, then most of what’s covered will not be new. In fact, C is nowhere near as intimidating as I thought it would be, and it’s really made me appreciate the things I took for granted in modern C-based languages.

Haskell

Functional languages are hitting the mainstream, big time. I learned basic functional language principals using Haskell at Uni over 10 years ago. Back then it was pretty much an academic language that complemented a mathematics paper I was doing. These days, functional languages offer a promising solution to concurrency problems with software running on multi-core processors. Haskell is a purely functional language, which means you cannot sneak in a for-each loop when the going gets tough. It’s a great way to learn how to solve a problem in a functional manner, using a functional mindset.

It’s easy to get started with Haskell. I’m currently making my way through this excellent tutorial: Learn You a Haskell for Great Good.

Javascript

I already know Javascript. Or at least I thought I did. Javascript has made a big comeback recently with the increasing popularity of client-side web programming for creating rich websites. The emergence of excellent frameworks like JQuery take the pain out of cross-browser support and DOM manipulation, which has always been the bane of Javascript development. On the surface, Javascript looks like a weak language with some bad features. But strip away the bad parts and there’s a really neat, powerful and dynamic language that runs pretty much anywhere!

With web applications becoming increasingly reliant on rich-client capabilities, it is important for any web developer to have a solid understanding of Javascript. If you are already familiar with Javascript, I would recommend the book Javascript: The Good Parts to take you to the next level.

Ruby

I previously posted on my adventures in Ruby and mentioned some good resources for getting started. Ruby is a very powerful, dynamic and portable language that can be used for many tasks big or small. From building full-scale web applications using Rails, to writing build scripts using Rake. Many .NET developers are replacing the XML-heavy NAnt build files with Rake scripts, which allow much greater flexibility by using the expressiveness of Ruby to coordinate the build tasks. The potent combination of RSpec and Cucumber for writing BDD specs make good use of Ruby’s dynamic and readable syntax. With the release of IronRuby on the horizon, .NET developers will be able to get the benefits of this great language running natively on the .NET Framework via the Dynamic Language Runtime.

F#

F# is a multi-paradigm language for the .NET framework and encompasses both functional and imperative elements. I’ve barely scratched the surface of F#, but it looks very promising indeed. The more we require functional elements in our day-to-day programming, the more important it is to have a language that fully supports functional programming. C# 3.0 has some great functional features, such as LINQ and lambda expressions, but F# looks to offer much more powerful set of functional features.

Conclusion

So, I have a lot of learn! I don’t expect to become an expert in all these languages at once. But I think having a basic understanding of each has already helped me to improve my general programming skills and to approach problems in different ways.

If you are interested in learning a new language, I would recommend you know at least one dynamic and one functional language. If you’re feeling particularly up for a challenge, try LISP

Software Craftsmanship 2009

Yesterday I attended the Software Craftsmanship 2009 conference held at the BBC media centre in London. Overall, it was a great day with some really interesting sessions covering a wide variety of topics. It was especially interesting to share ideas and experiences with developers from different backgrounds using different languages and platforms.

The first session I attended was Pitfalls in Test Authoring with Dave Cleal and John Daniels from Syntropy. This session was an open discussion on identifying test anti-patterns. Some really good points were raised and the discussion was very open and frank. There was some debate on whether unit tests should ever hit the database and what the scope of a unit test should be. This discussion later led to an open spaces talk on functional (integration) testing versus unit testing.

The next session I attended was Gojko Adzic’s talk on Specification Workshops. Gojko gave an excellent presentation on running workshops for the whole team to discuss the requirements for an iteration. One point that stood out for me was that the workshop should focus on what the software needs to do and not how to do it.

Over lunch I had a good chat to some java developers on why we should minimize code comments and the use of NOJOs ("Non Object-oriented Java Object", or DTOs to us .NET developers).  I also had a chance to catch up with some ex-BBC colleagues who were attending the conference.

After lunch I went to a session on Responsibility-Driven Design with Mock Objects by Willem van den Ende and Marc Evers. This was a live pair-programming session developing a text-based adventure game using RSpec and Ruby. The tests were focused on object collaboration rather than state. It was really interesting to see the use of mock objects in Ruby. I also found the focus on pure mocking for testing object collaboration to be very different from using mock objects to simply replace dependencies.

The next session was Empirical Experiences of Refactoring in Open Source by Steve Counsell from Brunel University. Steve presented his findings on the use of refactoring in open-source software. His findings were interesting but I was left a bit confused by what the results of the study meant for software teams. I would be interested to learn more about the conclusions of the study.

The final session I attended was on Test-driven Development of Asynchronous Systems by Nat Pryce. Nat gave a good talk on his experiences with end-to-end testing of asynchronous systems.

We finished the day with a tour of the BBC Television Centre and a few beers in the bar upstairs. A few of us got to see Jonathan Ross recording his Friday night show and apparently U2 were guests. Unfortunately we didn’t bump into Bono, but we did get to have a photo with a TARDIS.

All in all it was a great day and I would like to thank Jason Gorman for organising this excellent event.

Focus On Quality Improves Delivery

Ron Jeffries explains why software quality and speed of delivery are not mutually exclusive. If you want to continually deliver working software quickly, then you need to maintain high quality:

http://xprogramming.com/blog/2009/02/01/quality-speed-tradeoff-youre-kidding-yourself/

Uncle Bob has also posted his thoughts:

http://blog.objectmentor.com/articles/2009/02/03/speed-kills

I often find there is a lot of focus on delivering software quickly, but not so much on maintaining quality. I think this is because it is generally considered that maintaining high quality means greater expense and later delivery. However, the higher the quality of code, the better able we are to deliver working software quickly and repeatedly. My belief is that the quality leaver should never be touched, or you risk taking on crushing debt.

The War On Nulls

As .NET developers, we’ve all seen this exception hundreds of times: “System.NullReferenceException – Object reference not set to an instance of an object”. In .NET, this exception occurs when trying to access a reference variable with a null value. A null value means the variable does not hold a reference to any object on the heap. It is one of the most frustrating and prolific errors that we programmers encounter. But it needn’t be this way! We can prevent this error by following a few simple rules. But first, a little history…

The null reference was invented by Tony Hoare, inventor of QuickSort, one of the world’s most widely used sorting algorithms. In this introduction to his talk at QCon 2009, Tony describes the impact the null reference has had on software:

I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn’t resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years. In recent years, a number of program analysers like PREfix and PREfast in Microsoft have been used to check references, and give warnings if there is a risk they may be non-null. More recent programming languages like Spec# have introduced declarations for non-null references. This is the solution, which I rejected in 1965.

So obviously null references have caused quite a lot of damage. But neither Tony or null references are to blame. It’s the careless use of null references that has made them as damaging and prolific as they are.

I can’t think of a single reason why you would need to use null references as part of your system design. Here are some tips for preventing null references in your system.

Never use null references as part of the design

Business logic should not be based around testing for null references. If an object requires an empty state, be explicit about it by creating an empty representation of the object. You can then check if the object is in an empty state by comparing the current instance to an empty instance.

Here is an example of some code that uses a generic interface called ICanBeEmpty to support an empty representation of a Customer object. An extension method called HasValue() allows us to check if an object represents an empty instance.

public class Customer : ICanBeEmpty<Customer>

{

    private int id;

    private string name = string.Empty;

    //...

    public bool Equals(Customer other)

    {

        return this.id == other.id;

    }

    public static Customer Empty

    {

        get { return new Customer(); }

    }

    Customer ICanBeEmpty<Customer>.Empty

    {

        get { return Empty; }

    }

}

public interface ICanBeEmpty<T> : IEquatable<T>

{

    T Empty { get; }

}

public static class Extensions

{

    public static bool HasValue<T>(this ICanBeEmpty<T> obj)

    {

        return obj.Equals(obj.Empty);

    }

}

Don’t accept null references as parameters

Guard statements are often used to check for null references in methods. If you design your system not to pass nulls, you won’t need guards to check for null in your methods. But when you can’t guarantee input to your public methods, then you need to be defensive about null references.

Don’t return null references

A call to a method or property should never return a null reference. Instead, return an empty representation of an object, or throw an exception if a non-empty value is expected.

Fail fast if a null reference is detected

Design-by-contract technologies, such as Spec#, have declarations that can check for null references at compile time. You can also use an aspect-oriented programming (AOP) solution, such as PostSharp, to create custom attributes that ensures an exception is thrown if any null references are passed in, or returned by a method at runtime. By throwing an exception as soon as a null reference is detected, we can avoid hunting through code to find the source of a null reference.

public class CustomerRepository

{

    [DoesNotReturnNull]

    public Customer GetCustomer(int id)

    {

        //...

        return Customer.Empty;

    }

    [DoesNotAcceptNull]

    public void SaveCustomer(Customer customer)

    {

        if (customer.HasValue())

        {

            //...

        }

    }

}

Wrap potential sources of null references

If you are using a third-party service or component where you might receive a null reference, then wrap the call in a method that handles any null references to ensure they don’t leak into the rest of the system.

Always ensure object members are properly instantiated

All object members should be instantiated when an object is created. Be careful with strings in C#, as these are actually reference types. Always set string variables to a default value, such as string.Empty.

Nullable value types are ok

The nullable value types introduced in C# 2.0, such as int? and DateTime?, are better at handling null references as you have to explicitly cast them to a non-null value before accessing them. Be careful with using the Value property on a nullable type without first checking if the variable has a non-null value using the HasValue property. You can use GetValueOrDefault to return a default value if the variable is null.

By limiting the use of null references and not letting them leak into other parts of the system, we can prevent the troublesome NullReferenceException from ruining our day.

Are Burndowns Evil?

Agile teams often use a burndown chart to track the progress of a software project. The burndown chart provides an indication of work done over time. I have used burndowns on many projects and I have come to believe their use can negatively impact the quality of the software we deliver, without providing much benefit to the outcome of the project.

Firstly, a burndown can create schedule pressure early in the iteration. This is especially apparent on a new project with a new team. It takes time for a new project to get under way and for team members to get up to speed. This time can be very difficult to factor into an iteration.  Even though progress will improve, seeing the burndown flat-lining immediately can cause a lot of negative pressure on a team.

A burndown chart is linear and has no room for variations in team size, unscheduled meetings, unforeseen technical problems and other issues outside the control of the team. The burndown doesn’t take into account the unplanned, but necessary work that needs to be done to ensure the success of the project.

A burndown can be very unforgiving. One bad day and the progress line goes off course. This can cause pressure within the team to cut corners to get back on track. This is detrimental to the quality of the software and encourages developers to get a story done quick-and-dirty just to satisfy the burndown progress.

The progress of a burndown can be taken the wrong way by project managers and customers. No stories complete == no work done, which is usually not the case. If we need to track progress, we can simply look at the task board! How many stories are done? How many are still to do? How much time is left in the iteration? What needs reprioritising? Talk about it. Discuss the issues. The task board is a great place for the team to get together and talk about the progress of the project. If required, create a throw-away progress chart. But we shouldn’t drive the development process from it.

Use the number of points/ideal-days completed to estimate the team’s velocity. The velocity should be calculated on work already completed. For a new team and a new project, it is almost impossible to predict a velocity for the sake of creating a burndown, so why bother? It can cause more harm than good.

Another problem with the linear nature of a burndown is that it doesn’t factor in breakthroughs. A breakthrough is a fundamental shift in the understanding of a software design. This is a very important step in improving the design, quality and maintainability of the software. If a breakthrough is discovered by the team, then taking the time to refactor should be encouraged. Breakthrough refactorings can be hugely beneficial for the future development of the software.  A burndown can discourage refactoring and improvement by promoting a linear track.

The focus on a burndown is on reaching a predetermined end-point in time. Instead we should be focusing on delivering value to the business without compromising quality.

Experienced teams working on new or familiar software might not have any of these problems. I have been on projects where the burndown was very accurate and the project went very smoothly. But this was not because of a burndown. The burndown didn’t really provide any benefit to the outcome of the project. The project work was easy to estimate and so the burndown was always on track.

I’m not saying never use a burndown. They are often required by project managers to report on progress. Just don’t let it become the focus of the project, as it can potentially do more harm than good.

Building A Complex Web Forms UI

I recently wrote a post about composing a UI based on discrete behaviors. I thought maybe I should explain a bit more about the problem that led me to this idea.

Mike Wagg, Zubair Khan and I were tasked with developing a rather complex UI using ASP.NET Web Forms (the company had a suite of existing custom controls, so unfortunately MVC was not an option). We started-off using a Model View Presenter (MVP) pattern, but found that our presenters became overloaded with state management responsibilities. So we introduced a Presentation Model to handle the state and behavior of the View.

The ASP.NET page life cycle never failed to cause us grief. We attempted to abstract away the life cycle using a combination of a View, Presentation Model and backing Controller. The page populated the Presentation Model on Load and bound back to it on PreRender. Any state changes that occurred during the page life cycle was applied to the Presentation Model. The Controller’s responsibility was to receive events from the View, call out to services and pass data to the Presentation Model.

We found this greatly simplified things, as we didn’t have to worry about the changing state of the View throughout the page life cycle. We simply updated the Presentation Model and the View submissively bound to it at the end of the life cycle. We could also effectively test the entire process, as we didn’t rely on the page to manage state changes.

The only downside to the Presentation Model was that we had to change the code in order to accommodate new behavior. This violates the Open/Closed Principal (OCP) and increased the risk of breaking existing functionality. That led me to investigate the discrete behaviors approach that I blogged about.

Another problem we faced was getting the presentation components to talk to each other. We were using the View as the messaging bus, but this led to a lot of code that looked like parentView.childView.DoSomething(). This was very brittle, so we created an Event Hub that acted as a central messaging bus that any of the presentation components could publish/subscribe to.

We now feel we have this complex UI project under control. Mike is currently writing a series of posts that go into further details on the Presentation Model and Event Hub approaches. We learned a lot from this project and I hope this can help someone else who is creating a complex UI in a stateless web environment.