Mark Needham

One of the key ideas that I have learnt from my readings of The Toyota Way and Taaichi Ohno’s Workplace Management is that we should strive not to pass defects through the system to the next process, which you should consider to be your customer.

As a developer the next process for each story is the testing phase where the testers will (amongst other things) run through the acceptance criteria and then do some exploratory testing for scenarios which weren’t explicitly part of the acceptance criteria.

The question is how far should we go down this route and what exactly is a defect using this terminology – if a tester finds a bug which was listed in the acceptance criteria then I think it’s reasonable enough to suggest that the developer has moved a defect onto the next stage.

But what about if that bug only appears on one particular browser and that’s one that the developer didn’t test against but the tester did. Clearly automating tests against different browsers can help solve this problem but there are still some types of tests (particularly ones requiring visual verification) where it’s much more grey.

We want developers to write code with as few defects as possible but at the end of the day testers are much better at using software in ways that is likely to expose defects that developers wouldn’t even think about and I think this is definitely a good thing.

My current thinking around this area is that a defect is something which was covered by the acceptance criteria or something which has been previously exposed by exploratory testing and reappears.

Anything else is a normal part of the process.

While talking through my understanding of the Select method which can be applied to collections in C# with a colleague, it became clear that C# doesn’t seem to use the same names for these type of operations as are used in the world of functional programming.

Coincidentally on the same day I came across Bill Six’s post about using functional collection parameters in Ruby, so I thought I’d see what the equivalent operations are in C#.

Map

Map evaluates a high order function on all the elements in a collection and then returns a new collection containing the results of the function evaluation.

In C# we can use the ‘Select’ method. For example, to capitalise all the items in a list:

1
2

var someValues = new List<string> {"mark", "sydney", "sunny"};
var upperCaseValues = someValues.Select(item => item.ToUpper());

The responsibility for iterating the collection has been taken away from me and I can just focus on what I want to do with the collection rather than worrying too much about the details. A more declarative approach.

If I want to see the results of that operation I just do the following:

1

upperCaseValues.ForEach(Console.WriteLine);

MARK
SYDNEY
SUNNY

Filter

Filter applies a predicate against all of the elements in a collection and then returns a collection of elements which matched the predicate.

Conveniently there is actually a built in delegate called ‘Predicate’ which when combined with the ‘FindAll’ method can be used to solve this problem.

1
2
3

var someValues = new List<string> {"mark", "sydney", "sunny"};
var valuesWithSIn = someValues.FindAll(item => item.Contains("s"));
valuesWithSIn.ForEach(Console.WriteLine);

sydney 
sunny

If we just want the first value in the collection that matches the predicate we would use the ‘Find’ method instead:

1
2
3

var someValues = new List<string> {"mark", "sydney", "sunny"};
var valueWithSIn = someValues.Find(item => item.Contains("s"));
Console.WriteLine(valueWithSIn);

sydney

Reduce

Reduce applies a high order function against all the elements in a collection and then returns a single result.

We can use the ‘Aggregate’ method to achieve this:

1
2
3

var someValues = new List<string> {"mark", "sydney", "sunny"};
var valuesConcatenated = someValues.Aggregate("",(accumulator, item) => accumulator + item);
Console.WriteLine(valuesConcatenated);

marksydneysunny

The “” passed in as the first parameter to ‘Aggregate’ is the initial value for the accumulator.

Combining expressions

As with Ruby we can chain these expressions together to return even greater results.

For example, to get concatenate all the items which contain an s we would do the following:

1
2
3
4

var someValues = new List<string> {"mark", "sydney", "sunny"};
var valuesConcatenated = someValues.FindAll(item => item.Contains("s"))
                                   .Aggregate("",(accumulator, item) => accumulator + item);
Console.WriteLine(valuesConcatenated);

sydneysunny

Overall

I really like having this high order functions available to us – it has taken away the need to write some of the most boring code that we used to have to write and makes our code more concise and easier to read.

My colleague Chris Johnston recently posted about his experiences with pair programming, eventually ending up asking for other people’s experiences in doing so.

Several of my colleagues have replied citing some of their best practices and I have previously posted about what I think makes pair programming more effective so for this post I thought I’d try and also identify the approaches that make pair programming work for me.

Keep it productive

This is the area which has been written about the most, perhaps because it’s the most visible to others.

Knowing your IDE and its’ shortcuts, taking lots of small steps, using TDD, ensuring that both people get keyboard time, keeping a list of tiny tasks, and so on are all ways that we can work more effectively as a pair.

In addition, it’s also important not to spend your time arguing because your pair doesn’t do exactly what you want them to do. Cam Swords nails this in his comment on Dahlia’s blog

- let your pair do what they want
the most senior consultants/developers dont always get what they want. If you go into pairing expecting this, you wont enjoy the experience.

This is valid even if the issue is something that you think is really important. For example if you love tests, but your pair doesnt want to write them. Why not try not writing tests? They will soon want to write tests when everything starts breaking and they will respect you more for allowing them to learn the mistake themselves.

One idea I learnt from reading Steve Pavlina’s blog, also touched on here, was that whatever we want to happen, we should do more of ourself and it will naturally happen. Therefore if we feel our pair is not listening to our ideas we should spend even more time ensuring that we are actually listening to them – I don’t always follow this advice myself but when I do it does seem to work.

Stepping one level up, it’s also useful to ensure we rotate pairs frequently to ensure that a pair doesn’t become stale or get sick of the sight of each other! I don’t have the data to back this up but I think at most we should be looking to rotate at least every few days if not more frequently.

Keep it fun

I know the majority of the time we are pair programming in a work situation and although maybe we take a slight short term productivity hit by having this element of fun, I think working in this type of environment is more conducive to success in the longer run.

If I enjoy the work I do I’m likely to be more passionate about it, learn more about it and therefore become better at doing it.

Some examples of ways to create a fun atmosphere when pairing could mean joking about stupid variable names that you have come up with or having a side conversation that you pick up when there is a lull in proceedings – when the build is running for example.

Having a fairly laid back approach and not taking the whole thing too seriously is a useful approach to take. Being able to joke about the bad code that you’ve written and then working out ways to improve it with your pair can be a fun learning experience when done in a laid back way with a pair that you trust.

Clearly there is a bit of a balance to strike here so that we do actually do some work – although it is sometimes fun to include other pairs in our banter, doing so all the time doesn’t work so well from my experience and ruins their train of thought.

Keep learning

Although a lot of the value in pairing comes from the fact that we are spreading knowledge around the team and having two eyes looking at a problem tends to result in better quality solution achieved more quickly, I think teaching our pair new things is also very important.

One of my favourite phrases that I have heard with regards to judging the success of a Project Manager is to look at each of the members of their team and see if they are better for having done the project than they were before. If they are then the Project Manager has succeeded from a people point of view.

Maybe we can apply the same logic when pairing – in every pair programming session always look to teach your pair something that they don’t know. It doesn’t even have to be something completely related to the story being worked on although it’s even more effective if that’s the case.

It could be as simple as pointing out some books or blogs you have read recently around an area of technology which you know is of interest to the other person. Sharing domain knowledge in areas which are maybe not immediately applicable is another way that we can help share knowledge with our pairs.

Never Settle

I’m sure there are other subtle gains we get out of pairing that I haven’t thought of, but I think it’s important that we constantly look for ways to improve the way we pair.

For example, I recently came across the idea of screen pairing from Brian Marick’s blog – an idea that he learnt when pairing with Corey Haines on Corey’s pair programming tour across the US.

The idea is that both pairs sit at a machine opposite each other but both see the same screen by using iChat. The thinking behind this approach is that you can more easily see your pair’s body language and that it is generally more comfortable than having both people sitting side by side. Certainly an idea to try out in a Coding Dojo type situation.

I’m sure we haven’t yet learnt all the tricks of mastering this skill so keeping an open mind is probably the most approach at this stage.

Overall

I still have a lot to learn about pair programming and these are just some of my observations so far. Coming from someone who is very much pro pair programming, we want to try and reach the stage where we can prove that there is more value to the business from having our developers pair than by having them working individually.

We can only do this by continually evaluating what we are doing and looking for ways to improve it.

One of my favourite things introduced into C# recently is the new ForEach method which can be applied to (apparently only!) lists.

Last week we had a situation where we wanted to make use of the ForEach method on an IDictionary which we were using to store a collection of Selenium clients.

1

IDictionary<string, ISelenium> seleniumClients = new Dictionary<string, ISelenium>();

We wanted to write a piece of code to exit all of the clients when our tests had completed. We thought the following would do the trick:

1

seleniumClients.Values.ForEach(client => client.Stop());

The problem is that code doesn’t actually compile!

‘seleniumClients.Values’ returns an ICollection which extends IEnumerable so we thought ForEach should be available.

We eventually got around the problem by putting the collection into a list and then applying the ForEach method but it seems like there should be a better way to do this.

1

new List<ISelenium>(seleniumClients.Values).ForEach(client => client.Stop());

Is there?

One of the discussions we had at the Alt.NET conference back in September was around how important the environment that you work in is to your self improvement as a software developer and it came up again in a discussion with some colleagues.

I posted previously about my software development journey so far but to add to that one of the most important things for me about working at ThoughtWorks is the environment that it has provided me to improve myself as a software developer.

I am convinced that the environment you work in has a major influence on your ability to do this and therefore am not in complete agreement with some other posts I’ve read which suggest it’s more down to the individual and that some of these people don’t belong in the industry.

Why does the environment matter?

Individual motivation certainly plays a part in our development, but having the right environment as well creates opportunities to learn new concepts from colleagues that you might not have come across on your own.

When I talk about the ‘right environment’ I am referring to a workplace environment where you work with colleagues who are passionate about what they do and are have the ability and are willing to show others how to reach their level. This is something I am lucky enough to have working at ThoughtWorks.

Of course it is possible if you subscribe to the right RSS or Twitter feeds to teach yourself, but the value of having the opportunity to talk about them or try them out with colleagues cannot be underestimated.

I think one of the greatest benefits of these conversations is that they help guide you in the right direction or point out where you’re going wrong. It is still possible to make mistakes in a good learning environment but eventually someone is going to point it out to you and show you a better way to solve the problem.

This was certainly the case for me before I worked at ThoughtWorks whereby I spent a lot of time reading, what were in retrospect, the wrong types of books. I had a subscription to Books24x7 so I had access to the resources to learn but I channeled these in a less than optimal way.

I spent most of my time reading different C# books about essentially the same things without really knowing what the best way to improve myself as a developer was. I improved my knowledge of the APIs but my understanding of how to write maintainable software was no better than it was when I finished university.

Eventually some colleagues introduced me to the concept of writing code in layers to try and separate the various parts of the application I was working on. It improved my approach a bit but I still didn’t really know where to look to find out more information.

In my current environment if someone shows you an idea they will most likely point out some further reading areas for you to investigate and will be happy to answer any questions you have.

To give an example, Phil and I were recently talking about some functional programming concepts that are making their way into more object oriented languages. The examples he was showing me were written in Clojure, but as I am more familiar with these concepts in Ruby or C#, after our discussion he pointed me to a Bill Six article which describes all the functional collection patterns in Ruby.

I wouldn’t have come across that blog post without it being pointed out to me nor would I have become so interested about functional programming concepts in the first place without having had the opportunity to work with Alexandre Martins whose passion for learning about Erlang was what originally captured my interest.

These are just a couple of examples, there are many more.

What if you don’t have the environment?

Obviously there may be times when you don’t have the best environment to allow you to develop yourself.

The most direct way to solve this problem but perhaps also the most difficult is to change your environment so that you have better learning opportunities – there are certainly several people who have cited this as a major reason for them coming to work for ThoughtWorks.

The Obtiva Studio takes the idea of learning to an extreme with their Software Apprenticeship approach but even if you don’t have an optimal learning environment at work that doesn’t mean the learning cannot forge on!

Even if you don’t have the opportunity to work with the best in the industry they are still somewhat accessible through Twitter and most seem happy to answer questions and help people understand their ideas. Following the blogs of these guys and the blogs that they talk about is another way to keep in the loop.

Joining user groups such as Alt.NET is another way to interact with some of the people making things happen in the industry as of course is attending technical conferences where these people speak their words of wisdom.

Of course as Justin Etheredge points you still have to want to improve yourself otherwise it’s never going to work, but I still hold the belief that people generally try to do a good job and often the fact that they can’t do this is a lot to do with the environment that they’re in rather than genuinely not caring.

One of my favourite additions to JUnit 4.4 was the @Theory annotation which allows us to write parameterised tests rather than having to recreate the same test multiple times with different data values or creating one test and iterating through our own collection of data values.

Previously, as far as I’m aware, it was only possible to parameterise tests by using the TestNG library which has some nice ideas around grouping tests but had horrible reporting the last time I used it.

To create parameterisable tests using Theories we need to write some code like the following:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

import org.junit.Test;
import org.junit.experimental.theories.DataPoints;
import org.junit.experimental.theories.Theories;
import org.junit.experimental.theories.Theory;
import org.junit.runner.RunWith;
 
@RunWith(Theories.class)
public class SomeTest {
	@Theory
	public void testTheNewTheoriesStuff(int value) {
		// test which involves int value	
	}
 
	public static @DataPoints int[] values = {1,2,3,4,5};
}

The ‘testTheNewTheoriesStuff’ Theory is then executed with each of the values defined in the values array decorated with the @DataPoints annotation.

The error message reported for a failure is reasonably good and makes it quite easy to figure out which one of the data points causes the problem.

An example error message for an assertion which failed inside a theory might look like this:

org.junit.experimental.theories.internal.ParameterizedAssertionError: testTheNewTheoriesStuff(values[1])

It’s 0 indexed so this error message tells us that there was an error when running the theory with the 2nd data point, therefore allowing us to go and work out why that’s the case and fix it.

This approach is actually particularly useful for testing the scope in which classes we pull from a dependency injection container are available from in our application.

Another potential use for this would be to test the edge cases of our classes – perhaps this would work best if we can randomise the data it uses.

This seems to be more the approach Microsoft are taking with the the Pex framework, a similar idea in the .NET space.

While reading Pat Kua’s latest post about how coding a certain way can help you avoid certain classes of bugs I was reminded of a technique taught to me by a colleague with regards to writing functions/methods.

The idea is that it is more effective to code for positive data values rather than trying to work out all the possible negative combinations, since there are likely to be cases which we hadn’t considered if we do the latter.

For example, given the following method outline:

1
2
3

public void someMethod(int someValue) {
 
}

We might know that this method should only be allowed to take in non zero values. Therefore it makes more sense to code for this knowledge than to infer which values are not allowed.

The following code snippet…

1
2
3
4
5
6

public void someMethod(int someValue) {
	if(someValue != 0) {
		// throw exception
	}		
	// someOtherMethod();
}

…would therefore be preferable to this code snippet…

1
2
3
4
5
6

public void someMethod(int someValue) {
	if(someValue < 0) {
		// throw exception
	}		
	// someOtherMethod();
}

…since in the latter we are making the assumption that less than 0 is invalid whereas the actual requirement was for non 0 values to be invalid.

I know this is a highly contrived example but in theory this approach should prevent unexpected behaviour in our functions.

I have been following this approach since I was shown it and my first thoughts are that it leads to code which is more expressive and easier to write since we are working with what we know rather than trying to infer what we don’t know.

I think that following a test driven approach would eventually lead to us writing code similar to this anyway, but it’s an interesting idea to keep in mind.

My colleague Sarah Taraporewalla has written a series of posts recently about her experiences with TDD and introducing it at her current client.

While I agreed with the majority of the posts, one thing I found interesting was that in the conversation with a TDDer there were two tests being worked on at the same time (at least as far as I understand from the example).

This means that there will be two tests failing if we run our test suite, something which I try to avoid wherever possible.

I like to keep my focus just on the test that I am currently working on, so my approach if I had another test that I knew needed to be written would either be to write it down on a piece of paper or to write the skeleton and then just not put anything inside the test body.

This could be seen as being a touch risky in case I then forget to actually write the test and the build remains green, but I prefer this trade off than the distraction that I feel when having more than one test red.

When driving out the design of classes I am now veering towards the approach of severe simplicity such that we literally only do enough to make the test green even if that involves returning a hard coded value for example.

The next test after that would probably be the one that drives out the implementation since it becomes easier to write the code to handle the general case rather than hard coding specific implementations for the individual tests.

I started becoming convinced of this approach after trying the Karate Chop Code Kata a couple of months ago where I set up all the tests initially and therefore had 20 tests failing all at once.

It felt quite overwhelming having that many tests failing, and the sense of progress from making a test pass wasn’t there for me.

It seems a bit ridiculous but keeping the steps as small as possible is certainly the approach I am seeing the most success with at the moment.

I’ve been working quite a lot with Javascript and in particular jQuery recently and since I haven’t done much in this area before all the tips and tricks are new to me.

One thing which is always useful no matter the programming language is to use it in a way that you can get rapid feedback on what you are doing.

Fortunately there are quite a few tools that allow us to do this with Javascript:

Firebug

The Firefox plugin is perhaps the quickest way of getting feedback on anything Javascript and indeed CSS related.

The ability to see which HTTP calls have been made on a page is invaluable for checking whether AJAX functionality is working correctly and DOM manipulation can be executed and tested on the fly.

Including jQuery in a page effectively makes Firebug the jQuery Interactive Console, allowing us to try out the different functions and see their effects immediately.

Unit Testing Frameworks

There are several javascript unit testing frameworks around at the moment which run in the browser and provide the ability to write assertions on our code.

I have been using QUnit and screw-unit and while they work reasonably well for simple tests, neither seems to be at the level of JUnit or NUnit for example. I’m sure this will come as they mature.

Other frameworks I’ve heard about but not tried: RhinoUnit, JSNUnit, JSUnit, no doubt there are others I haven’t heard about yet.

Selenium IDE

The sometimes forgotten Firefox plugin is very useful for quickly creating repeatable scenarios to see the impact that code changes have had.

The beauty of this approach is that it takes out the manual steps in the process, so we can just make our changes and then re-run the test. The runner lights up green or red, taking out the need to manually verify the correctness of our assertions.

Alert

The ‘alert’ function is perhaps most useful when we want to quickly verify the path being taken through a piece of code without having to step through it using the Firebug debugger.

It’s probably more useful for proving our assumptions than actual debugging and it’s certainly quick and easy to set up.

The Book

Taiichi Ohno’s Workplace Management by Taiichi Ohno

The Review

Having completed The Toyota Way a few weeks ago I was speaking with Jason about what books were good to read next – he recommended this one and The Toyota Way Fieldbook.

I struggled to see a connection to software development with a lot of what I read, but there were certainly words of wisdom that we can apply to continuously improve our ability to deliver projects.

What did I learn

• Just in Time doesn’t mean exactly when the raw material is needed – it means just before it’s needed. This concept can certainly be applied in an agile software development process to ensure that story cards don’t spend too long in any column before moving to the next one. The reasoning in our case being that the knowledge behind the analysis/development of them is at its greatest just when the card has completed that stage.
• If you make defects you have not worked – this is related to the idea of building quality into the process. You are not adding value if the work that you produce has defects in it. This is quite an interesting contrast to the more typical ‘hours worked’ approach whereby the productivity in these hours is not considered to be that important.
• The job of team leaders is to make life on the gemba (i.e. shop floor) better. This has some similarities with the Tech Lead role on software projects where the person playing that role will spend a lot of their time reflecting on the development process and looking for ways to make it work better. This can be through driving pair rotation on a team, running analytics on the code to find areas of weakness, helping t setup test frameworks etc. Reflection on these types of things is the only way to drive improvement.
• Stop defects moving through the system – this is achieved in agile by having story kickoffs and walkthroughs, the former to ensure that everyone is clear what is expected of a story and the latter to ensure that those criteria have been met. Catching defects early makes them much easier to fix since the story is still freshly in the head of the developers that worked on it.
• Stop the line for defects – the idea here is to prevent defects from moving through the system, similar to the above point. In this case I’d have thought it’s more similar to not wanting code to be checked in on a red build so that the problems can be fixed before the line continues so to speak. It does seem a bit over the top to stop people checking in just because the build is red though, a better strategy perhaps being a team discipline to not check in when this is the case.
• Don’t automate for the sake of it – look for manual improvements in the process before deciding to automate something. I think this is quite interesting as automating processes in software development is not as costly as it would be on a production floor. One area where maybe there is more debate is automated acceptance testing using UI driven tests. These can often take ages to run as part of the build when there may in fact be better (also probably automated) ways of testing the same functionality. In this case perhaps recognising that there are options when it comes to automating is the key take away.
• There were several mentions of standardising the approach which is probably more applicable to manufacturing than software development, although there are certainly areas, such as debugging, where a standardised approach would probably be more effective.

In Summary

This book is fairly short but it acts as a nice contrast to The Toyota Way and presents similar information in a slightly different way.