Following the recommendations of Corey Haines, Michael Guterl, James Martin and Michael Hunger I decided to get Kent Beck's screencasts on Test Driven Development which have been published by the Pragmatic Programmers.

I read Kent's 'Test Driven Development By Example' book a couple of years ago and remember enjoying that so I was intrigued as to what it would be like to see some of those ideas put into practice in real time.

As I expected a lot of Kent's approach wasn't that surprising to me but there were a few things which stood out:

• Kent wrote the code inside the first test and didn't pull that out into its own class until the first test case was working. I've only used this approach in coding dojos when we followed Keith Braithwaite's 'TDD as if you meant it' idea. Kent wasn't as stringent about writing all the code inside the test though – he only did this when he was getting started with the problem.

  The goal seemed to be to keep the feedback loop as tight as possible and this was approach was the easiest way to achieve that when starting out.

• He reminded me of the 'calling the shots' technique when test driving a piece of code. We should predict what's going to happen when we run the test rather than just blindly running it. Kent pointed out that this is a good way for us to learn something – if the test doesn't fail/pass the way that we expect it to then we have a gap in our understanding of how the code works. We can then do something about closing that gap.
• I was quite surprised that Kent copied and pasted part of an existing test almost every time he created a new one – I thought that was just something that we did because we're immensely lazy!

  I'm still unsure about this practice because although Ian Cartwright points out the dangers of doing this it does seem to make for better pairing sessions. The navigator doesn't have to wait twiddling their thumbs while their pair types out what is probably a fairly similar test to one of the others in the same file. Having said that it could be argued that if your tests are that similar then perhaps there's a better way to write them.

  For me the main benefit of not copy/pasting is that it puts us in a mindset where we have to think about the next test that we're going to write. I got the impression that Kent was doing that anyway so it's probably not such a big deal.

• Kent used the 'present tense' in his test names rather than prefixing each test with 'should'. This is an approach I came across when working with Raph at the end of last year.

  To use Esko Luontola's lingo I think the tests follow the specification style as each of them seems to describe a particular behaviour for part of the API.

  I found it interesting that he includes the method name as part of the test name. For some reason I've tried to avoid doing this and often end up with really verbose test names when a more concise name with the method name included would have been way more readable.

  A couple of examples are 'getRetrievesWhatWasPut' and 'getReturnsNullIfKeyNotFound' which both describe the intent of their test clearly and concisely. The code and tests are available to download from the Prag Prog website.

• One thing which I don't think I quite yet grasp is something Kent pointed out in his summary at the end of the 4th screencast. To paraphrase, he suggested that the order in which we write our tests/code can have quite a big impact on the way that the code evolves.

  He described the following algorithm to help find the best order:

  • Write some code
    • erase it
    • write it in a different order

  And repeat.

  I'm not sure if Kent intended for that cycle to be followed just when practicing or if it's something he'd do with real code too. An interesting idea either way and since I haven't ever used that technique I'm intrigued as to how it would impact the way code evolved.

• There were also a few good reminders across all the episodes:
  • Don't parameterise code until you actually need to.
  • Follow the Test – Code – Cleanup cycle.
  • Keep a list of tests to write and cross them off as you go.

Overall it was an interesting series of videos to watch and there were certainly some good reminders and ideas for doing TDD more effectively.

One of the other neat ideas I was reminded of when watching Kent Beck's TDD screencasts is the value of 'calling your shots' i.e. writing a test and then saying what's going to happen when you run that test.

It reminds me of an exercise we used to do in tennis training when I was younger.

The coach would feed the ball to you and just before you hit it you had to say exactly where on the court you were going to place it – cross court/down the line and short/deep.

The point of this exercise is that it's relatively easy to just hit the ball over the net but to have control over exactly where the ball's going to go is way more powerful albeit more difficult.

This applies to TDD as well – it's easy to write a failing test but much more useful to write a failing test which fails in exactly the way that we expect it to.

I've written previously about the value of commentating when pair programming and calling your shots is a really easy way of keeping the conversation flowing in a pair.

I like to ask not only how a test is going to fail but why it's going to fail in that way. I think it's a pretty good way of making sure that you as a pair understand exactly what you're doing. It also slows the pace just enough that you're not coding without thinking about what you're doing.

I quite like Bryan Liles' take on this which he described in a talk at acts_as_conference 2009. Bryan suggests that we first write a test and then either make it green or change the error message that you're getting.

We should know whether or not the test is going to go green or the error message is going to change before we run the test and the idea is that we want to either get the test to pass in one go or at least get a step closer to a passing test.

I've been watching Kent Beck's TDD screencasts and in the 3rd episode he reminded me of a mistake I used to make when I was first learning how to test drive code.

The mistake happens when testing collections and I would write a test which would pass even if the collection had nothing in it.

The code would look something like this:

[Test]
public void SomeTestOfACollection()
{
	var someObject = new Object();
	var aCollection = someObject.Collection;
 
	for(var anItem : aCollection)
	{
		Assert.That(anItem.Value, Is.EqualTo(...));
	}
}

If the collection returned by someObject is empty then the test will still pass because there is no assertion to deal with that situation coming up.

In Kent's example he is using an iterator rather than a collection so he creates a local 'count' variable which he increments inside the for loop and then writes an assertion outside the loop that the 'count' variable has a certain value.

In my example we can just check that the length of the collection is non zero before we iterate through it.

[Test]
public void SomeTestOfACollection()
{
	var someObject = new Object();
	var aCollection = someObject.Collection;
 
	Assert.That(aCollection.Count(), Is.GreaterThan(0));
	for(var anItem : aCollection)
	{
		Assert.That(anItem.Value, Is.EqualTo(...));
	}
}

It's a relatively simple problem to fix but it's certainly one that's caught me out before!

On the majority of the projects that I've worked on at ThoughtWorks we've held a showcase at the end of each iteration to show our client what we've been working on and finished over the previous one or two weeks.

The format of these showcases has been fairly similar each time but the people who attended has tended to vary depending on the situation.

As part of the project being worked on at ThoughtWorks University we've run a showcase at the end of each week which the whole team have been attending.

Toby pointed out that having everyone there didn't seem to be the best use of people's time since the majority of the developers in the room didn't actually have any input during the showcase.

I've often felt the same in that situation although we used a similar approach on a project I worked on last year and it seemed to be quite useful for addressing the human aspect of the project.

The client was able to meet all the people on the team and equally the developers were able to gain some insight into the types of conversations that the analysts were having with the client.

In that particular example we had around 10-15 developers so there was quite a big gathering but on the other projects where we've had the whole team at the showcase there's only been 3 or 4 of us.

On the last project I worked on we took it in turns to go to the showcase. I think it's quite useful to have at least one technical person in a showcase as they're able to give instant feedback on implementation details such as how difficult it will be to change the way a certain piece of functionality works.

A lot of the time we didn't have any input but it was interesting that quite often we'd come out of those showcases with more understanding of what the client was trying to achieve with a specific feature.

If we don't have all the developers in every showcase we do tend to have them all there for the first showcase at least as that tends to be the one where the most stakeholders will be present.

Overall though it's a call to make depending on the situation and the difficulty in judging the value of attending the showcase seems to come about because a lot of the benefits of attending are indirect whereas staying at our desk and coding has a direct benefit to the project.

One of the requirements that the ThoughtWorks University grads have been given on the internal project they're working on is to ensure that they leave the code base in a good state so that the next batch can potentially continue from where they left off.

The application will be deployed on Thursday and this means that a lot of the time this week will be spent refactoring certain areas of the code base rather than only adding new functionality.

When this was suggested Duda pointed out that it's often the case that we might accept a certain amount of technical debt in order to get the application out there.

While he is right and this is quite an unusual situation, we did see a similar situation on the last project I worked on.

On that project there was quite a tight delivery deadline for the first release so we knowingly incurred some technical debt in order to make sure that we met that date.

I've written previously about some of the technical debt that we incurred in that first release and while I think most of the time we made the right call I think there were still some occasions when we thought we were taking on deliberate prudent debt but were actually taking on deliberate imprudent debt.

Luckily it didn't really come back to bite us and in the second release we had a much more relaxed pace and were therefore able to go through the code base and refactor certain parts of it to make it more maintainable.

J.B. Rainsberger has a really cool analogy about refactoring where he talks about cleaning the kitchen and cleaning the garage.

Cleaning the kitchen is what we endeavour to do all the time such that we'll write a bit of code and then clean up after ourselves. Sometimes we don't clean up enough and we end up with a bit of a mess which takes much longer to clean up – i.e. we need to clean the garage.

I think we sometimes drift towards thinking that we don't need to clean the kitchen so often and end up cleaning the garage too often as a result.

This is something that Uncle Bob covered in a post he wrote around a year ago where where he points out that we're more likely to take on technical debt when we didn't need to rather than the other way around.

Finding the right balance between cleaning the kitchen and cleaning the garage seems to be something that comes from the experience of taking either approach too far.

Brian, Tejas and I (well mainly them) have been working on an application to give badges to people based on their GitHub activity at the Yahoo Open Hack Day in Bangalore and we've been making use of Bundler to pull in our dependencies.

Our Gemfile was originally like this:

gem "sinatra", "1.0"
gem "haml", "3.0.13"
gem "activesupport", "3.0.0.beta4", :require => false
gem "tzinfo", "0.3.22"
gem "nokogiri", "1.4.2"
...

For quite a while we were wondering why 'bundle install' wasn't actually resolving anything at all before we RTFM and realised that we needed to call 'source' at the top so that bundler knows where to pull the dependencies from.

Changing the file to look like this solved that problem:

source "http://rubygems.org"
 
gem "sinatra", "1.0"
gem "haml", "3.0.13"
gem "activesupport", "3.0.0.beta4", :require => false
gem "tzinfo", "0.3.22"
gem "nokogiri", "1.4.2"
...

bundler still seemed to have problems resolving 'nokogiri' whereby I was getting various error messages, eventually ending up with this one:

Installing nokogiri (1.4.2) from .gem files at /Users/mneedham/.rvm/gems/ruby-1.8.7-p299/cache with native extensions /Library/Ruby/Site/1.8/rubygems/installer.rb:482:in `build_extensions': ERROR: Failed to build gem native extension. (Gem::Installer::ExtensionBuildError)
 
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby extconf.rb
checking for iconv.h... yes
checking for libxml/parser.h... yes
checking for libxslt/xslt.h... yes
checking for libexslt/exslt.h... yes
checking for gzopen() in -lz... no
-----
zlib is missing.  please visit http://nokogiri.org/tutorials/installing_nokogiri.html for help with installing dependencies.

I had to follow the instructions on their website to get that working which isn't ideal as it means not everything is being resolved through bundler.

I'm not sure if there's a way to get around having to do that so if anyone know a way let me know!

I recently came a blog post written by Matt Ward describing some habits to make you a better coder and while he presented a lot of good ideas I found myself disagreeing with his 2nd tip:

2. Write Your Logic through Comments

When it comes to coding, there are many tenets and ideas I stand by. One of this is that code is 95% logic. Another is that logic doesn’t change when translated from human language into a programming language.

What this means is that if you can write it in code, you can write it in a spoken language like English or French.

…

Instead of just jumping into coding the function, I could step back and write the logic in plain English as comments.

I've tried this approach before and although it can be useful I found that quite frequently I ended up with a more complicated solution than if I'd driven it out with a test first approach.

The advantage of driving the code from examples/tests is that it helps to put you in a mindset where you only need to care about one specific way that a particular object may be used.

As a result we often end up with simpler code than if we'd tried to imagine the whole design of that object up front.

I find it more difficult to keep a lot of code in my head but having just one example is relatively easy. The less code I have to think about at any one time the less mistakes I make.

As we add additional examples which describe different ways that the object may be used I've often found that the code ends up becoming more generalised and we end up with a simpler solution than we might have imagined when we started.

Matt goes on to say:

This way, I can think through the full logic and try to iron out the wrinkles before I actually get into writing the code. I’ve found this to be an incredibly valuable habit that tends to result in fewer bugs.

Using a TDD approach "allows us to describe in code what we want to achieve before we consider how" so the examples that we write provide an executable specification of what we expect the code to do.

I don't have a problem with making mistakes when coding. I make mistakes all the time but having the safety net of tests helps me fix them pretty quickly.

Matt ends this section with the following:

As a bonus, since I will rarely actually delete the comments, writing the logic through comments also means that my code will already be documented, making it easier for others to follow my logic if they ever have to work on it, or even just for myself, if I have to come back to it several months or years down the road!

There are other ways of documenting code which don't involve peppering it with comments. We can write our code in a way that reveals intent such that instead of having this:

// FUNCTION: Lock On Time
// This function will accept two time values, indicating the range through
// which it should return an unlocked status.
 
  // Create a new data object
 
  // Using the data object, get the current time
 
  // IF the current time falls within the range passed to the function
 
    // Return false – meaning that we are currently unlocked
 
  // ELSE
 
    // Return true – meaning that we are currently locked.
 
  // ENDIF
 
// END FUNCTION

We have something closer to this:

public bool ShouldBeLockedBasedOn(DateTime startOfTimeRange, DateTime endOfTimeRange)
{
	var dataObject = CreateDataObject();
	var currentTime = dataObject.CurrentTime;
 
	if(currentTime.IsBetween(startOfTimeRange, endOfTimeRange) 
	{
		return false;
	}
	return true;
}

…where 'IsBetween' would be an extension method on DateTime. We could have that as a private method but I think it reads better this way.

Comments don't tend to be maintained in the same way that code is from my experience so as soon as the code around them changes we'll find that they quickly become misleading rather than helpful.

There are certainly times when it makes sense to put comments in code but using them as a substitute for writing intention revealing code isn't one of those!

I'm currently working as a trainer for ThoughtWorks University (TWU) and the participants have some Industrial Logic e-learning material to work through before they take part in the 6 week training program.

I've been working through the refactoring/code smells courses myself and while I've been finding it really useful, I think this was partly because I've been able to link the material to situations that I've seen in code bases that I've worked on over the past few years.

It would have been interesting to see if I'd have got as much value from going through the material 4 years ago before I started working at ThoughtWorks and didn't have a range of code bases to relate the patterns to.

My thinking is that I would have found it more difficult to see the value of the material and that the approaches described would just have seemed 'obvious' despite the fact that I've made pretty much all of the mistakes that the training looks to address!

About a year ago I wrote a blog post where I described the value of re-reading books and one point which I'd forgotten is that even though it may be hard to relate to some ideas the first time you come across them it's still valuable to read about them anyway.

It helps to prepare your mind for when you eventually come across some code where the idea can be applied and Krishnan pointed out that this was actually part of the feedback received from the current TWU participants.

I think this is probably a good example of a variation of confirmation bias at work in that since we've been prepared to see certain patterns/potential to use different refactorings in code when we do come across those situations in code we're much more likely to see those situations.

Krishnan pointed out that it would still be very useful for the TWU trainers to refer back to the Industrial Logic material when we come across those patterns in the project simulation that we run as part of TWU.

I think this is the most important part of the process as it will help to reinforce the learning.

I'm still curious whether there ever is a time when it makes sense to delay learning about something until we have more context.

I find that when I'm learning about something which goes way over my head I'll often stop doing that and pick something else to look at which I can relate to a bit better.

I try to go back to the original material again later on but what I find often happens is that I'll come across it in the future more by coincidence than design and this time it will make more sense.

Something that I've noticed over the last few years is that when people give feedback to each other there is often an over emphasis on the individual and less attention paid to the environment in which they were working.

I covered this a bit in a blog post I wrote about a year ago titled 'Challenging projects and the Kubler Ross Grief Cycle' which I converted into a presentation that I gave at XP2010 in June. In the presentation I spoke more about the way the environment can impact the way we behave.

One of the points I made was that the environment has a very big impact on the way that people act.

After one particular project that I worked on Lindy, who was running our performance review process, pointed out that everyone who had worked on that project had the exact same feedback and that it said way more about the environment that project was operating in than it did about the individuals.

I'm not quite sure where we draw the line between what an individual can reasonably be said to have control over and what is difficult for them to influence because of the environment. Perhaps there doesn't need to be a line.

In Crucial Confrontations the authors talk about there being three sources of influence – self, others and things – or personal, social and structural as on the diagram on the right!

As I understand it the authors suggest that we start looking at the individual in terms of their own motivation and ability first and then work our way down through the others.

Although this model is intended for conversations where one person is confronting the other for not behaving how they expected in some way, it seems like a reasonable model to follow for general feedback as well.

As assumptions seem to drift into our perceptions of what other people are doing often in an unfavourable way the point of following the model is that it will help draw out these assumptions and help us to see exactly why someone acted the way they did.

A fairly common example is where a tech lead just give instructions to their team to do something without explaining why they want them to do that.

They assume that the team already know why – assuming that the team has the information, context and experience of making this type of decision that they do. The team assumes that the tech lead isn't telling them because he/she just wants them to follow orders.

Neither of these assumptions are particularly useful and it seems much more effective to talk through something with the other person based only on what we've observed so that we can see whether there is something for them to improve or if we need to try and improve the environment in some way.

Easier said than done.

I recently came across an interesting post about pair programming by Paritosh Ranjan where he outlines some of the problems he's experienced with this practice.

While some of the points that he raises are certainly valid I think they're more evidence of pair programming not being done in an effective way rather than a problem with the idea in itself.

To take one example:

Generally people don’t think a lot while pair programming as the person who wants to think about the pros and cons will be considered inefficient (as he will slow down the coding speed). So, generally people show fake confidence on the effectiveness of the proposed solution.

While it's certainly possible to end up with this scenario, I've also taken part in pairing sessions where we were able to think through a problem and come up with a design much more effectively than either of us would have been able to alone.

Something that I've noticed that I do too frequently is seeing a practice being executed in a sub optimal way and coming to the conclusion that there's a problem with the practice itself.

For example I wrote a post about a month ago outlining some of the problems that we'd been having with retrospectives on some of the projects that I've been working on and at one stage towards the beginning of the year I was wondering whether there was even a lot of value in having a retrospective.

What was pointed out in the comments of that post and subsequently on threads on our internal mailing list is that to keep people engaged we should vary the way we run the retrospective rather than running the same format every time.

I'm told Esther Derby and Diana Larsen's 'Agile Retrospectives' has a lot of ideas on how to run retrospectives more effectively but I haven't quite got around to reading it just yet.

Another practice which I've been doubting is the Iteration Kick Off meeting which often seems to be a session where we read through every single story that's coming up while the majority of the people in the room are completely disengaged. These meetings often dragged on for an hour or more.

Discussing this with a business analyst colleague last week he pointed out that he runs these meetings in a completely different way. His goal is to communicate what functionality is coming up so that any coding decisions can be made with that in mind.

That communication doesn't necessarily have to be in a meeting, it could just be a conversation had over lunch. If it is a meeting then he'd look to keep it short and to the point.

The underlying trend behind all of these is that we saw a practice being done in a sub optimal way and came to the conclusion that there must be a problem with the practice.

I'm coming to the conclusion that it would be more effective to look at the goal the practice is trying to achieve first and see if we can change the way we're executing the practice to achieve what we want.

If not then perhaps the practice is at fault and we need to look for another way to achieve our goal.

Following on from my post about the value we found in acceptance tests on our project when doing a large scale refactoring I had an interesting discussion with Jak Charlton and Ben Hall about deleting unit tests when they're no longer needed.

The following is part of our discussion:

Ben:

@JakCharlton @markhneedham a lot (not all) of the unit tests created can be deleted once the acceptance tests are passing…

Jak:

@Ben_Hall @markhneedham yep I agree, but that isn't what TDD really advocates – its a balance, unit tests work well in some places

Me:

@Ben_Hall @JakCharlton gotta be courageous to do that.Its like you're ripping away the safety net. Even if it might be an illusion of safety

Jak:

@markhneedham one of the XP principles … Courage

While Jak and Ben are probably right I do find myself feeling way more anxious about deleting test code than I would deleting production code.

I think that this is mostly because when I delete production code we usually have some tests around that code so there is a degree of safety in doing so.

Deleting tests seems a bit more risky because there's much more judgement involved in working out whether we're removing the safety net that we created by writing those tests in the first place.

The diagram on the right hand side shows the way I see the various safety nets that we create to protect us from making breaking changes in production code.

In this case it might seem that a unit test is providing safety but it's now an illusion of safety and in actual fact it's barely protecting us at all.

I find it much easier to delete a unit test if it's an obvious duplicate or if we've completely changed the way a piece of code works such that the test will never pass again anyway…

..and I find it more difficult to judge when we end up with tests which overlap while testing similar bits of functionality.

Do others feel like this as well or am I just being overly paranoid?

Either way does anyone have any approaches that give you ore confidence that you're not deleting something that will come back to haunt you later?

One of the more interesting presentations doing the rounds on twitter and on our internal mailing lists is the following one by Dan Pink titled 'Drive – The surprising truth about what motivates us'.

This topic generally interests me anyway but it's quite intriguing that the research Dan has gathered support for what I imagine many people intrinsically knew.

Incentives

The presentation dispels the myth that money always works as a motivator for getting people to do what we want them to do. Rather its value is more noticeable as an anti de-motivator – Pink suggests that organisations need to pay people enough so that money is no longer an issue.

He goes on to detail research which shows that money doesn't work as a motivator when a task requires even rudimentary cognitive skill which suggests it wouldn't be all that effective in a software development context.

Following on with this logic Pink suggests that before he did his research he would have thought that if you wanted to get innovation in an organisation then that would best be achieved by giving out an innovation bonus. He now suggests this wouldn't be effective.

We had an interesting example of this recently where the ThoughtWorks UK and Australia offices tried to run an iPad App competition with the prize of an iPad for the winning entry.

This worked fine in Australia but didn't at all in the UK. Since the 'incentive' was the same in both cases I'm inclined to believe that the reason it worked better in Australia was due to the fact that the guys there managed to create a spirit of competition between the Melbourne & Sydney offices and between the participants.

How do we get better performance?

Pink suggests that there are three main factors which lead to better performance & personal satisfaction – autonomy, mastery and purpose – and I think that to an extent we can get all of these with the agile approach to software development.

Autonomy

Pink suggests that people like to be self directed and direct their own lives and he gives the example of Atlassian's Fedex days as an example of developers being given the freedom to do whatever they want for 24 hours and coming up with some really useful products at the end of it.

I think we have autonomy to an extent on software projects. We might not have the ability to choose exactly what problem we're solving for our customer but we do mostly have the ability to choose how we're going to solve it.

We can choose how we're going to design the solution, discussing various trade offs with our customer if there's more than one way to solve it…

Mastery

Pink points out that many people play musical instruments at the weekend even though they have little chance of ever earning money from doing so and he suggests that the reason for this is its fun and we have an urge to get better.

Software development is almost a perfect fit for mastery because there are so many different areas for improvement no matter how good you are.

Corey Haines has been pushing the idea of 'Learn To Type Week' which is just one example of this.

I thought I was pretty good at touch typing but after trying out the different exercises he's been linking to I realise that there are still areas in which I can improve upon and it's quite fun trying out the exercises and trying to get better.

Apart from that there are code katas, code koans, new languages and many other ways in which we can improve ourselves.

Purpose

Pink describes purpose as "what gets you up in the morning racing to go to work" and suggests that we need something more than just making profit.

I mostly don't feel that I'm actually "going to work" on the projects I've been on because the majority of the time the other two factors are being met and I have the opportunity to work with passionate people who want to deliver high quality software together.

I'm not sure if that quite gets to the essence of purpose but it certainly doesn't feel that what I'm working on is pointless – we're building something which helps solve a problem for our customer and that seems like a valuable thing to do to me.

Overall

I found this presentation really interesting and the way it's presented with the cartoons is really cool as well.

I haven't yet read Dan Pink's book 'Drive' which presumably expands upon this talk but I've read 'A Whole New Mind' which was interesting reading so I'm sure I'll read this one at some stage.

A couple of months ago I wrote about tacit programming with respect to F#, a term which I first came across while reading about the J programming language.

There's a good introduction to tacit programming on the J website which shows the evolution of a function which originally has several local variables into a state where it has none at all.

I've been having a go at writing Roy Osherove's TDD Kata in J and while I haven't got very far yet I saw a good opportunity to move the code I've written so far into a more tacit style.

From my understanding two of the ways that we can drive towards a tacit style are by removing explicitly passed arguments and variables from our code.

Remove explicitly passed arguments

The second part of the kata requires us to allow new lines separating numbers as well as commas so with the help of the guys on the J mailing list I wrote a function which converts all new lines characters into commas:

replaceNewLines =: 3 : 0
	y rplc ('\n';',')
)

'rplc' takes an input as its left hand argument and a 2 column boxed matrix as its right hand argument.

In this case the left hand argument is 'y' which gets passed to 'replaceNewLines' and the boxed matrix contains '\n' and ','. The left item in the matrix gets replace by the right item.

We want to get to the point where we don't have to explicitly pass y – it should just be inferred from the function definition.

As is the case in F# it seems like if we want to do this then we need to have the inferred value (i.e. y) passing as the last argument to a function which in this case means that it needs to be passed as the right hand argument.

'rplc' is actually the same as another function 'stringreplace' which takes in the arguments the other way around which is exactly what we need.

replaceNewLines =: 3 : 0
	('\n';',') stringreplace y
)

The next step is to apply the left hand argument of 'stringreplace' but infer the right hand argument.

We can use the bond conjunction (&) to do this. The bond conjunction creates a new function (or verb in J speak) which has partially applied the left argument to the verb passed as the right hand argument.

replaceNewLines =:  ('\n' ; ',') & stringreplace

'replaceNewLines' represents the partial application of 'stringReplace'. We can now pass a string to 'replaceNewLines' and it will replace the new lines characters with commas.

Remove local variables

My 'add' function currently looks like this:

1
2
3
4

add =: 3 : 0
	newY =. replaceNewLines y
 	+/ ". newY
 )

We want to try and drive 'add' to the point where it's just a composition of different functions.

At the moment on line 3 we have '+/' which can be used to get the sum of a list of numbers.

e.g.

+/ 1 2 3
> 6

We also have '".' which converts a character array into numbers.

e.g.

". '1,2,3'
> 1 2 3

In order to compose our 3 functions together without explicitly passing in 'y' or 'newY' we need to make use of atop conjunction (@) which "combines two verbs into a derived verb that applies the right verb to its argument and then applies the left verb to that result."

It works in the same way as Haskell's function composition operator i.e. it applies the functions starting with the one furthest right.

We end up with this:

add =: +/ @ ". @ replaceNewLines

or if we want to inline the whole thing:

add =:  +/ @ ". @ ( ('\n' ; ',') & stringreplace )

Overall

I'm still getting the hang of this language – it's taking much longer than with any other languages I've played with – but so far the ideas I've come across are very interesting and it seems like it massively reduces the amount of code required to solve certain types of problems.

I've read a couple of Seth Godin's other books – Tribes and The Dip – and found them fairly readable so I figured his latest offering, Linchpin, would probably be worth a read too.

This is the first book that I've read on the iPad's Kindle application and it was a reasonably good reading experience – I particularly like the fact that you can make notes and highlight certain parts of the text.

It's also possible to see which areas of the book other Kindle users have highlighted and you can see your highlights/notes via the Kindle website.

The Review

The sub-title of the book: 'Are you indispensable? How to drive your career and create a remarkable future' didn't really appeal to me all that much but I've found that these types of things are often just for provocation and don't necessarily detract from the message.

As with the other Godin books I've read, he spends a lot of time making his original point and in this one it felt like I'd already agreed with what he was saying for at least 50 pages before we moved onto something else.

Despite that I think there were some good points made in the book. These were some of the more interesting ones for me:

• One of my favourite quotes from the book is the following about fire:
  

  Fire is hot. That’s what it does. If you get burned by fire, you can be annoyed at yourself, but being angry at the fire doesn’t do you much good. And trying to teach the fire a lesson so it won’t be hot next time is certainly not time well spent.

  Our inclination is to give fire a pass, because it’s not human. But human beings are similar, in that they’re not going to change any time soon either.

  One of the things I've noticed over time is that it's very unlikely that the core way a person behaves is likely to change regardless of the feedback that they get from other people.

  Pat touches on this in a post where he points out that we need to be prepared for feedback to not be accepted.

  I don't think this means we should stop giving feedback to people if we think it will help them be more effective but it does seem useful to keep in mind and help us avoid frustration when we can't change a person to behave in the way we'd like them to.

• Godin makes an interesting point about the value of the work that we do:
  

  A day’s work for a day’s pay (work <=> pay). I hate this approach to life. It cheapens us.

  This is exactly the consulting model – billing by the hour or by the day – and although I've come across a couple of alternative approaches I'm not sure that they work better than this model.

  Value based pricing is something which I've read about but it seems to me that there needs to be a certain degree of trust between the two parties for that to work out. The other is risk/reward pricing and I've heard good/bad stories about this approach.

  It seems to me that we'd need to have a situation where both parties were really involved in the long term outcome of the project/system so if one party is only invested for a short % of this time then it's going to be difficult to make it work.

• Shipping is another area he touches on in a way that makes sense to me:
  

  I think the discipline of shipping is essential in the long-term path to becoming indispensable.

  The only purpose of starting is to finish, and while the projects we do are never really finished, they must ship. Shipping means hitting the publish button on your blog, showing a presentation to the sales team, answering the phone, selling the muffins, sending out your references. Shipping is the collision between your work and the outside world.

  While this is just generally applicable, in software terms this would be about the sort of thing that my colleagues Rolf Russell & Andy Duncan cover in their talk 'Rapid and Reliable Releases'.

  I also had an interesting discussion with Jon Spalding about the importance of just getting something out there with respect to the 'Invisible Hand' browser plugin that he's currently working on. Jon pointed out that it's often best to ship and then rollback if there are problems rather than spending a lot of time trying to make sure something is perfect before shipping.

• Godin spends a lot of time pointing out how important human interactions and relationships are and I think this is something that is very important for software delivery teams. One of the most revealing quotes is this:
  

  You might be parroting the words from that negotiation book or the public-speaking training you went to, but every smart person you encounter knows that you’re winging it or putting us on.

  Virtually all of us make our living engaging directly with other people. When the interactions are genuine and transparent, they usually work. When they are artificial or manipulative, they fail.

  I attended a consulting training course when I first started working at ThoughtWorks 4 years ago and I've always found it impossible to actually use any of the ideas because it doesn't feel natural. It's interesting that Godin points out why this is!

Overall this book feels to me like a more general version of Chad Fowler's 'The Passionate Programmer' which is probably a more applicable book for software developers.

This one is still an interesting read although it primarily points out stuff that you probably already knew in a very clear and obvious way.

A couple of weeks ago Dermot and I showcased a piece of functionality that we'd been working on – notably hiding some options in a drop down list.

We showcased this piece of functionality to the rest of the team in Firefox and it all worked correctly.

Our business analyst, who was also acting as QA, then had a look at the story in Internet Explorer 6 and we promptly realised that the way we'd solved the problem didn't actually work in IE6.

In retrospect we should have showcased the story in IE6 in order to shorten the feedback cycle but if we take that logic even further than it's clear that we should be running our application in IE6 frequently as we're developing functionality.

It's a dilemma that we've faced on nearly every project I've worked on recently.

We know in the back of our minds that we need to make it work on Internet Explorer 6 but because of Firebug the speed of development is siginifcantly quicker if we use Firefox.

It's almost as if we're trading off the longer term safety we would have if we use IE6 all the time for the quick feedback cycles we get from the Firebug console/CSS editor when we're fiddling around with Javascript and CSS.

The way that we're working at the moment is to continue using Firefox for local development but trying to make sure that we test and showcase in IE6.

It's not a foolproof approach, as can be seen by the example I gave at the beginning of this post, so I'd be interested if anyone has any clever ideas for dealing with the situation where we have a requirement to make our application IE6 compatible.

On the project that I've been working on over the past few months one of the key benefits of the application was its ability to perform various calculations based on user input.

In order to check that these calculators are producing the correct outputs we created a series of acceptance tests that ran directly against one of the objects in the system.

We did this by defining the inputs and expected outputs for each scenario in an excel spreadsheet which we converted into a CSV file before reading that into an NUnit test.

It looked roughly like this:

We found that testing the calculations like this gave us a quicker feedback cycle than testing them from UI tests both in terms of the time taken to run the tests and the fact that we were able to narrow in on problematic areas of the code more quickly.

As I mentioned on a previous post we've been trying to move the creation of the calculators away from the 'CalculatorProvider' and 'CalculatorFactory' so that they're all created in one place based on a DSL which describes the data required to initialise a calculator.

In order to introduce this DSL into the code base these acceptance tests acted as our safety net as we pulled out the existing code and replaced it with the new DSL.

We had to completely rewrite the 'CalculationService' unit tests so those unit tests didn't provide us much protection while we made the changes I described above.

The acceptance tests, on the other hand, were invaluable and saved us from incorrectly changing the code even when we were certain we'd taken such small steps along the way that we couldn't possibly have made a mistake.

This is certainly an approach I'd use again in a similar situation although it could probably be improved my removing the step where we convert the data from the spreadsheet to CSV file.

One thing that we tried to avoid on the project that I've been working on is making use of C# expressions trees in production code.

We found that the areas of the code where we compiled these expressions trees frequently showed up as being the least performant areas of the code base when run through a performance profiler.

In a discussion about the ways to improve the performance of an application Christian pointed out that once we've identified the area for improvement there are two ways to do this:

• Do it less
• Find another way to do it

We were able to find another way to achieve what we wanted without using them and we favoured this approach because it was much easier to do,

An alternative would have been to cache the compilation of the expression so that it wouldn't happen every single time a request passed through that code path.

A lot of the time it seems like it's actually possible to just do something less frequently rather than changing our approach…

For example:

• Caching a HTTP response so that not every request has to go all the way to the server.
• Grouping together database inserts into a bulk query rather than executing each one individually.

… and most of the time this would probably be a simpler way to solve our problem.

I quite like this heuristic for looking at performance problems but I haven't done a lot of work in this area so I'd be interested in hearing other approaches as well.

Yesterday evening I decided to try and upgrade the Ruby installation on my Mac from 1.8.7 to 1.9.2 and went on the yak shaving mission which is doing just that.

RVM seems to be the way to install Ruby these days so I started off by installing that with the following command from the terminal:

bash < <( curl http://rvm.beginrescueend.com/releases/rvm-install-head )

That bit worked fine for me but there are further instructions on the RVM website if that doesn't work.

My colleague David Santoro pointed me to a post on ASCIIcasts detailing the various steps to follow to get Ruby installed.

Unfortunately my first attempt…

rvm install 1.9.2

…resulted in the following error in the log file:

yaml.h is missing. Please install libyaml.
readline.c: In function ‘username_completion_proc_call’:
readline.c:1292: error: ‘username_completion_function’ undeclared (first use in this function)
readline.c:1292: error: (Each undeclared identifier is reported only once
readline.c:1292: error: for each function it appears in.)
make[1]: *** [readline.o] Error 1
make: *** [mkmain.sh] Error 1

I thought that perhaps 'libyaml' was the problem but Michael Guterl pointed me to a post on the RVM mailing list which suggests this was a red herring and that the real problem was 'readline'.

That led me back to a post on the RVM website which explains how to install 'readline' and then tell RVM to use that version of readline when installing Ruby.

I tried that and then ran the following command as suggested on Mark Turner's blog post:

rvm install 1.9.2-head -C --enable-shared,--with-readline-dir=/opt/local,--build=x86_64-apple-darwin10

That resulted in this error:

ld: in /usr/local/lib/libxml2.2.dylib, file was built for i386 which is not the architecture being linked (x86_64)
collect2: ld returned 1 exit status
make[1]: *** [../../.ext/x86_64-darwin10/tcltklib.bundle] Error 1
make: *** [mkmain.sh] Error 1

Michael pointed out that I needed to recompile 'libxml2.2′ to run on a 64 bit O/S as I'm running Snow Leopard.

I hadn't previously used the 'file' function which allows you to see which architecture a file has been compiled for.

e.g.

file /usr/local/lib/libxml2.2.dylib
 
/usr/local/lib/libxml2.2.dylib: Mach-O dynamically linked shared library i386

I had to recompile 'libxml2.2′ to run on a 64 bit O/S which I did by downloading the distribution from the xmlsoft website and then running the following commands:

tar xzvf libxml2-2.7.3.tar.gz 
cd libxml2-2.7.3
./configure --with-python=/System/Library/Frameworks/Python.framework/Versions/2.3/
make
sudo make install

Re-running RVM Ruby installation command I then had this error instead:

tcltklib.c:9539: warning: implicit conversion shortens 64-bit value into a 32-bit value
ld: in /usr/local/lib/libsqlite3.dylib, file was built for i386 which is not the architecture being linked (x86_64)
collect2: ld returned 1 exit status
make[1]: *** [../../.ext/x86_64-darwin10/tcltklib.bundle] Error 1
make: *** [mkmain.sh] Error 1

I downloaded the sqlite3 distribution and having untarred the file ran the following commands as detailed on this post:

CFLAGS='-arch i686 -arch x86_64' LDFLAGS='-arch i686 -arch x86_64' 
./configure --disable-dependency-tracking
make
sudo make install

Next I needed to recompiled 'libxslt' which I downloaded from the xmlsoft website as well before untarring it and running the following:

./configure
make
sudo make install

Having done that I re-ran the RVM Ruby installation command:

rvm install 1.9.2-head -C --enable-shared,--with-readline-dir=/opt/local,--build=x86_64-apple-darwin10

And it finally worked!

The magnificent yak is borrowed under the Creative Commons Licence from LiminalMike's Flickr Stream.

On an internal mailing list my colleague David Pattinson recently described a feedback approach he'd used on a project where everyone on the team went into a room and they took turns giving direct feedback to each person.

Since we were finishing the project that we've been working on for the past few months, Christian, Dermot and I decided to give it a try last week.

One thing to note is that this feedback wasn't linked to any performance review, it was just between the 3 of us to allow us to find ways that we can be more effective on projects that we work on in the future.

Much like David I found this approach to feedback to be the most useful that I've seen in nearly 4 years working at ThoughtWorks.

We took it in turns to receive feedback from the other two guys and each person first explained what they wanted the feedback to focus on.

I've participated in face to face feedback before but what I liked better about this approach was that someone could make an observation about something that you'd done and then that became a discussion point between the three of us.

In general it seems to promote a more conversational style of feedback than often seems to happen when it's just one on one.

I think it was really good being able to get two opinions on each behaviour as people often have different takes on the same situation. Taking both viewpoints together along with your own seemed to make it easier to narrow in on the behaviour and see how it could be improved.

When giving feedback it was useful to have someone else doing so at the same time as it helped remind me about things that I'd forgotten about.

I still need to improve the way I give and receive feedback – Pat Kua details a series of tips for extracting behaviours from the actual feedback that people give and has several other posts on the topic. This is the best resource that I've come across but I'd be interested in knowing of any others.

The key thing that I've noticed when giving feedback is to only point out your observation and the impact it had on you rather than making assumptions about why the person might have done that – you're nearly always wrong!

Overall though I found the group feedback approach to be useful and it's something I'll look to encourage on projects I work on in the future although I'm unsure how well it would scale in a larger team.

Photo taken from AmyZZZ1′s Flickr stream under the Creative Commons licence.

I recently watched a presentation given by Joshua Kerievsky from the Lean Software & Systems conference titled 'The Limited Red Society' in which describes an approach to refactoring where we try to minimise the amount of time that the code is in a 'red' state.

This means that the code should be compiling and the tests green for as much of this time as possible .

I think it's very important to follow these principles in order to successfully refactor code on a project team and it's an approach that my colleague Dave Cameron first introduced me to when we worked together last year.

These are some of my observations and thoughts on the talk:

• Kerievsky talks about parallel change which is where we want to make some changes to a bit of code and instead of changing it directly we create a parallel implementation and then gradually change the clients of that code to use the new approach.

  An example of this which I wrote about last year was when we wanted to move the creation of objects from using object initializer to the builder pattern. Instead of doing it all in one go we had both approaches in the code base at the same time and gradually moved all the existing code to use the new approach. We also tried to use this approach to change the API of one of the main objects in the CC.NET code in a dojo last year.

  Kent Beck talks about a similar approach in his QCon talk titled 'Responsive Design' from November 2008.

• One interesting point that Josh made in the Q&A session is that there may be times when we don't necessarily want to go straight for parallel change – it might be easier to use a narrowed change approach first.

  With narrowed change we would first look to reduce the number of places where we have to make the change we want to make.

  For example if we want to change an object to internally use a list instead of an array we could first isolate the places where we add to or retrieve from the data structure into methods. We would then call those methods instead of accessing the data structure directly.

  This way we can reduce the number of places we need to change when we eventually change the array to a list.

  I haven't used this approach before but will look to do so in future.

• There was a discussion about small steps and big leaps at the end where one of the attendees pointed out that it often takes much longer to take a small steps approach rather than just taking one big leap.

  Josh pointed out that the appropriate choice depends on the risk involved in the refactoring situation – if it's low risk then perhaps it does make sense to just change the code in one go. However, an additional advantage of the small steps approach is that it makes it much easier to do a graceful retreat if the refactoring gets out of hand and we end up yak shaving.

Although I already knew some of the approaches shown in this video it's always interesting to see how experienced practitioners put them to use and there were a couple of new ideas that I hadn't come across before.

I particularly liked the fact that there was a 20 minute Q&A section at the end. The discussion is quite interesting to listen to.