Sign in / up

* Posts by Toby

2 publicly visible posts • joined 31 Jan 2007

The perils of pair programming

Toby

Stupid Analogy

Just to be clear. You say you've done pair programming... have you done XP? your book is about XP, not pair programming. They are very different things.

Your bucket analogy... Its funny but its just not true, is it?

Your idea that you don't have to experience something to comment on it is just crazy. Its an argument from Ignorance and a Reduction to Absurdity.

Let me put it another way: If a child tells you he hates brocolli even though he's never tried it. Should we just accept that and make him something else to eat? Obviously no, you make him try it.

Your argument is an inexcusable philosophical argument to use for any argument except for extreme corner cases like jumping off cliffs. XP is not an extreme corner case. Your argument is just a childlike response you can use to stay in your comfort zone and not bother to try something which may havbe merits.

One itinerant teacher I once had said to me:

"When I'm teaching you, you do it my way. It doesn't matter if you think you know better. Humour me, do it my way. That way if you were right then you've lost nothing. If I was right you've gained something. If you ignore me and keep doing it your way all you will do is stay where you are"

In short: "Try anything once"

The argument that people should be allowed to choose whether they pair program or not is pretty weak too. Maybe people should be allowed to choose how many hours they work, after all if they are only productive for 4 hours a day then they might as well only work those hours.

What about the company's right to choose? Maybe they choose you pair program so that everyone understands the code. Maybe they choose a development methodology that makes sense for their project. Maybe its a lightweight methodology like XP because the project goals match XP. XP enforces pair programming, you're against any methodology that enforces pair programming. Sooooo..... Who gets to choose what you do at work? yourself? or the person who pays the wages?

You can philosophise as much as you like but if XP makes sense from a business and project point of view then you do it, or you leave. Thats how jobs work.

Don't get me wrong, there are legitimate criticsms to XP, unfortunately we're missing nearly all of them here in what seems to be a childlike foot stamping.

Legitimate Criticisms:

XP is great for describing low level code (at the unit level) but is very weak at delivering the stretegic 'big picture'

XP relys on interpersonal communications between developers, and this starts to become unwieldly at 20 developers. therefore XP for large projects is problematic

0 0
Toby

Another view on Pair Programming

First of all, I have just ordered your book and I'm sure it will be an interesting read. I'd like to comment on what you're written here,

There does need to be a back lash against extreme programming, like any fad its only after people have used it and evaluated it, is it fully understood.

Extreme programming isn't a magic bullet, it is however a very powerful tool if you use it correctly in the right way. To put this into perspective,

I have worked for three years now for a development house which has adopted extreme programming whole-sale so I have quite a bit of experience in the methodology.

As this is an article on pair programming I'll stick to that subject not other interesting topics such as when Extreme Programming should be used, after all XP is a

methodology, and like all methodologies there are times when you would or won't want to use XP. For example, you'd never use XP on safety critical systems as it lacks rigor

but you certainly would use it for proof of concept projects.

At our Company we only use Pair programming about 50% of the time. I think this is weakness in your article, any agile method should only be used pragmatically, when it is

going to deliver benefit. Obviously there are occasions when certain pairs or the task itself are not suitable for pair programming. So buy another computer and do it on your

own. There is little point pair programming when the work is very simple and has been done many times before. Performing simple tasks would be your analogy of walking

across town. If the task was to navigate a car across London, then a second map literate pair would be very useful.

Pair programming should be used whenever the task is new, complicated or different, developers may know roughly how to solve it, what design patterns they are

going to use but don't know how its going to hang together. Here developers are implementing designs while they code and this is a very dangerous time. Bad designs produce so many headaches further down

the line, the concept of one developer thinking strategically and one thinking tactically is really true.

When you get onto true 'Voyage of Discovery' projects, then you're into the land of code Spikes. but we're talking pair programming now so I'll stay focussed.

Your hypothetical pairings miss out one very important scenario Expert-Expert. All our best, core code has been built with two of our experts programming together. Two experts together make very few

substantial mistakes and have the ability to design on the fly very elegant pattern oriented code even for 'Voyage of Discovery' category problems. The time saving for architecting that stuff right

is massive, the result is not only code that works, but code that is simple.

Everyone has mentioned it, but learning is critically important too. But interestingly its not just junior staff who needs to learn, its all your developers. By far the most damaging code changes we

have in our company is when one of our bright sparks goes off and rewrites a piece of our core code, then goes off for a week to meetings and customer sites and everyone is left with a major piece of application functionality

they need to learn how to use by looking at the code. (the darker side of refactoring) This isn't as efficient as the task being pair programmed and then its more likely an authority on that new piece of functionality will be around.

The statement that you think one indicator of good developers is that they want to work alone is interesting, IT projects now are larger than any single person, you need a strong, direct, efficient mechanism for

developers to communicate, if not pair programming then what? Of course, other modalities exist but there needs to be something.

One interesting thing Martin Fowler wrote a long time ago, to paraphrase: "I'm a good programmer with great habits". Habits is one thing you can instill into junior developers quickly (with the aid of a heavy stick, hehe)

Any process will take a while to teach people to be better developers, but pair programming quickly teaches people the process better developers use to develop (unit tests, refactoring, design patterns, etc).

As for recruiting Pair programmers, we use Pair programming as part of our interview process, we give people a task during the interview and they sit with our people and write a little code. We haven't had any problems

recruiting developers who want to do pair programming because most people are looking for the chance to do XP (because its sexy... or as sexy as IT gets) and most people want to code better.

Toby Sucharov

Pair Programmer (currently sat on my own)

Erudine

0 0