markhneedham/blog huggingface dataset:
Consistency in the code base and incremental refactoring
Date: 2010-05-05 22:34:56

I wrote a post a while ago about http://www.markhneedham.com/blog/2009/11/04/consistency-in-the-code-base/[keeping consistency in the code base] where I covered some of the reasons that you might want to rewrite parts of a code base and the potential impact of those changes but an interesting side to this discussion which I didn't cover that much but which seems to play a big role is the role of *incremental refactoring*.

In our code base we recently realised that the naming of the fields in some parts of a form don't really make sense and I wanted to start naming new fields with the new naming style and then go back and change the existing ones incrementally when it was a good time to do so.

http://uk.linkedin.com/pub/richard-filippi/1/39/b7[Richard] and https://twitter.com/christianralph[Christian] suggested that this wouldn't be such a good approach because it would make the naming issue even more confusing until all the fields had been renamed.

In order to avoid this problem we had to either go and change every single field to follow the new naming approach immediately or settle on the old names even though they might not be as descriptive.

Since doing the former would involve changing the names of around 15-20 fields across several different objects, in Hibernate mapping code, probably in the database, on HTML forms and in Watin tests we decided not to do that - the project is only for a short amount of time so the investment probably wouldn't be worthwhile.

Although in this case it makes sense not to make the improvement it doesn't strike me as being entirely satisfactory that we would need to make this type of change in a big bang fashion.

From my experience there are often insights into the code or improvements in the ubiquitous language as time goes on and while consistency is of course an important thing in any code base it's not the only thing.

When do we decide that actually gradually moving to a better approach is worth the temporary pain that having this inconsistency will cause?
Agile: Chasing a points total
Date: 2010-05-11 22:28:42

I've previously written about http://www.markhneedham.com/blog/2010/04/07/velocity-as-a-goal/[the danger of using velocity as a goal] but on almost every project I've worked on at some stage we do actually end up chasing a points total.

Something I find quite interesting towards the end of an iteration is that if there is a choice of two stories to pick up then the project manager will nearly always press for one which can be completed within the remaining time in order to get the points total for that iteration higher.

This might even mean that we pick something which is lower priority because we might not finish a higher priority but larger story in time.

This would mean that the points for that card would not be recognised until the next iteration  which would mean that in the current iteration the points total would be lower than expected.

Most of the time this doesn't make a great amount of difference and if it helps take some pressure off and create an impression of 'success' then it seems a reasonable trade off to make.

It does still seem less than ideal to have that type of decision dictated by such a limited metric though.

http://twitter.com/dermotkilroy[Dermot] pointed me to a blog post by Tim Ross titled 'http://timross.wordpress.com/2009/01/19/are-burndowns-evil/[Are burndowns evil?]' where he discusses this in more detail and although I agree with the points Tim makes, it often seems that a product owner ends up with the impression that the project is 'failing' or that we are 'behind' if the velocity 'target' is not being met each iteration.

It seems to take product owners who are new to a more agile approach a bit of time to get used to the idea that achieving the points total isn't the most important thing to focus on and that it's more useful to focus on other things which actually give them value.

I've worked on projects where we've got to the stage where the points total is a side show but it takes quite a bit of time of consistently delivering before we can get that level of trust.
Learnings from my first project of 2010
Date: 2010-05-09 22:17:57

Pat Kua recently wrote http://www.thekua.com/atwork/2010/03/six-years-at-thoughtworks/[a retrospective of his time working at ThoughtWorks] and since I recently finished the first project I've worked on in 2010 I thought it would be interesting to have a look at what I'd learned and observed while working on it.

== "Perfect" code

I've previously believed that driving for the cleanest code with the least duplication and best structured object oriented design was the way to go but on this project we favoured a simpler design which felt quite procedural in comparison to some of the code bases I've worked on.

I initially felt that this would be a problem but the code was still pretty *easy to change* and everyone on the team was able to understand it without any problem so that seemed to outweigh any other concerns.

== There's always a story to be told

The client initially had a very stringent change process where if a developer wanted to implement a new feature they would have to get a change request signed off before they were able to check out a branch of the code base to work on it.

This had been changed before I started working there such that Subversion was being used by the development teams although the code still had to go through quite a stringent change management process before it could be released into production.

We didn't really understand why this was the case because it just seemed to make it more difficult to get anything live.

As it turned out that change process was introduced to get around a problem they'd experienced where code was being manually changed in live. This meant that when there was a bug it was difficult to reproduce it since that version of the code wasn't in source control.

Of course there are other ways to achieve this goal but it was interesting that the approach being taken wasn't completely illogical but had been arrived at through a series of steps which did make sense. Dan North talks of the need to have a http://www.markhneedham.com/blog/2009/04/25/pimp-my-architecture-dan-north/[project shaman] who can *tell the story of why certain decisions were made* and the history behind them and it's always useful to have someone who can do that.

== Theory of constraints

The other interesting thing that I learnt, which is directly linked to the above, is that there is always a constraint within a system and *no matter how much you optimise other parts of your system it won't make any difference to the overall situation*.

In this case no matter how quickly the team was able to code new requirements it didn't make that much difference because there was still quite a big wait at the end pushing the release through the release management system so it could go into production.

We were starting to work on trying to improve this part of the process when I rolled off the project but a lesson for me here is to try and identify where the constraint is in any given system and try and work out how we can address that.
Coding: Paying attention
Date: 2010-05-09 13:04:48

http://twitter.com/jeremydmiller[Jeremy Miller] tweeted earlier in the week about http://twitter.com/jeremydmiller/status/13310240804[the dangers of using an auto mocking container] and how it can encourage sloppy design:

____
That whole "Auto Mocking Containers encourage sloppy design" meme that I blew off last week? Seeing an example in our code.
____

I haven't used an auto mocking container but it seems to me that although that type of tool might be useful for reducing the amount of code we have to write in our tests it also hides the actual problem that we have - an object has too many dependencies.

By hiding the creation of stubs/mocks for those dependencies in our test we are addressing the effect and not the cause i.e. we are http://www.markhneedham.com/blog/2009/08/06/bear-shaving/[bear shaving].

Jeremy followed this up with http://twitter.com/jeremydmiller/status/13310461017[a couple of] http://twitter.com/jeremydmiller/status/13310483817[quite insightful comments]:

____
You know though, I still think it comes down to +++<strong>+++you being responsible for paying attention.
+++</strong>+++
____

____
It's no different than still having to worry about DB optimization even though the ORM is shielding you from the details
____

Another somewhat related situation where I've noticed a similar problem is when we have several tests which require a certain method to be stubbed out and in the interests of reducing duplication we http://www.markhneedham.com/blog/2008/12/19/tdd-mock-expectations-in-setup/[pull that up into a setup method].

While this achieves that goal it also means that there is information that is hidden away from us when we read each of our tests.

One approach that I've seen encouraged is that we should never use a setup method so that we have to create everything we need for our test in the test body.

I quite like this approach because it encourages us to see any problems that we're creating with respect to writing difficult to test code but quite often what ends up happening is we'll http://www.markhneedham.com/blog/2009/09/22/tdd-copying-and-pasting-tests/[copy and paste tests] because there's more code to write for each test.

I'm coming to the conclusion that there's no one approach that will stop us making design mistakes and that as Jeremy says, we need to make sure that we pay attention to what we're doing.
C#: Using a dictionary instead of if statements
Date: 2010-05-30 23:13:25

A problem we had to solve on my current project is how to handle form submission where the user can click on a different button depending whether they want to go to the previous page, save the form or go to the next page.

An imperative approach to this problem might yield code similar to the following:

[source,csharp]
----

public class SomeController
{
	public ActionResult TheAction(string whichButton, UserData userData)
	{
		if(whichButton == "Back")
		{
			// do the back action
		}
		else if(whichButton == "Next")
		{
			// do the next action
		}
		else if(whichButton == "Save")
		{
			// do the save action
		}

		throw Exception("");
	}
}
----

A neat design idea which my colleague http://twitter.com/dermotkilroy[Dermot Kilroy] introduced on our project is the idea of using a dictionary to map to the different actions instead of using if statements.

[source,csharp]
----

public class SomeController
{
	private Dictionary<string, Func<UserData,ActionResult>> handleAction =
		new Dictionary<string, Func<UserData,ActionResult>>
		{ { "Back", SaveAction },
		  { "Next", NextAction },
		  { "Save", SaveAction } };

	public ActionResult TheAction(string whichButton, UserData userData)
	{
		if(handleAction.ContainsKey(whichButton))
		{
			return handleAction[whichButton](userData);
		}

		throw Exception("");
	}

	private ActionResult NextAction(UserData userData)
	{
		// do cool stuff
	}
}
----

It's quite similar in a way to a problem we had on another project where we needed to http://www.markhneedham.com/blog/2010/01/15/c-a-functional-solutional-to-a-modeling-problem/[deal with user inputs and then create an object appropriately].

The way we have to read the code is a bit more indirect than with the original approach since you now need to click through to the individual methods for each action.

On the other hand I like the fact that we don't have if statements all over the place anymore.

* Updated * - updated to take Dhananjay Goyani's comments into account
Functional C#: LINQ vs Method chaining
Date: 2010-02-05 18:06:28

One of the common discussions that I've had with several colleagues when we're making use of some of the higher order functions that can be applied on collections is whether to use the LINQ style syntax or to chain the different methods together.

I tend to prefer the latter approach although when asked the question after http://www.markhneedham.com/blog/2010/01/31/ddd8-mixing-functional-and-object-oriented-approaches-to-programming-in-c/[my talk at Developer Developer Developer] I didn't really have a good answer other than to suggest that it seemed to just be a personal preference thing.

http://www.twitter.com/damianpowell[Damian Marshall] suggested that he *preferred the method chaining approach because it more clearly describes the idea of passing a collection through a pipeline where we can apply different operations to that collection*.

I quite like that explanation and I think my preference for it would have probably been influenced by the fact that when coding in F# we can use the http://www.markhneedham.com/blog/2009/01/06/f-forward-operator/[forward piping operator] to achieve code which reads like this.

For example if we had a list and wanted to get all the even numbers, double them and then add them up we might do this:

[source,ocaml]
----

[1..10] |>
List.filter (fun x -> x % 2 = 0) |>
List.map (fun x -> x * 2) |>
List.fold (fun acc x -> acc + x) 0
----

If I was in C# I'd probably do this:

[source,csharp]
----

Enumerable.Range(1, 10)
.Where(x => x % 2 == 0)
.Select(x => x * 2)
.Sum(x => x);
----

I found it quite difficult to work out what the equivalent LINQ syntax would be because I don't use it but I think something like this would be what you'd need to write to do the same thing:

[source,csharp]
----

from x in Enumerable.Range(1, 10)
where x%2 == 0
select x * 2).Sum(x => x);
----

I'm not sure if there's a way to do the sum within the LINQ statement or whether you need to do it using the method as I have here.

Even just writing this example I found that the way I had to write the LINQ code seemed quite counter intuitive for me with the way that I typically try to solve problems like this.

At least now thanks to Damian I now understand why that is!
C#: A lack of covariance with generics example
Date: 2010-02-20 12:17:16

One of the things I find most confusing when reading about programming languages is the idea of http://codebetter.com/blogs/raymond.lewallen/archive/2006/12/28/Covariance-and-Contravariance.aspx[covariance and contravariance] and while I've previously read that covariance is not possible when using generics in C# I recently came across an example where I saw that this was true.

I came across this problem while looking at how to refactor some code which has been written in an imperative style:

[source,csharp]
----

public interface IFoo
{
	string Bar { get; set; }
}

public class Foo : IFoo
{
	public string Bar { get; set; }
}
----

[source,csharp]
----

private IEnumerable<IFoo> GetMeFoos()
{
    var someStrings = new[] { "mike", "mark" };

    var someFoos = new List<IFoo>();
    foreach (var s in someStrings)
    {
        someFoos.Add(new Foo { Bar = s });
    }
    return someFoos;
}
----

I changed the code to read like so:

[source,csharp]
----

private IEnumerable<IFoo> GetMeFoos()
{
    var someStrings = new[] { "mike", "mark" };
    return someStrings.Select(s => new Foo { Bar = s });
}
----

Which fails with the following compilation error:

[source,text]
----

Error	1	Cannot implicitly convert type 'System.Collections.Generic.IEnumerable<Test.Foo>' to 'System.Collections.Generic.IEnumerable<Test.IFoo>'. An explicit conversion exists (are you missing a cast?)
----

I thought the compiler would infer that I actually wanted a collection of 'IFoo' given that I was returning from the method directly after the call to Select but it doesn't.

As I understand it the reason that we can't downcast an IEnumerable of 'Foo' to an IEnumberable of 'IFoo' is that we would run into problems if we worked of the assumption that our original collection only contained Foos in it later on in our program.

For example it would be possible to add any item which implemented the 'IFoo' interface into the collection even if it wasn't a 'Foo':

[source,csharp]
----

// this code won't compile

List<Foo> foos = new List<Foo>();
// add some foos

List<IFoo> ifoos = foos;

foos.Add(new SomeOtherTypeThatImplementsIFoo());
----

It's not possible to convert 'SomeOtherTypeThatImplementsIFoo' to 'Foo' so we would run ourself into problems.

http://blogs.msdn.com/rmbyers/archive/2005/02/16/375079.aspx[Rick Byers has a post from a few years ago where he explains how this works in more detail] and also points out that covariance of generics is actually supported by the CLR, just not by C#.

In the case I described we can get around the problem by casting 'Foo' to 'IFoo' inside the 'Select':

[source,csharp]
----

private IEnumerable<IFoo> GetMeFoos()
{
    var someStrings = new[] { "mike", "mark" };
    return someStrings.Select(s => (IFoo) new Foo { Bar = s });
}
----
Javascript: Confusing 'call' and 'apply'
Date: 2010-02-28 01:45:49

I wrote a couple of weeks ago about http://www.markhneedham.com/blog/2010/02/12/javascript-passing-functions-around-with-call-and-apply/[using the 'call' and 'apply' functions in Javascript when passing functions around] and while working on http://www.markhneedham.com/blog/2010/02/28/javascript-isolating-browser-specific-code/[our IE6 specific code] I realised that I'd got them mixed up.

We were writing some code to override one of our functions so that we could call the original function and then do something else after that.

The code was roughly like this:

[source,javascript]
----

Foo = {
    bar : function(duck) {
      console.log("bar " + duck.quack());
    }
};
----

The code that I originally wrote to capture the original function, call it and then do the additional behaviour was like this:

[source,javascript]
----

(function() {
  var originalBar = Foo.bar;

   Foo.bar = function(duck) {
        originalBar.call(this, arguments);
        console.log("new bar");
   };
})();
----

When we call the function:

[source,javascript]
----

Foo.bar({ quack : function() { return "quacking" } });
----

We get the following error:

[source,text]
----

TypeError: duck.quack is not a function
----

'arguments' is a local variable in any Javascript function which contains all the arguments passed to the function stored in an array type structure.

However, I had forgotten that when using the 'call' function we need to pass the full list of parameters individually rather than as an array so in this case we would need to pass 'duck' in specifically:

[source,javascript]
----

(function() {
  var originalBar = Foo.bar;

   Foo.bar = function(duck) {
        originalBar.call(this, duck);
        console.log("new bar");
   };
})();
----

Now when we run the function we get the expected behaviour:

[source,javascript]
----

Foo.bar({ quack : function() { return "quacking" } });
----

[source,text]
----

bar quacking
new bar
----

This is where apply comes in handy because apply allows us to pass in 'arguments' as the second parameter and it will send all the arguments of the function that we're inside to the function that we're calling which is exactly what we want in this case.

Using 'apply' we would end up with the following code:

[source,javascript]
----

(function() {
  var originalBar = Foo.bar;

   Foo.bar = function(duck) {
        originalBar.apply(this, arguments);
        console.log("new bar");
   };
})();
----

In this case the function only takes in one argument so there's not much noticeable improvement in the code but when a function takes multiple arguments then using 'apply' is certainly a cleaner approach.
Javascript: Isolating browser specific code
Date: 2010-02-28 00:11:20

One thing we've found on my current project is that despite our best efforts we've still ended up with some javascript code which we only want to run if the user is using Internet Explorer 6 and the question then becomes how to write that code so that it doesn't end up being spread all over the application.

jQuery has some functions which allow you to work out which browser's being used but I've noticed that when we use those you tend to end up with if statements dotted all around the code which isn't so good.

An approach which I was shown recently involves using http://www.quirksmode.org/css/condcom.html[CSS conditionals] to identify when we're using Internet Explorer instead.

We can then include an IE6 specific javascript file like so:

[source,text]
----

<!--[if lt IE 7]>
	<script type="text/javascript" src="/path/to/ie6.js") %>"></script>
<![endif]-->
----

Since we're building an ASP.NET MVC application we include this bit of code in our master page so that it gets picked up by all the web pages.

We've either needed to override existing functions or call the existing function but then do some extra work afterwards as well.

In order to do this we have to make sure that the IE6 specific file is included after our other javascript files since the interpreter will use the last definition of a function that it finds.

Given an existing function defined like so:

[source,javascript]
----

Foo = {
    Bar : function() {
            console.log("original bar call");
    }
};
----

If we want to override this function to do something else we could include the following code in our IE6 specific file:

[source,javascript]
----

Foo.bar = function() {
    console.log("overriding bar call");
}
----

When we call 'Foo.bar()' we'd only see the second 'console.log' statement.

It becomes a bit more interesting if we want to call the original function and then do some other functionality.

We can make use of the http://docs.jquery.com/Types#Proxy_Pattern[proxy pattern] to allow us to do this cleanly.

[source,javascript]
----

Foo = {
    bar : function() {
            console.log("original bar call");
    }
};

(function() {
    var originalBar = Foo.bar;
    Foo.bar = function() {
        originalBar.apply(this, arguments);
        console.log("overriding bar call");
    };
})();
----

If we call 'Foo.bar()' in IE6 we'd now see both of those 'console.log' statements.

The reason that we wrap the reassignment in a function is so that we can hide the 'originalBar' function from the rest of our code. We save 'Foo.bar' in a closure and then override it and delegate calls to the original before logging the extra message.

I quite like this approach although I'm not sure if it's the most intention revealing code because it's not necessarily obvious that the function is being rewritten unless you happen to know about the IE6 only file.

Is there a better way to do this than the approach I've described?
Javascript: File encoding when using string.replace
Date: 2010-02-10 00:02:02

We ran into an interesting problem today when moving some Javascript code which was making use of the 'string.replace' function to strip out the £ sign from some text boxes on a form.

The code we had written was just doing this:

[source,javascript]
----

var textboxValue = $("#fieldId").val().replace(/£/, '');
----

So having realised that we had this code all over the place we decided it would make sense to create a common function that strip the pound sign out. These common functions reside in a different js file to the original code.

[source,javascript]
----

function Common() {
	this.stripPounds = function(value) {
		return value.replace(/£/, '');
	};
}
----

We replace the above code with a call to that instead:

[source,javascript]
----

var textboxValue = new Common().stripPounds($("#fieldId").val());
----

Having done this we realised that the £ sign was no longer being replaced despite the fact that the code was pretty much identical.

After a lot of fiddling around http://twitter.com/gurrie09?utm_source=follow&utm_content=profile&utm_campaign=twitter20080331162631&utm_medium=email[Brian] eventually realised that the js file containing 'Common' was ANSI encoded when we actually needed it to be UTF-8 encoded, probably because we created it in Visual Studio.

As a result the £ sign is presumably being read as some other character which means the replacement doesn't happen anymore.

Converting the file to UTF-8 encoding fixed the problem for us but it's certainly not something I'd have ever thought of.