Mark Needham

One of the problems that I’ve frequently run into when writing C# code in a more functional way is that we can often end up with ‘Funcs’ all over the place which don’t really describe what concept they’re encapsulating.

We had some code similar to this where it wasn’t entirely obvious what the Func being stored in the dictionary was actually doing:

public class Calculator
{
	private Dictionary<string, Func<double, double, double>> lookups = new Dictionary<string, Func<double, double, double>>();
 
	public Blah()
	{
		lookups.Add("key", (input1, input2) => (input1 * 0.1) / input2);
	}
	...
}

Christian pointed out that we can create a named delegate (something I had completely forgotten!) so that it’s a bit more obvious what exactly we’re storing in the dictionary just by looking at the code.

We’d then end up with this code:

public class Calculator
{
	private delegate double PremiumCalculation(double input1, double input2);
 
	private Dictionary<string, PremiumCalculation> lookups = new Dictionary<string, PremiumCalculation >();
 
	public Calculator()
	{
		lookups.Add("key", (input1, input2) => (input1 * 0.1) / input2);
	}
	...
}

Now it’s pretty clear from just reading the declaration of ‘lookups’ what it’s being used for without needing to go further into the code to understand that.

This is just a simple example but the problem becomes more obvious the more angle brackets we end up with in our dictionary definition and pulling those Funcs out makes the code much easier to understand.

We’ve been writing quite a bit of code on my current project trying to encapsulate user selected values from drop down menus where we then want to go and look up something in another system based on the value that they select.

Essentially we have the need for some of the things that a Java Enum would give us but which a C# one doesn’t!

Right now we have several classes similar to the following in our code base to achieve this:

public class CustomerType
{
    public static readonly CustomerType Good = new CustomerType("Good", "GoodKey");
    public static readonly CustomerType Bad = new CustomerType("Bad", "BadKey");
 
    private readonly string displayValue;
    private readonly string key;
    private static readonly CustomerType[] all = new[] { Good, Bad };
 
    private CustomerType(string displayValue, string key)
    {
        this.displayValue = displayValue;
        this.key = key;
    }
 
    public static CustomerType From(string customerType)
    {
        return all.First(c => c.displayValue == customerType);
    }
 
    public static string[] Values
    {
        get { return all.Select(c => c.DisplayValue).ToArray(); }
    }
 
    public string DisplayValue
    {
        get { return displayValue; }
    }
 
    public string Key
    {
        get { return key; }
    }
}

To get values to display in drop downs on the screen we call the following property in our controllers:

CustomerType.Values

And to map from user input to our type we do this:

CustomerType.From("Good")

Right now that will blow up if you trying to parse a value that doesn’t have an instance associated with it.

Christian came up with the idea of storing each of the public static fields in an array and then using ‘First’ inside the ‘From’ method to select the one that we want.

We previously had a somewhat over complicated dictionary with the display value as the key and type as the value and looked it up that way.

So far this does all that we need to do and the only annoying thing is that if we add a new instance then we need to manually add it to the ‘all’ array.

An alternative would be to do that using reflection which I think would work but it’s simple enough like this so we haven’t taken that approach yet.

Continuing with our learning with Mercurial, yesterday we wanted to revert a couple of change sets that we had previously committed and go back to an old version of the code and continue working from there.

As an example, say we wanted to go back to Revision 1 and had the following changes committed:

Revision 3
Revision 2
Revision 1
Revision 0

My original thought was that we could merge revision 1 with the current tip:

hg merge -r 1

Sadly that won’t work because we can’t merge with an ancestor:

'abort: can't merge with ancestor'

I put the question to twitter and got a few different suggestions.

The first was to use ‘revert’ and go back to revision 1 like so:

hg revert -r 1

This works pretty well although my colleague Chris Turner pointed out that we could also use ‘backout’ like so:

hg backout -merge 3
hg backout -merge 2

The neat thing about that approach is that we get 2 changesets checked in showing the reversing of the changes that we previously checked in. We therefore have a better history of what exactly we’re reverted.

With this approach we could also back out changes which weren’t right near the tip of the repository as was the case in my example.

Another alternative is to clone the repository from the revision that we want to keep:

hg clone -r 1

With this approach we would lose the history of anything beyond that revision but if that’s what we want then it’s another approach to achieve our goal!

It’d be interesting to hear your opinions on which approach you take and if there are any others to solve the problem I described.

On the project I’m currently working on we have several stories around writing the code that does various different calculations based on user input and then shows the results on the screen.

The original assumption on these stories was that we would be looking up the data of the business rules from a local database. The data would be copied across from a central database into that one for this project.

After some discussion about one of the stories, Christian pointed out that the only reason that we needed to have that data in the database was so that it would be configurable in production without having to make code changes and redeploy the application.

I’d been working with the assumption that these stories could only be considered done when the data was coming from the database but we’ve extracted the ‘configurability of data’ out into another story which the business can choose to prioritise if that’s more valuable than other features we’re working on.

It didn’t even occur to me that we could pull this type of thing out but it seems like a useful approach as part of our drive to deliver the core functionality of the application as quickly as possible.

If we then need to go back and put in the configurability of the data, the lookup of that data is all hidden behind an interface so we shouldn’t see too much pain by choosing to delay doing that.

My colleagues Frankie and Danilo have been recommending ‘Maverick‘ to me for a long time and I finally got around to reading it.

In this book Ricardo Semler, the CEO of Semco, tells the story of the company and how he helped evolved the organisation into one which is more employee led and embraces ideas such as open & self set salaries while encouraging civil obedience in the workforce as a necessity to alert the organisation to its problems.

These were some of the ideas that I found the most interesting:

• Early on Semler points out that Semco doesn’t have a culture of looking busy. He describes how a sales manager spends a lot of his day just reading the newspaper but then as soon as there’s a problem for him to handle that’s when he earns his salary. Even though this book isn’t specifically about systems thinking, the description of this situation suggests to me that they are able to look at the bigger picture at Semco.

  In software teams we can often feel quite guilty if we’re not busy but a bit of slack time is often useful for thinking about better ways to do things or to spike out new ideas.

• Semler emphasises the need to have small business units of under 150 people while matches up quite well with research done by Robin Dunbar which indicates that 150 is the ‘theoretical cognitive limit to the number of people with whom one can maintain stable social relationships.’ Semler also adds that keeping the units small ‘keeps them human’.

  I know ThoughtWorks keeps this in mind with respect to our offices and will look to open a new one if the number of people in one is getting close to the 150-200 mark.

• Semco have a culture of what Semler refers to as ‘absolute trust‘ which he suggests is a more natural way. They implemented this at Semco by removing security checks on the gates into/out from the plants.

  He almost then predicts the inevitable question in the reader’s mind with the following statement:

  2 or 3% will take advantage of an employer’s trust. Is this a valid reason to subject 97% to a ritual of humiliation?

  Have thefts increased or decreased?

  I don’t know and I don’t care. It’s not worth it to me to have a company at which you don’t trust the people with whom you work.

  He promotes an approach of common sense amongst his employees, suggesting that ‘rules freeze companies inside a glacier; innovation lets them ride sleighs over it’.

  The general idea seems to be that the small details aren’t really that important and only serve to distract from the bigger objectives that the company are trying to achieve.

• I was quite surprised to read how strongly Semler recommends job rotation:

  Man is by nature restless. When left too long in one place he will inevitably grow bored, unmotivated, and unproductive. The cure, I believed, was to encourage managers to exchange jobs with one another

  He goes on to point out that this type of rotation forces people to learn new skills which makes them more valuable but also discourages empire building because people don’t stay in the same place for too long.

  I think we do this to some extent in the software industry between some roles but probably not as much as we could do. Having said that there is a lot to learn as a developer anyway so perhaps it’s not so applicable here.

• Perhaps the most controversial idea in the book is that of transparent/self set salaries. There was initially resistance to the latter idea as cynics believed that a few people would take advantage and award themselves massive pay increases. However, they found that having those salaries public served as a strong disincentive.

  He also identifies the fact that people have a stake in the success of the company as being key for allowing this to work:

  The third reason our people tended to be modest about salaries has to do with self preservation…Our people know salaries account for most of our operating costs, and they think about our budgets when they set them. It’s easy to solve a budget problem by eliminating a salary that seems too high, and noone wants to stick out.

• The underlying reason behind why a lot of the ideas Semler implements seem to be about unhiding information as described by the following quote:

  There is power in knowing something someone else doesn’t…but when cards are held close to the chest, communication will be faulty and anxieties, misunderstandings, insecurity, and eventually hostility will manifest itself…which is why when we started sharing information at Semco it has such a profound effect. People in the higher echelons could no longer rely on the conventional symbols and had to develop leadership skills and knowledge to inspire respect.

  Spreading responsibility for problem solving across the organisation is another idea Semler strongly encourages and I think this partly explains why it’s more fun working in an agile environment.

  Information in general is more accessible and because of that people have more opportunity to solve problems than they otherwise would.

• Semler discusses the need to keep the organisation lean even when times are good which he acknowledges is much more difficult than trying to keep it lean when times are hard! For Semco this involves being careful when hiring people to work on product lines which they knew had a short life span as well as ensuring that they didn’t add any unnecessary roles just because sales were strong.

Towards the end of the book Semler suggests that his goal with Semco was to ‘make people look forward to coming to work in the morning‘ which seems like quite a noble objective!

I found it quite interesting that although a lot of these ideas seem a bit radical, they made sense in Semco’s context because they were introduced incrementally and only after some other ideas had been introduced which helped smooth the way.

It’s certainly an interesting read and the ideas expressed at quite different than what is typical in most organisations.

While reading through an old blog post by Matthew Podwysocki about writing F# code in a functional rather than imperative way I came across the ‘defaultArg’ function which I haven’t seen previously.

It’s quite a simple function that we can use when we want to set a default value if an option type has a value of ‘None’:

The type signature is as follows:

> defaultArg;;
val it : ('a option -> 'a -> 'a) = <fun:clo@0>

And the definition is relatively simple:

let defaultArg x y = match x with None -> y | Some v -> v

We could then use it if we were looking up a key in a dictionary but wanted to return a default value if there wasn’t an entry for that key.

For example:

let myMap = Map.add "key" "value" Map.empty                
let result = defaultArg (Map.tryFind "nonExistentKey" myMap) "default"     
> val result : string = "default"

This is just another of the utility functions we can use in F# to allow us to keep composing functions even when we can get more than one type of result from another function.

We’re using Mercurial as our source control system on the project I’m working on at the moment and since I’ve not yet used a distributed source control system on a team I thought it’d be interesting to note some of my initial thoughts.

One of the neat things about having a local repository and a central one is that you can check in lots of times locally and then push those changes to the central repository when you want everyone else to get the changes that you’ve made.

So far we’ve been pushing much more frequently than would usually be the case using something like Subversion. For example I checked in after doing some tidy up on unused references whereas with Subversion I’d probably have included that as part of another checkin.

It actually makes development more fun and reminds me of a kata I did while checking in almost every minute last year.

We’re all still very much learning Mercurial but these are some of the commands that we’ve found ourselves using a lot so far:

• To check if there are any changes to pull from the central repository:

  hg incoming
  hg in

• To check if we have any changes that we haven’t pushed to the central repository:

  hg outgoing
  hg out

• To add any unversioned files and remove any missing files:

  hg addremove

• To remove a file from the repository and from the file system:

  hg remove /file/name

• To remove a file from the repository on the next commit but not remove it from the file system:

  hg forget /file/name

• To pull any changes from the remote repository and update your repository with them:

  hg pull -u

  This one only completely works if you don’t have any changes locally on the files you’re pulling in. Otherwise you’ll need to do a ‘hg merge’ afterwards.

  It seems like there’s a lot more merging to do when using Mercurial than with Subversion which we’re still getting used to but seems to be more natural as we use Mercurial more.

• To undo committing a file locally:

  hg rollback
  hg ci -X /file/to/not/commit -m"message and so on"

I’ve found Mercurial: The Definitive Guide by Bryan Sullivan and Joel’s hginit to be useful resources for learning more about this tool.

On the project I’m currently working on my colleague Christian Blunden has introduced a version of the Maybe type into the code base, a concept that originally derives from the world of functional programming.

The code looks a bit like this:

public interface Maybe<T>
{
	bool HasValue();
	T Value();
}

public class Some<T> : Maybe<T>
{
	private readonly T t;
 
	public Some(T t)
	{
		this.t = t;
	}
 
	public bool HasValue()
	{	
		return true;
	}
 
	public T Value()
	{		
		return t;
	}	
}

public class None<T> : Maybe<T>
{
	public bool HasValue()
	{	
		return false;
	}
 
	public T Value()
	{		
		throw new NotImplementedException();
	}	
}

We would then use it in the code like this:

public FooRepository
{
	public Maybe<Foo> Find(int fooId)
	{
		var foo = LookUpFooFromDatabase();
 
		if(foo == null)
		{
			return new None<Foo>();
		}
		return new Some<Foo>(foo);
	}

var maybeFoo = fooRepository.Find(1);
 
if(maybeFoo.HasValue())
{
	// do something with it
}
// fail in misery

The benefit we get from using this pattern is that we’re explicitly defining in the contract of ‘FooRepository.Find’ that the method might not return a ‘Foo’ rather than leaving the callee to work out whether or not they need to check for a null value.

It’s effectively the Nullable pattern except we can use it for reference types and not just primitives.

An alternative approach which Dermot pointed out is the null object pattern.

Typically when using that pattern we would treat the result of calling ‘FooRepository.Find’ the same regardless of whether we get a real ‘Foo’ or not.

That pattern would work quite well if we have to show a list of items in a grid, for example, and just showed blank cells if there isn’t a real ‘Foo’.

In our case we want to distinguish between whether we did or did not find a ‘Foo’ because the application behaves differently if we can’t find one. Therefore in this case the null object pattern doesn’t work so well.

One of the general guidelines that I like to follow when writing methods is trying to ensure that it’s only doing one thing but on several recent projects I’ve noticed us breaking this guideline and it feels like the right thing to do.

The method in question typically takes in some user details, looks up that user in some data store and then returning it if there is an existing user and creating a new user if not.

It would probably look something like this:

public class UserService
{
	public User FindOrCreateUser(string username)
	{
		var user = userRepository.FindUserBy(username);
		if(user == null)
		{
			user = CreateUserFrom(username);
		}	
		return user;
	}
}

My initial thought when we wrote it was that it seemed wrong but the method name does clearly describe our requirement so I’m not so sure it’s a bad thing.

NHibernate has a ‘SaveOrUpdate’ method which to me seems to cover similar ground although Save/Update are much closer in functionality then Find/Create so maybe that’s more justifiable.

I’d be interested to know whether you think this type of method is perfectly fine or whether we’re very very bad people for writing it!

Grant Joung wrote a post a while ago about velocity goals and whether they’re a good or bad idea, a topic which seems to come up from time to time on agile teams.

My colleague Danilo Sato previously wrote about the dangers of using velocity as a performance measure because it’s something that’s directly within our control and can therefore be gamed:

Value should be measured at the highest level possible, so that it doesn’t fall into one team’s (or individual’s) span of control. People tend to behave according to how they’re measured and if this metric is easy to game, it will be gamed.
…
Velocity doesn’t satisfy my criteria for a good performance measure. Quite the opposite, it’s a very easy metric to game

Danilo suggests that we should look to use metrics which are outside of our immediate control but which we can score high on if we focus on doing a good job. He cites the ‘net promoter score’ (that measures how much your custumer is willing to recommend you to a friend) as an example of this.

Dan North gave a really good presentation titled ‘Our obsession with efficiency‘ where he covers similar ground and touches on the gaming of performance measures.

From my experience having velocity as a goal doesn’t make any difference to the motivation of the team which is often cited as the reason for referring to it as a target.

In all the teams I’ve worked on people are giving their best effort anyway so they can only really have an impact on the velocity by doing one of the following:

1. Working longer hours
2. Cutting corners on quality (by less testing perhaps)
3. Finding a smarter way of working

With the 1st idea we now have an inaccurate representation of how much work we can actually complete in a given time period so our future planning is now made more difficult unless we insist that people work long hours all the time which is a recipe for disaster.

With the 2nd we will eventually suffer when there are more defects later on in our process and we have to come back and re-work those bits of the system.

The 3rd is good but then again I don’t imagine that we would need to have a velocity goal in order to start doing that – we should be working smart by default.

I recently came across an interesting paper titled ‘Goals gone wild‘ which suggests that goal setting can actually be detrimental and that we should be more careful about how we use them:

The use of goal setting can degrade employee performance, shift focus away from important but nonspecified goals, harm interpersonal relationships, corrode organizational culture, and motivate risky and unethical behaviors. We argue that, in many situations, the damaging effects of goal setting outweigh its benefits.

Setting velocity as a goal is a prime example of what the authors call a narrow goal:

With goals, people narrow their focus. This intense focus can blind peopleto important issues that appear unrelated to their goal

As Danilo points out what we really want to do is to get some features that our users want to use into production with as few defects as possible so that they actually work.

Our underlying goal might therefore be to make the lives of our users easier through their use of the website we’re building.

This is much more difficult to measure which is perhaps why the number of points completed becomes the focus when in reality that’s not what anyone cares about. It seems more to signify a lack of trust between the two parties.

In reality I haven’t noticed that people on the teams I’ve worked on pay that much attention to whether velocity is considered a target or not. People just do their job and we pretty much always have the same velocity each week regardless.