Archive for January, 2009

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 ==;
    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
    public Customer GetCustomer(int id)
        return Customer.Empty;
    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.

The Curse Of The Rewrite

Uncle Bob writes about why rewriting an existing Big Ball of Mud is probably the worst thing you can do:

It’s depressing to think that many of the projects I have been brought in on over the past few years were grand rewrites. Technically they have been relatively successful, but probably viewed by the business as time-wasting and expensive. It’s time for this madness to end! Pick up a copy of Michael Feather’s book and start scrubbing!

User Interface Code And The Open/Closed Principal

The Open/Closed Principal (OCP) is a fundamental object-oriented design principal that states:

“Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.”

This means that we should be able to add new behavior to a software entity without altering its code.

Most UI code I have seen, including Model-View-Presenter (MVP) and Model-View-Controller (MVC) implementations, clearly violate the open/closed principal.

When developing UI code, we tend to create presentation classes in terms of views, or sections of the UI. To add new behavior to the UI, we need to modify these presentation classes. This increases the risk of breaking existing functionality.

UI development can be notoriously complex because of the many interactions and state changes that can occur. To manage this complexity we should ensure that our classes have only one reason to change.

Instead of grouping presentation classes into visible sections of the UI, maybe we should be creating a series of discrete presentation behaviors that react to events raised from the view.

These behaviors can be added and removed without affecting other behaviors on the page.

Behavior-Driven Development (BDD) advocates creating tests based on individual behaviors, so why not create our presentation classes in the same way? The tests then correspond directly to a single discrete unit, rather than a behavior that occurs within a larger structure, e.g. a presenter class.

Each behavior has a name that describes the behavior it represents. Using a descriptive name provides instant documentation of the UI behavior. It should be easy for someone to understand what the UI does simply by looking at the behavior names. If a problem occurs, it should be easy to identify and isolate the affected behavior.

Implementing Presentation Behaviors

I have created a simple music finder application that demonstrates an implementation of presentation behaviors.

Download the sample code here.

The sample application contains a single page, represented by an IFindMusicView interface. The behaviors respond to events raised by this View and update the View accordingly.

A typical behavior can be defined as:

Given… a particular scenario

When… an event occurs

And… all conditions have been met

Then… do something

And… do something else

Each behavior is implemented as a class that derives from a base class with an IBehavior interface. This interface contains two methods: When() and Then().

The When() method contains code that registers the behavior with a certain event on the page. The Then() method contains the code that responds to the event if all conditions have been met. The “Given” aspect is implemented by the class constructor, which takes the view and any associated dependencies.

   1: public class when_song_list_is_empty_disable_select_button : FindMusicBehavior
   2: {
   3:     public when_song_list_is_empty_disable_select_button(IFindMusicView view)
   4:         : base(view)
   5:     {
   6:     }
   8:     public override void When()
   9:     {
  10:         View.AfterSongsLoaded += (sender, e) => Then();
  11:     }
  13:     public override void Then()
  14:     {
  15:         View.IsSelectButtonEnabled = View.SongsList.Count > 0;
  16:     }
  17: }


The behaviors are instantiated by the View, but an Inversion Of Control container could be used to register the behaviors at run-time. The View then wouldn’t need to know anything about the behaviors that are implemented for it. We could then drop-in and drop-out behaviors without needing to change the existing code.

Further Considerations

Although this is an interesting concept, I am yet to implement it on a large-scale application. There are several areas I need to investigate further, such as:

  1. Can one behavior extend the functionality of another behavior?
  2. Can parallel behaviors remain independant from one another?
  3. How does this work with MVC frameworks? Are the behaviors triggered by actions?
  4. How well does this scale?


Does this concept make sense? Does it sound practical? Could it potentially solve some of the issues we face with developing complex UI code? Any feedback would be greatly appreciated.