Mark Needham

Thoughts on Software Development

Archive for April, 2011

ThoughtWorks University: v2.0 vs v1.0

without comments

Since we finished the most recent ThoughtWorks University session last week a few people have been asking me how the experience was and I’ve found myself comparing this experience to my own as an attendee in August 2006.

Back then ThoughtWorks University was much different. We had 5 weeks of workshop style sessions and then spent the last week working on an internal application.

This time we spent 1 week doing the workshop style sessions, 1 week working together on a story and then 4 weeks working on the application.

Knowing what you don’t know

My general feeling is that although TWU v2.0 is better designed for helping people to learn, an advantage of the previous approach was that there was more opportunity to see the gaps in your skill-set.

From what I remember there was much more trainer input and at times it was amazing to see how good someone could be at programming once they’d got years of practice behind them.

Although this still happened, albeit less frequently, there was often feedback that people didn’t know what they didn’t know and were therefore unsure what they needed to learn.

They will still be able learn about those gaps on the projects they work on but I didn’t feel this group had the sense of how much there still is to learn as I did 4 1/2 years ago.

The ‘trainer’ role

The role of the ThoughtWorks University trainers has changed from being an actual trainer to being more of an enablement coach whose primary goal is to facilitate people learning.

I think this makes the ‘trainer’ a more passive participant as your job is no longer to ‘teach’ people things but rather to let them learn themselves.

At times this meant sitting back to allow people to explore and learn from their mistakes and although I think this is a valuable approach it can get quite boring!

Realism vs Creating Learning Opportunities

One of the nice things about the new style is that the challenges and problems that people encountered were actually real and not contrived.

On the other hand this meant that we couldn’t specifically target things that we wanted people to learn in such a structured way.

For example, I remember doing several sessions on object design and design patterns and although we weren’t experts in either of those by the end of TWU it helped us to see some areas that we could go and read/learn more about.

I think people probably came across similar types of situations in this TWU but in their pairs rather than as a group so it was more difficult to point out the learning area.

Written by Mark Needham

April 27th, 2011 at 12:33 pm

The ladder of inference

with one comment

In Discussing the Undiscussable William Noonan describes the ladder of inference, a tool which can be used to help us achieve double loop learning with respect to our interactions with other people.

Ladder of Inference helps people identify what information or facts are used as the basis for their reasoning process.

It also helps people understand how they interpret that information and how they apply their interpretation to the issue or problem at hand.

Essentially, the Ladder of Inference is a metaphorical tool designed to help people understand and describe their use of inductive reasoning. Given what we see, what conclusions do we draw?

Ladder of inference

The book mainly describes the ways that we end up climbing the inference ladder ourselves but I’ve been thinking recently that it’s quite interesting to know that in all likelihood that’s how other people are thinking about the things that we do.

One of the main examples of people climbing the ladder of inference in an ‘agile’ context is when somebody comes late to the standup in the morning.

The other members of the team often jump up the ladder and come to the conclusion that the late person is lazy/doesn’t care about the project or their time and is generally a bad person, all before finding out why they were late!

The ladder climbing gets even worse if the person is a serial offender and even though it’s unfair to that person, it’s unlikely that you’re going to be able to get all the other people in the team to change their way of thinking.

It therefore makes sense to be aware that people may be making these inferences about our behaviour and perhaps adjust the way we act accordingly.

Written by Mark Needham

April 24th, 2011 at 2:11 pm

ThoughtWorks University: Things people found difficult

without comments

After six weeks ThoughtWorks University #21 finished on Thursday so I thought it’d be interesting to summarise some of the things that people seemed to find difficult over the course of TWU.

The stack trace

We were using Java for the duration of TWU and as a result there were plenty of stack traces for people to debug.

These were most frequently related to incorrect wiring of Spring components but there were other reasons too.

People seemed to find these stack traces quite difficult to understand, particularly when one stack trace was nested inside another, and often just started guessing why the code wasn’t working.

This is a good example of where ‘quit thinking and look‘ from ‘Debugging – The 9 Indispensable Rules‘ comes in handy.

I think it takes a while for that lesson to sink in but it makes life much easier once it does.

Programming by wishful thinking

One of the programming techniques which we tried to encourage is the idea of programming by wishful thinking i.e. you write the code that you wish existed and then you go and implement it.

Some of the group seemed to find this approach quite difficult to understand and preferred to go and create the class/methods of the object rather than just pretending that they existed for the time being.

I think the intuitiveness of this technique might be linked to how easy people find the TDD approach to writing code and since many hadn’t done this before that may explain why it didn’t come naturally.

Using Google

I wrote a couple of months ago about some observations I’d had while pairing with people during a university recruitment event and one of them was that people struggled to find the answers to their questions on Google.

A lot of the time the most useful thing I could do for people when they asked for help was to show them how I’d search for the answer on Google.

More often than not this was enough for them to figure out the answer themselves.

Written by Mark Needham

April 23rd, 2011 at 7:47 pm

The sunk cost fallacy

with 4 comments

I recently came across David McRaney’s post about the sunk cost fallacy with reference to Farmville, a fallacy that is very applicable to software.

David starts off with the following statements which describe the fallacy pretty well:

The Misconception: You make rational decisions based on the future value of objects, investments and experiences.

The Truth: Your decisions are tainted by the emotional investments you accumulate, and the more you invest in something the harder it becomes to abandon it.

I think this is very true in a lot of IT organisations in particular when they’ve made a big investment on some sort of middleware, usually an ESB.

These can often cost hundreds of thousands if not millions of £’s so the person who authorised the purchase is likely to push very hard for it to be used because if it’s not then their decision looks very foolish.

The problem is that in a lot of cases using an ESB doesn’t simplify the system being built – it makes it much more complicated.

ESB’s are typically difficult to test against, difficult to setup on a continuous integration server and generally make the life of people who have to use them hell.

The sunk cost fallacy applies here because the organisation feels the pain of the initial purchase and doesn’t want to write that off even if it would make life easier for them from now onwards.

I even have my own smaller example from something I’ve been working on over the weekend.

I wanted to try moving this blog from WordPress to Jekyll and I came across octopress which simplifies the process by providing ready made style sheets and layouts.

I’ve got it mostly working but I couldn’t work out how to create pages which showed the posts in certain categories or for a specific month.

From what I can tell you can get that functionality by implementing a plugin but unfortunately plugins were only added to Jekyll from version 0.6 and octopress relies on henrik-jekyll version 0.5.

I’ve spent about a day and a half getting the blog to its current state so I’m pretty reluctant to write off that time and scrap the octopress idea.

Unfortunately that may not be possible if I want to get all the functionality of wordpress.

I’m not sure exactly when we should take the sunk cost and when we should write it off but being aware of it is at least a step in the right direction.

Written by Mark Needham

April 17th, 2011 at 12:05 pm

Tech Leading: Initial Thoughts

with one comment

As I mentioned in an earlier post I’ve been playing the role of tech lead on the project that we’ve been doing at ThoughtWorks University so I thought it’d be interesting to note down some of my observations so far.

Out of the tech leads that I’ve had I liked the style of Dave Cameron the best.

He viewed himself more as a technical facilitator rather than as a person who should make every single decision about how a system got built which meant that others also got a chance to take some responsibility.

Varying the style

I wanted to apply this style with everyone on the team such that I would facilitate a conversation with the pair about the story that they were working on but they would decide how they went about it.

This worked reasonably well for some of the people but I quickly noticed that others were ending up quite lost if we only had a brief conversation.

They needed a bit of a structure around what they were going to work on so in those cases we tiny tasked out the implementation together.

A fresh view

When I worked with Christian as my tech lead I noticed that when we were stuck on something he would often come round and ask a question which guided us to a solution which had been completely evading us.

I don’t yet do that as well as him but I have found that having a fresh and higher level view of a problem means that you can see things which the pair may now be missing because they’re so stuck in the implementation.

That’s happened several times and is always immensely frustrating for the pair involved!

Knowing what’s on the wall

I’ve got quite used to only having to know what story I was working on and not really needing to know that much about what the rest of the team are working on.

That approach doesn’t work quite as well in the tech lead role where you need to be the one who has an idea of what’s going on with everything that’s in play.

This is the thing I’ve struggled the most with and there have been occasions where stories have been in play way too long where I could have intervened and help the pair work out how to finish them.

Other people that I’ve spoken to have suggested that one way of ensuring you know what’s going on is to browse every checkin that’s made to the repository each day.

I did try this a couple of weeks ago but it’s really time consuming and I think you can get information about a story quicker by just talking to the people working on it.

Written by Mark Needham

April 17th, 2011 at 11:27 am

ThoughtWorks University: “It’s your project”

without comments

One of the things that we’ve struggled with at ThoughtWorks University is giving the attendees the opportunity to run the project that we’ve been working on.

The first few weeks were the most frustrating both for the trainers and for the attendees because we spent a lot of time telling the attendees that it was their project but then didn’t display behaviour consistent with that message.

From my observations this happened because the role of the trainers was defined as ‘senior team member’ which meant that if a trainer saw something going wrong they’d try and fix it since that’s what they’d do in a normal team.

This was most evident initially with the Iteration Manager which started off being one of the trainers.

After realising that this meant that person solved pretty much every problem we had to change that approach and let one of the attendees take the role.

By doing this I think the group as a whole have learnt more about what it takes to drive stories across the wall, facilitate a showcase, prepare a release and so on.

More recently we’ve stepped back a bit in the other roles and although I’m still acting as the tech lead we’re allowing others to cover some of the tasks that someone in that role might usually take care of.

The main learning for me is that our initial metaphor of being a ‘senior team member’ rather than a ‘trainer’ actually hindered the learning of the group despite creating a more realistic project environment.

It’s difficult to say whether we should have gone with our current approach straight from the start or not.

Part of me thinks it may have been useful to get an idea of what a normal project would look like but the other part thinks maybe we wasted learning time.

Written by Mark Needham

April 13th, 2011 at 8:28 pm

Feedback: Easing in

without comments

One of the most common techniques of feedback which I’ve come across is one that William Noonan describes in ‘Discussing the Undiscussable‘ as easing in.

From the book:

Easing in is a skilful strategy whereby I try to get the other person to come round to my point of view without my stating it directly.

From my experience we’ll try to do this because giving our point of view could lead to an awkward conversation so we’d rather they express our opinion for us instead.

Amusingly I managed to create an example of easing in while showing a colleague (colleague 1) the chapter about easing in!

We’d been involved in a conversation the previous evening with one other colleague (colleague 2) where colleague 1 was asking leading questions to colleague 2 in order to get colleague 2 to confirm an observation that colleague 1 had made.

It didn’t really work because colleague 2 had a different opinion of the situation so the conversation eventually petered out.

The next day I was reading the chapter on ‘easing in’ and showed it to colleague 1 expecting that they would immediately recognise what I was talking about.

Unfortunately that’s not what happened and my colleague just read the part I pointed out and then handed the book back without any comment.

Having realised what I’d done I went and spoke with them about 20 minutes later and described how I thought the chapter had some relevance to the conversation of the previous evening.

We then had the chance to discuss the idea of easing in a bit more and now both of us are more aware of the concept and try to avoid doing so when giving each other feedback.

Written by Mark Needham

April 13th, 2011 at 2:33 am

Posted in Feedback

Tagged with

HTML encoding/escaping with StringTemplate and Spring MVC

with 2 comments

Last week my colleague T.C. and I had to work out how to HTML encode the values entered by the user when redisplaying those onto the page to prevent a cross site scripting attack on the website.

I wrote a blog post a couple of years ago describing how to do this in ASP.NET MVC and the general idea is that we need to have a custom renderer which HTML encodes any strings that pass through it.

In our case this means that we needed to write a custom renderer for String Template and hook that into Spring MVC.

We already had a view class StringTemplateView so we needed to add to that class and add our custom renderer.

The viewResolver was defined like so:

    public ViewResolver viewResolver() {
        InternalResourceViewResolver viewResolver = new InternalResourceViewResolver();
        return viewResolver;

And after some guidance from Jim we changed StringTemplateView to look like this:

public class StringTemplateView extends InternalResourceView {
    protected void renderMergedOutputModel(Map<String, Object> model, HttpServletRequest request, HttpServletResponse response) throws Exception {
        String templateRootDir = format("%s/WEB-INF/templates", getServletContext().getRealPath("/"));
        StringTemplateGroup group = new StringTemplateGroup("view", templateRootDir);
        StringTemplate template = group.getInstanceOf(getBeanName());
        AttributeRenderer htmlEncodedRenderer = new HtmlEncodedRenderer();
        template.registerRenderer(String.class,  htmlEncodedRenderer);
    private class HtmlEncodedRenderer implements AttributeRenderer {
        public String toString(Object o) {
            return HtmlUtils.htmlEscape(o.toString());
        public String toString(Object o, String formatName) {
            return HtmlUtils.htmlEscape(o.toString());

At the moment we want to HTML encode everything that we render through StringTemplate but if that changes then we could make use of the formatName parameter which we’re currently ignoring.

In retrospect this looks pretty simple to do but my Googling skills were pretty much failing me at the time so I thought it’d be good to document.

Written by Mark Needham

April 9th, 2011 at 10:54 am

ThoughtWorks University: Similarities with ‘Discussing the Undiscussable’

without comments

I’m currently reading the final chapter of William Noonan’s Discussing the Undiscussable titled ‘Helping Those Who Teach, Learn’ and a couple of the ideas that he describes seem quite applicable to what we’re doing at ThoughtWorks University.

Modelling the skills

When teaching the Mutual Learning Model Noonan suggests that the practitioner needs to be able to produce actions consistent with the model in real time situations rather than just being able to do convincing presentations on the subject.

I think this is the same with teaching/facilitating the learning of ThoughtWorks University and it seems to centre around the espoused theory and theory in action.

The espoused theory describes our theory of what we think we do in a situation whereas the theory in action describes what we actually do.

I was a bit worried about doing a presentation/session on a topic where I would present my espoused theory about a topic and then more than likely not meet that theory in practice.

Over the course of the last month or so it’s become more clear to me that it’s not a big problem to make mistakes, even when you’re supposed to be the one who knows what they’re doing, as long as you’re open about your mistakes

Leading questions

Noonan talks about the use of leading questions when opening a topic to the group, something which I think is quite prevalent in sessions and workshops:

There are potential downsides to the approach of using questions to get to the predetermined correct answer. If the class doesn’t answer correctly, the teacher keeps asking questions like, “No, that is not it exactly. What other things can you think of?”

The students or participants hit a point of frustration where there is finally a collective call to “just tell us the answer.”

The intention is to try and make the session interactive but I’m not convinced that it helps learning and it often seems that if someone does actually get to the ‘correct answer’ that it’s because of guessing rather than real understanding.

Frankie and I unfortunately ended up using an approach similar to this when facilitating a session on the ThoughtWorks delivery model.

We wanted the group to come up with the different components of a software delivery project rather than have us do a presentation on it which would have been immensely boring.

They got 90% of these without the need for any intervention but we did end up asking leading questions to draw out the last 10%.

Rather than doing this, Noonan suggests the following approach:

The remedy is for the leader to follow the basic rule of thumb that if you have a view, state it and balance it with inquiry to see if people agree or have different views.

In this case that would have meant that we would have kept the facilitated discussion but then helped fill in the missing components before discussing those with the group.

Written by Mark Needham

April 9th, 2011 at 10:38 am

Unix: Getting the sound from ‘say’ as a wav file

with 2 comments

I spent a bit of time yesterday afternoon working out how to get the output from the Unix command ‘say’ to be played whenever our build breaks.

We’re using cctray on a Windows box for that purpose which means that we need to have the file in the ‘wav’ format.

Unfortunately ‘say’ doesn’t seem to be able to output a file in that format:

> say "WARNING! Drainage has occurred, please fix it. Drainage has occurred, please fix it." --output-file drain.wav
Opening output file failed: fmt?

So I first converted it into a ‘wmv’:

> say "WARNING! Drainage has occurred, please fix it. Drainage has occurred, please fix it." --output-file drain.wmv

And then converted it into a ‘wav’ via

Sadly doesn’t seem to have an API so I can’t fully automate it.

If anyone knows a service that does have an API let me know!

Written by Mark Needham

April 7th, 2011 at 7:18 pm