Mark Needham

I wrote a couple of months ago about an approach we're using to help people find test data builders in our code base by hanging those builders off a class called 'GetBuilderFor' and I think it's worked reasonably well.

However, a couple of weeks ago my colleague Lu Ning suggested another way to achieve our goal of allowing people to find the builders easily.

The approach he suggested is to put all of the builders in the same namespace, for example 'Builders', so that if someone wants to find out if a builder already exists they can just type 'Builders.' into the editor and then it will come up with a list of all the builders that exist.

The benefit of this approach is that it means we can make use of the object initializer to setup test data – perhaps one of the few occasions when it seems to be reasonably useful.

Lu Ning explains in more detail on his blog but the idea is that instead of:

new FooBuilder().Bar("hello").Build();

We could do this:

new FooBuilder { Bar = "hello" }.Build();

The second approach requires less code since we can just create all public fields and setup a default value for each of them in the class definition and then override the values later if we want to as shown above.

We can't do this with the 'GetBuilderFor' approach since you can only make use of object initializer when you are initialising an object (as the name might suggest!).

Another advantage of this approach is that we don't have to write the boiler plate code to add each builder onto the 'GetBuilderFor' class so that others can find it.

The disadvantage is that once we type 'Builders.' to find the list of builders we then need to delete that text and type in 'new FooBuilder()…' which means the flow of creating test data isn't as smooth as with the 'GetBuilderFor' approach.

I don't feel like there is a really big difference between these approaches and as long as people can find code that's the main thing.

There would probably be less typing required with the namespace approach although I've never really felt that typing is the bottleneck in software development projects so it would be interesting to see if this would give us a gain or not.

We are still using the 'GetBuilderFor' approach on our project since there probably wouldn't be a massive gain by switching to the other approach at this stage.

It does seem like an interesting alternative to solving the same problem though.

I've previously written about the builder pattern which I think is a very useful pattern for helping to setup data.

It allows us to setup custom data when we care about a specific piece of data in a test or just use default values if we're not bothered about a piece of data but need it to be present for our test to execute successfully.

One problem that I noticed was that despite the fact we had builders for quite a number of the classes we were using in our tests, when new tests were being added test data was still being setup by directly using the classes instead of making use of the builders which had already done the hard work for you.

A colleague and I were pairing last week and I pointed out one of these areas and he suggested that we should try and introduce the builder pattern to try and solve it!

We actually didn't have a builder for that particular piece of data yet but I pointed out several other builders we did have which he wasn't aware actually existed.

Clearly I hadn't done a very good job of communicating the existence of the builders but when discussing this we realised that the turn around time for checking whether or not a builder existed was actually not very quick at all.

• Start writing test and realise that test data setup was a bit complicated
• At best search for 'ClassNameBuilder' if you knew that was the naming convention for these builders
• Create test data for the test by typing 'new ClassNameBuilder()…'

We therefore came up with the idea of anchoring the builders to a common class which we called 'GetBuilderFor'.

It is now possible to create test data by writing code like this:

var car = GetBuilderFor.Car().Year("2009").Make("Audi").Build();

The nice thing about this is that we now only have to type in 'GetBuilderFor' and then a '.' and ReSharper will show us all the builders that are available to us. If there isn't one then we can create it.

Communication wise we've both been mentioning this approach in our stand ups and to other people when we pair with them and hopefully this approach will stop the duplication of test data creation.

For those in the Java world Jay Fields wrote a cool post a few months ago where he describes a way to do a similar thing in Java. I think this is one place where having static imports makes the code read really fluently.

Pat Kua has a recent post where he talks about the language used between testers and developers when talking about defects that testers come across when testing some functionality and while I would agree with him that the language used is important, I've always found that injecting some humour into the situation takes the edge off.

As Dahlia points out I think this is probably only possible if there is good rapport between the developers and testers on the team so perhaps this has been the case for the teams I've worked on.

I would find it quite disappointing if my first attempt at a story cleared all the way through to business sign off without a tester in the team at least coming up with some cases where it doesn't work properly – I try to think of the scenarios that someone with a testing hat on would come up with but they are way better at that role than I am so there's bound to be something that I've missed.

Now this doesn't mean that I should keep recreating the same types of defects/bugs over and over again – that would be the waste of re-learning and doesn't add a whole lot of value.

In all the teams I've worked on there has definitely been a bit of banter between the testers and the developers whereby the testers tell us off 'tongue in cheek' for putting so many bugs into the code and we respond by asking them not to keep on breaking the application.

I've always felt that this approach worked reasonably well although it should probably be pointed out that I only do that with my ThoughtWorks colleagues where we pretty much have an implicit understanding that we are not criticising each other when talking in such a (supposedly) blunt manner.

If there's any underlying lesson from this approach then I would suggest it's that developers would be better of assuming that a tester is probably going to find a bug in their code and that they shouldn't assume something is finished just because it is development complete.

Testers on the other hand maybe can be less confrontational (as Pat suggests) when they find bugs – the developers didn't put them in there deliberately! You guys just happen to be way better at using the application in a way that finds its' flaws than we are.

Keeping it light hearted is also way more fun!

I've been reading Neal Ford's The Productive Programmer (my review) which is a book all about improving your productivity as an individual developer.

It got me thinking that there are also ways that we can make teams more productive so that they are actually teams and not just a group of individuals who happen to work with each other.

I've had the opportunity of working under some great Tech Leads who have helped create an environment where teams can perform to their maximum. I've noticed some recurring themes in both those teams.

In his book Neal talks about getting into a state called 'Flow' when programming. This is a state where you are totally focused on what you're working on and are able to be extremely productive.

When looking at Team Productivity one of the key factors behind how well the team performs is how well the team communicates. There are several ways that we can ensure that this is done effectively.

Team Proximity

It seems obvious but teams operate optimally when they are all working in the same physical space. Whether this be having an area of the office just for the team or using a conference room, communication is at its best when it's easy to do.

In particular if the desk layout is such that it is easy for people to pair with each other on a problem or ask questions without having to move very far then we have a good setup.

Team Size

We need to keep the size of the team appropriate to the size of the work and the time in which it needs to be completed.

The smaller the team and therefore the smaller the number of lines of communication the more effective a team can be. Of course we need to ensure that we have enough people on the team to complete the work required.

At an extreme we learn from Brook's Law that adding people to a team probably won't make it go faster. This is also true when working out the initial size of the team – if the team is too big then the number of lines of communication becomes increasingly big and effective communication becomes difficult.

Safe Environment

Even if you have the other two it won't matter unless a safe environment can be generated for people in the team to interact.

This means that people can feel free to ask questions to others in the team without being made to feel inferior.

People not communicating properly with each other is one of the biggest reason time is wasted on projects – reinventing solutions to problems that another team member has solved is a complete waste of time.

To given an example – on one project i wanted to work out how to unit test a Windows web service that we had written. I searched Google a bit but couldn't work it out. Luckily I was able to ask one of my more senior colleagues how to do it and he pointed me towards the Gateway pattern which allowed me to solve the problem straight away.

He didn't make me feel like I was stupid for not knowing how to solve the problem, but explained some options for how he would solve it and pointed me towards a book where I could read more about the solution.

How do we get the balance?

Individual productivity is defined as reaching the state of Flow in The Productive Programmer. In this state by definition you are working alone and not communicating with other team members. Team productivity on the other hand requires constant communication to make it work.

My colleague Jon Pither describes some of the issues he has noticed with pair programming with regards to this.

Psychologists refer to zone as ‘flow’. Daniel Coleman – author of Emotional Intelligence – describes flow as being “emotional intelligence at its best… the ultimate in harnessing the emotions in the service of performance and learning”.
…
Pair programming is a not stress free activity…Being in a “pair” you are constantly required to explain your intricate thought processes to another person.
…
We need to appreciate that developers are humans, and sadly are not perfect coding punching-out machines. Pair-programming introduces an emotional burden on the developer.

While I agree with Jon that pair programming is a completely different proposition to working alone, I'm not as qualified as him to comment as I've spent most of my professional life pair programming.

Certainly within an agile team there will be tasks which can be done individually and maybe these are the times individuals can use to achieve the fulfillment that being in a state of flow provides.

In terms of pure productivity I wonder whether there is such a thing as Pair Flow or Team Flow which would describe the state where a pair or team is working in an optimal state.

There needs to be a balance between a pair actually getting things done but also providing help to other pairs when the need arises.

I have noticed that one way this works fairly successfully is that if another pair needs help then only one person in the pair goes to help while the other can continue working. Although you lose the benefit of having both people at the keyboard since it's only for a short period of time I think it's acceptable.

For me personally I find it more enjoyable to work with others all the time even though I may not get into the state of flow although I appreciate that others may have different opinions on this matter.

Sometimes the simplest things can provide the greatest value to project teams. We often look for a technical solution to problems where something simpler would achieve the same aim.

The Information Wall is as its name may suggest a place where you can put information that people in the team need to know but which they have not (yet) committed to memory.

Examples of things that you could put on an information wall could be:

• Wiki url
• SVN repository url
• Remote machine names & credentials
• Build server url
• Useful phone numbers
• Anything else that's needed!

Although it may seem to add very little value I think it's a really good tool for making information accessible to people. It also means you avoid the valueless conversations where team members keep interrupting each other to ask for these details.

Having the wall as close to the development team area as possible is ideal.

One of the more interesting concepts used on the NLP course that I did last year was the idea of only giving positive feedback to people.

The thinking behind the theory (which I think comes from Robert Dilts, one of the early thinkers behind NLP) is that people know what they are doing wrong and already beat themselves up about it; therefore there is no point you mentioning it as well.

I was initially sceptical about this approach as it seemed a bit too idealistic for my cynical mind. I found it extremely difficult to start with and didn’t give any feedback to anyone for quite a few sessions. Eventually though something clicked for me and by the end of the 18 day course I feel I did gain a greater respect for and recognition of the talents that other people on the course had. The need to focus only on the positive actually seems to drive the mind to see more in this area than it otherwise would.

Although noone likes it when they are criticised, I think there are some occasions when someone criticising you can prove to be extremely motivational. This basically involves them completely writing you off and you then being determined to prove them wrong. For example at school I was told that I would definitely fail the Pure Maths modules of my A Level Maths course. Completely unimpressed with this verdict I persevered with it for months eventually scoring 85%. Job done.

I think sometimes when giving critical feedback it can say more about you than it does about the person you are giving it to, and this is where it’s vital to step back and think why you are giving the feedback.

I find at least for myself the tendency is to want to point out things people do that annoy me, which in effect is me trying to make the person more like myself. Steve Pavlina suggests that the things we hate the most in other people are the things we actually hate in ourselves. Therefore his suggestion was if you find something someone else does annoying, first look at yourself and try and improve yourself in this area.

I’m not sure if I totally subscribe to why this approach would work but I definitely agree that it is way easier to change yourself than it is to change someone else.

Similar articles:

• Giving effective feedback

One of the first unusual (to me) things that I noticed from the trainers at ThoughtWorks University was that when they were listening to participants they would often ask questions and re-frame the participants' comments. Intrigued and impressed by this I spoke to one of the trainers and was told that they were engaging in 'active listening'. Wikipedia defines the term as follows:

I believe this is a very useful skill to acquire, and I certainly hope to improve my ability in this area.

It reminded me of the 5th Habit that Steven Covey speaks of in his book titled 'The Seven Habits of Highly Effective People': Seek First to Understand, Then to be Understood. Certainly easier said than done…but then again we do have two ears and only one mouth so perhaps there is a good reason for that!

Browsing the ThoughtWorks Blogs yesterday evening I came across a link to an interesting site which spoke of the 'Eight barriers to effective listening'. I found this particularly useful as not only does it point some of the common problems one can have when listening to someone else, but also suggestions as to how these can be overcome.

A couple of months ago I read a book titled 'Coaching Yourself to Leadership' – although I found it quite heavy going in places, it too touches on some listening barriers, namely:

I hope this is ok to post on here – I've just written up the points straight from the book. Copyright of the author Peter O'Brien and all that.

I know I do at least 3 of those, and that's being kind to myself!

One of the most interesting things I have discovered since starting at ThoughtWorks earlier this month is the emphasis that is placed on giving feedback.

The first lesson we were taught about giving feedback was that it could be one of two types. Either it should Strengthen Confidence or Increase Effectiveness.

In Layman's term that means that if you want to make a positive comment about somebody's contribution then you should make reference to something specific that you believe they have done well so that they can continue doing it. Equally if you believe there is an area that they could improve it, a specific example of this behaviour/fault should be noted along with a suggestion for how they can improve.

As a member of Toastmasters since January I was already used to this concept of feedback and there are certainly parallels in the feedback system encouraged at Toastmasters and that used at ThoughtWorks.

Although Toastmasters do not define types of feedback, there is an expectation that evaluators will apply themselves in a certain manner when carrying out their job.

One of the things which is frowned upon is known as 'whitewashing'. This is where an evaluator would say that a speaker was 'brilliant' or give a summary just using complementary adjectives. Although the speaker may well be flattered, it does not really tell them anything or leave room for improvement. The use of the word 'brilliant' or 'superb' is only the perception of the person using it, and the failure to make use of the word with regards to a specific behaviour or action means that it is rendered meaningless.

Equally when the evaluator believes there is an area that the speaker can improve in they should make a reference to the specific negative behaviour or action so that the speaker can recall their mistake and go about making the improvement. When giving feedback it is very poor practice to attribute your own feelings to the speaker – you are giving them control over something which they do not have control over! For example, if an evaluator were to say: 'I felt bored listening to your speech, you should make the next speech more interesting'. In this case the evaluator is giving the speaker the power to make them feel bored. It is ridiculous to let someone have that amount of control over you and if we consider that another person listening to the same speech may have felt really engaged, a property of the speech cannot be that it was 'boring'.

This is very similar to the way that ThoughtWorkers are expected to give feedback, although it is also emphasised that when giving feedback one should speak only for themselves, and not try and speak for a group of people. Doing this would assume that mind reading is possible and as far as I'm aware this feat has yet to be achieved. An example of committing this mistake would be to say something along the lines of: 'It would be better for us if you could do x'. In this case 'us' is not defined and it is unlikely that one person can speak precisely of the feelings of other people.

This concept is very similar to that of Generalisation in the NLP Meta Model, which states the following:

This is an area that I am actually working on myself, and I am finding it very difficult to speak only for myself because I'm so used to generalising! Of course there are still times when generalisation is vital, and we would find it very difficult to live our daily lives without generalising on some things. Giving feedback, however, is one area where this 'technique' is counter productive.