markhneedham/blog huggingface dataset:
Pair Programming: Introduction
Date: 2008-02-10 01:47:25

I've had the opportunity to have worked with many different people http://c2.com/cgi/wiki?PairProgramming[pair programming] wise over the last year or so, and having seen it done in several different ways thought it would be interesting to work through some of my thoughts about this Extreme Programming (XP) originated practice.

First of all it seems to me that pair programming is a technique that is used with a lot more frequency at ThoughtWorks than at any other IT organisation.

Obviously I do not know every IT organisation in the world, but based on discussions at the http://www.altnetuk.com/[ALT.NET UK] conference I went to last weekend; it certainly came across to me like that. The difficulty in getting clients and/or management to see the value in having two people on one machine was the main factor mentioned as proving problematic.

I have been working for ThoughtWorks for 18 months now and have been pairing for all but 3 of those months. Perhaps contrary to popular opinion, not every project is a 100% pairing one.

I've paired with people for 20-30 days at a time, paired with people for 1 day at a time, paired with people who have been pairing for years, paired with people who are pairing for the first time, and all in all it's been fun.

I now find writing code far more enjoyable when working with someone else, motivated by the opportunity to bounce ideas around and come up with better solutions.

The biggest benefit for me of pairing is that you have to vocalise your ideas to your pair. This massively reduces the chance of going down a dead alley as a '`wrong`' idea would have to somehow make sense to two people, which is much less likely to happen.

Equally, when done well, you end up thinking a lot more about why you are doing things e.g. why should that method go on this class, should we introduce a new service, why are we testing it in this way, should we be testing it another way etc.

On the flip side there are times when you just want to look up something which interests you but isn't totally relevant to the current task and that has to be placed on the backburner for the time being. Pairing can also prove very tedious when doing fairly trivial tasks such as changing configuration files; although of course it does help if every knows how to do this so pairing on these tasks does provide some benefit.

I will cover some of my other thoughts in future posts.
Learning theory first
Date: 2008-02-09 13:15:11

I've always been the type of person who only gets the motivation to do something if there is some useful practical reason for doing so. It therefore probably doesn't come as much of a surprise that I hated the majority of my mostly theoretical computer science degree.

I was talking to one of my colleagues last week and came out of the conversation convinced that the desire to know the theory behind concepts is amplified when you actually get to see it in action in a real life system.

My prime example is multi threading and concurrency. At university we had to write a program to calculate e to 500 decimal places using multi threading. In my mind this exercise was completely pointless, and I don't think I came out of it any wiser with regards to threading.

Contrast that to the project I'm working on now where the main window of our application was freezing up due to an expensive operation being run on the UI thread. The solution of course was to execute the expensive operation on a background thread.

Although I know this is a fairly trivial example, it did provide a real life situation where threading was required. As a result of this I have become much more interested in the specifics of threading and the potential problems that can arise when doing so.

It would probably actually prove more useful to see the concepts in action in a real life system before being taught the detailed theory behind how it all fits together. For me at least when I'm learning about something I like to have a reference point and having seen the concept in action would provide this.

It seems obvious to me therefore that studying for a degree after having first done a few years in industry would probably lead to you having a much richer learning experience and a much improved understanding. Not that I expect that to catch on!
Feedback: Positive Reinforcement/Change yourself first
Date: 2008-02-12 00:01:58

One of the more interesting concepts used on the http://www.ablworld.com/Courses/Practitioner.htm[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. http://www.stevepavlina.com/blog/2007/01/understanding-human-relationships/[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:

* link:/blog/2006/09/02/giving-effective-feedback/[Giving effective feedback]
Pair Programming: The Non Driving Pair
Date: 2008-02-14 01:27:58

One of the intriguing aspects of pair programming for me is that of the non driving person in the pair -- what are they supposed to do?!

Obviously there are fairly well known strategies for more interactive pairing, such as http://c2.com/cgi/wiki?PairProgrammingPingPongPattern[Ping Pong] and Ball and Board (which is where one person controls the mouse and the other the keyboard), but neither of these strategies suggest what to do when you are not driving

Obviously it is very easy to be a bad non driving part of the pair, by http://blog.jayfields.com/2007/09/distracted-pair.html[getting distracted] by what's going on around you and a quick fix that I've heard to solve this is that when you're bored, ask for the keyboard back. This solves the immediate problem but still doesn't make you any better at contributing when you're not at the keyboard.

One idea that I've been playing with recently is keeping a list of the next task that needs to be done after the current one is done -- effectively just tracking where we are on the story. We use tiny tasks for most stories as laid out by http://www.thekua.com/atwork/2007/07/19/onboarding-strategy-tiny-tasks[Patrick Kua]. This does work although you still don't feel that involved, and it can end up seeming like you're dictating to the other person what to do. This is definitely an approach to be applied with some tact.

Some of the more skilled non drivers I've worked with have the ability to see the bit of code being worked on as part of the whole and are able to see when we have gone too far down the wrong path and should actually be making changes elsewhere. I find this a lot harder to consciously improve, and I've been told it's a skill that comes with experience.

I'm sure there are other roles of non driving that can be applied, mentoring being one, although that's for another post! Thoughts?
Pair Programming: Benefits of the pair switch mid story
Date: 2008-11-04 00:00:26

On my current project we've been having some discussions around the frequency with which we rotate pairs, the feeling being that we probably keep the same pairs for a bit too long.

We discussed using techniques such as http://mitchlacey.com/docs/XR4PromiscuousPairingandBeginnersMind.pdf[promiscuous pairing], which takes the idea of pair rotation to an extreme, but have settled on making our rotations more or less daily.

One interesting thing I noticed from some recent pair switching was the immediate benefit we can realise from the pair rotation.

When we switch pairs mid story the story champion (person who owns the story from start to end) has to get their new pair up to speed as quickly as possible.

My colleague http://lizdouglass.wordpress.com/[Liz Douglass] has a very precise yet effective way of doing this. From observation:

* Describe the story or task from a high level detailing what it is we are trying to do and how it fits into the system as a whole
* Describe what has been done so far, why that approach was taken and what is left to do.
* Describe any problems encountered, previous solutions tried and new ideas to try to solve the problem.

I have found that this works really well and allows me to contribute to the task at hand more quickly than if I had to ask questions to work out what is going on.

The story champion has the benefit of having been involved in the story kick off so it is certainly very useful for them to be able to take this information and then provide it with context to their future pair.

In addition I have noticed that explaining what you are doing on a task to a new pair often leads to you noticing flaws in your logic, therefore leading you to solve the problem.

Even if this doesn't happen, having a new pair of eyes and a new perspective on a problem can often lead to it being solved more quickly.
Html.RadioButton setting all values to selected value workaround
Date: 2008-11-28 21:32:28

While working with the Html.RadioButton() UI helper for ASP.NET MVC we came across an interesting problem whereby when you submitted the form, all the values for that particular group of radio buttons was set to the value of the one that was selected.

For example, given a form like this:

[source,csharp]
----

<%= Html.RadioButton("option1", true) %>Yes
<%= Html.RadioButton("option2", false)%>No
----

When we first load the page, this is the HTML it generated:

[source,csharp]
----

<input type="radio" name="option1" value="true" />Yes
<input type="radio" name="option1" value="false" />No
----

When we post the form having selected the 'Yes' option for example, this is what the HTML looks like now:

[source,csharp]
----

<input type="radio" name="option1" value="true" checked="checked" />Yes
<input type="radio" name="option1" value="true" />No
----

A bit of Googling revealed that http://stackoverflow.com/questions/277607/htmlradiobutton-sets-all-values-to-selected-value[others] have come across this same problem and that it is a http://forums.asp.net/t/1338576.aspx[bug in the code].

The solution suggested on Stack Overflow was to write a custom RadioButton helper which does a regex replacement on the 'value=' part of the HTMl generated.

We started working down the path to using a similar approach before http://jamescrisp.org/[James] pointed out that we might be able to achieve the same outcome by passing in the value as one of the htmlAttributes.

We changed our original Html.RadioButton() code to take in 'new { value = true }' and 'new { value = false }' respectively and it solved the problem.
TDD: Suffering from testing last
Date: 2008-11-28 00:34:24

I've always been a big proponent of writing tests before writing code, and I roll off the standard reasons to people who question this approach:

* They help to drive the design
* They provide a safety net when making future changes
* They provide a way of communicating the intent of the code to the rest of the team

And so on. Despite knowing all this I recently took a non test driven approach to writing some bits of code - we were keen to get the system working end to end so it seemed a trade off worth making to prove that it was doable.

I knew that I would *suffer when it came to testing this code after I had already written it* and indeed it did!

I've tested around legacy code before and although http://www.amazon.co.uk/Working-Effectively-Legacy-Robert-Martin/dp/0131177052/ref=sr_1_1?ie=UTF8&s=books&qid=1227794213&sr=8-1[Michael Feather's book] makes it much easier, it's still not a great experience. The saving grace has always been that I didn't write the code whereas in this case it was quite definitely my fault that I ended up with this problem.

The original pain came from not knowing where I should start. Since we didn't have any tests I wasn't sure exactly what the code was doing despite the fact that I had written most of it fairly recently.

In particular I ran into the problem whereby I wrote a test which passed so all seemed good. Suspicious as to whether this was the case I decided to comment out some of the code which was apparently making the code pass. I expected the test to fail and give me the red bar but in actual fact the test still passed!

It turned out that I had written the expectations for my mocks slightly wrong in the test - a mistake that I would have definitely caught if I had written the test first but could have easily missed by testing last.

After this I decided that because there wasn't too much complex logic in this particular piece it would be much better to *comment out the code and then test first* before fitting it back together again. Eventually I got all the code covered but it took much longer than if I had just tested it properly the first time around.

For me software development is all about creating quick feedback loops and I find it very frustrating when I'm unable to do this. Testing first is one very good way of achieving this as it provides a clear way forward and gives feedback on our progress.

I will certainly be very reluctant to test last again.
Standups: Pair stand together
Date: 2008-11-17 22:16:11

One of the common trends I have noticed in the http://www.think-box.co.uk/blog/2006/05/daily-stand-up-scrum-meeting.html[stand ups] of teams which practice pair programming is that very often the first person in the pair describes what they have been working on and what they will be doing today and then when it comes to the other person they say 'ditto'.

After I dittoed one too many times on a project earlier this year it was pointed out to me that this was not a valuable way of contributing to the weekend and that I should describe my view of our progress as it may differ to my pair.

I had thought I was avoiding repetition by not contributing information which had already been covered, but I went along with this idea and immediately something was mentioned which hadn't been previously covered. Instant vindication!

More recently I noticed a similar trend on another project I was working on   and we came up with the idea of *each pair standing together in the standup* and effectively speaking as one.

This allowed us to avoid the 'repetition problem' and the 'ditto problem' as when it was the second person's turn to speak they could just add in any details that their pair didn't speak about without having to repeat the whole context again.

I think this worked reasonably well and it seemed to make our standups move along more quickly.
Agile: Putting the risk up front
Date: 2008-11-10 22:44:15

The last two projects that I've worked on I've been on the project from right near the start, and one thing that's been consistent in both projects is that we've spent time early on in the project trying to reduce technical risk.

In my most recent project this has involved getting infrastructure in place early on, and in the previous one it involved working on technical spikes for several weeks to prove that what the client was asking for was actually technically possible.

While reading http://www.markhneedham.com/blog/2008/11/05/crystal-clear-book-review/[Crystal Clear] I noticed that this approach is the same as that advocated by Alistair Cockburn with regards to putting the highest learning tasks up front before business stories, and the idea of the http://alistair.cockburn.us/Walking+skeleton[walking skeleton].

Some people consider this opposed to the agile approach in that we are creating something before we absolutely need to use it. I think this is a difference in the understanding between doing something at the last responsible moment and the last possible moment.

The former is the way that I understand we should do things - get the pain out the way early on and not later on death march style

I wonder whether it should be the same on a per story basis or if there is no gain from taking this approach - i.e. usually the backend side of stories is what takes up the time so should we do this first and then drive out the rest or is it better to drive from the front?

One thing I have learnt from conversation about this idea is that we still need to show some progress to the business and therefore need to balance the need to reduce project risk with completing business stories.

Clearly there is a trade off to be made here but I think the 'risk up front' approach is preferable to leaving the integration until later on when it is both more difficult to do and doesn't leave much room for error either.
Debugging ASP.NET MVC source code
Date: 2008-11-19 21:30:19

We've been doing some work with the ASP.NET MVC framework this week and one of the things we wanted to be able to do is to debug through the source code to see how it works.

Our initial idea was to http://haacked.com/archive/2008/11/03/bin-deploy-aspnetmvc.aspx[bin deploy the ASP.NET MVC assemblies] with the corresponding pdbs. Unfortunately this didn't work and we got a conflict with the assemblies deployed in the GAC:

[source,text]
----

Compiler Error Message: CS0433: The type 'System.Web.Mvc.FormMethod' exists in both 'c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\8553427a\c1d1b9c6\assembly\dl3\898a195a\60680eb9_3349c901\System.Web.Mvc.DLL' and 'c:\WINDOWS\assembly\GAC_MSIL\System.Web.Mvc\1.0.0.0__31bf3856ad364e35\System.Web.Mvc.dll'
----

We attempted to uninstall the System.Web.Mvc assembly from the GAC but were unable to do so because it has other dependencies.

The next idea was to uninstall ASP.NET MVC using the MSI uninstaller. This worked in terms of getting rid of the assembly from the GAC but it meant that we no longer had support for ASP.NET MVC in Visual Studio.

Luckily http://tgould.blogspot.com/[Troy] pointed out James Kovac's blog post about http://codebetter.com/blogs/james.kovacs/archive/2008/01/17/debugging-into-the-net-framework-source.aspx[debugging the .NET framework source] and we were able to debug the ASP.NET MVC code by hooking up the http://www.codeplex.com/aspnet/SourceControl/DirectoryView.aspx?SourcePath=%24%2faspnet%2fMVC%2fSymbols&changeSetId=17272[pdbs] that come with the http://weblogs.asp.net/scottgu/archive/2008/03/21/asp-net-mvc-source-code-now-available.aspx [source code download].

Some other approaches were pointed out on the http://www.nabble.com/Debugging-ASP.NET-MVC-td20554211.html[ALT.NET mailing list] although the above is what worked for us.
Saff Squeeze: First Thoughts
Date: 2008-11-21 00:58:07

While practicing some coding by doing the http://sites.google.com/site/tddproblems/all-problems-1/Roman-number-conversion[Roman number conversion] last weekend I came across an article by Kent Beck which talked of a method he uses to http://www.threeriversinstitute.org/HitEmHighHitEmLow.html[remove the need to use the debugger] to narrow down problems.

He calls the method the '*Saff Squeeze*' and the basic idea as I understand it is to write the original failing test and then inline the pieces of code that it calls, adding assertions earlier on in the code until the actual point of failure is found.

The thinking behind this is that we will now have another much smaller test which we can add to our test suite although he did point out that it may take longer to solve the problem this way rather than using the debugger.

I'm not a fan of debugging through code and I believe if we are using TDD effectively then it should http://www.thekua.com/atwork/2007/10/test-driven-development-requires-less-debugging/[reduce the need to use the debugger].

When I got a bit stuck with the parsing of the input for my Roman number conversion I decided this would be a good time to give the approach a trial run.

The actual problem was that I was trying to parse a value such as 'XI' by called String.split("") which looking back of course was ridiculous. This was resulting in an array with 3 values - X,I and "" - which then gave a null pointer exception when I tried to convert it to a numeric value.

Applying the Saff Squeeze allowed me to narrow down this problem and change the implementation when I realised my approach was never going to work.

Although I wasn't able to keep the test which I had created from all the inlining, it did become clear to me from this exercise that my tests around certain areas of the code were not fine grained enough. I find I lose the discipline a bit when I test from the outside in which is something I am trying to improve. This method proved to be a good way of keeping me honest.

Kent suggested that it would take much longer to debug using this approach but I found I was able to solve my problem almost as quickly as if I had debugged through it with the added benefit that I wrote a few extra tests while I was narrowing down the problem.

It is certainly an interesting approach although one which I need more practice with before trying to introduce it into a work environment.