Mark Needham

Thoughts on Software Development

Archive for July, 2010

The value of naming things

with 6 comments

Nikhil and I were discussing some of the ideas around Test Driven Development earlier in the week and at one stage I pointed out that I quite liked Bryan Liles’ idea of ‘make it pass or change the message‘.

Bryan suggests that when we have a failing test our next step should be to make that test pass or at least write some code which results in us getting a different error message and hopefully one step closer to making the test pass.

As I described this to Nikhil he pointed out that this is probably what most people are doing anyway and now the technique just has a name.

I think this is probably a fair assessment but then again I find it very useful when people give a name to common techniques/patterns as it makes them much easier to talk about without having to fill in a whole load of context.

For example Joshua Kerievsky has come up with some names to describe incremental refactoring techniques such as parallel change and narrowed change.

Parallel change describes a technique where we want to change a method signature but don’t want to break all the clients of that method by directly changing it.

Instead we create the new method alongside the current one and gradually move the clients to call the new one instead. When they’ve all moved we can delete the original method.

Narrowed change describes a technique where we try to reduce the number of places where we have to make the change we want to make.

It’s much easier to use the vocabulary that Kerievsky has come up with than to have to describe the techniques each time!

However I do think it is possible to go too far with naming things to the point that there are actually so many names that it’s incredibly difficult to remember them all.

xUnit Patterns seems like an example of this to me.

There are an incredible number of patterns described in that book and while they do all describe slightly different scenarios I’m not necessarily convinced that having this many different patterns makes our discussions easier.

Overall though I think having names for common patterns in software development is a good thing and it does add value even though it seems like we’ve just ‘given something a name’.

Written by Mark Needham

July 31st, 2010 at 7:05 am

Kent Beck’s Test Driven Development Screencasts

with 4 comments

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.

Written by Mark Needham

July 28th, 2010 at 10:44 am

Posted in Testing

Tagged with

TDD: Call your shots

with 4 comments

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.

Written by Mark Needham

July 28th, 2010 at 7:39 am

Posted in Testing

Tagged with

TDD: Testing collections

with 5 comments

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!

Written by Mark Needham

July 28th, 2010 at 6:05 am

Posted in Testing

Tagged with

Agile: Developer attendance at showcases

with one comment

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.

Written by Mark Needham

July 27th, 2010 at 7:31 am

Posted in Agile

Tagged with

Technical Debt around release time

with 5 comments

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.

kitchen.jpg

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.

garage.jpg

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.

Written by Mark Needham

July 25th, 2010 at 2:21 pm

Posted in Coding

Tagged with

Bundler: Don’t forget to call ‘source’

without comments

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!

Written by Mark Needham

July 25th, 2010 at 11:48 am

Posted in Ruby

Tagged with ,

TDD, small steps and no need for comments

with 7 comments

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!

Written by Mark Needham

July 23rd, 2010 at 2:52 am

Posted in Testing

Tagged with

The prepared mind vs having context when learning new ideas

with 3 comments

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.

Written by Mark Needham

July 22nd, 2010 at 4:06 am

Feedback, the environment and other people

without comments

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.

Workplace_chart2.jpg

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.

Written by Mark Needham

July 20th, 2010 at 5:30 pm

Posted in Feedback

Tagged with