Pair Programming: Failure at Twice the Average Rate

From Wikipedia: Pair Programming

I came upon an interesting article on "paired programming" (WSJ).

Its described in the article as "two people sharing one desk and computer."

Now I can imagine why someone might think this is a good idea.  One of the two is lost in some way - perhaps s/he has poor communications skills, is young, less experienced on a given project, etc.

Pairing this person up with someone more experienced would bring them up to speed faster.

Ars Technica also has a recent article on a similar topic (see this): managing a developer with poor communication skills. Maybe paired programming would be a solution?

Let's look a bit below the surface here before we adopt foolish solutions like "paired programming."

What's wrong with little Johnny and his skills as a programmer?  Why does he need some sort of boost in the first place?

To understand this you have to understand what the notion programming is really about - which to some degree takes us back to my article on Agile Programming.

At its most basic level programming is the art of writing down a series of statements in some language that causes the computer to perform a specific task.

Let's for the moment assume this is happening naively and in a vacuum, i.e., no other programmers around.

To do this a programmer must understand quite a number of things:

- The computer language s/he is using to do the job.

- The problem to be solved.

- How the computer language can best be used to represent the problem and solution.

So in a general sense we can formulate a strategy: give the problem to the programmer, make sure he understands it, let him have at it.

But what happens in this simple model when he's "done?"

How does his boss or whoever provided the problem to solve know that he solved it and solved it correctly?

Today this is often accomplished via "unit testing" - some sort of predefined tests based on a description of the problem and the solution.  The tests have precomputed answers so we can simply apply them to the code little Johnny wrote and get a "go/no-go" result.

But think about this.  To write the tests one has to understand the problem better than the coder writing the code because to write a good test you have to think of "end case" scenarios were problems with data could tickle bugs in the written code.

Pretty hard if you haven't really looked at the code.

You have other problems as well - a tester and coder may understand the problem slightly differently in which case either the tests or code may be useless.

So what does "pair programming" add to this mix?

Not much that I can see - except doubling the cost.

The bottom line is that building a piece of software requires that before a single line of code is committed the entire concept of the total application being built must be completely understood.

Now notice I did not say completely "designed" or "specified."

And this is a key point.

If the collective "I" (the programming team) has a true understanding of the task at hand then its possible to create self contained consistent code because not portion of the task is unknown.

For example, if I am a builder adding an addition onto a house I can estimate what's involved but until I look inside the walls and at the roof rafters I am not going to know for sure whether the estimate I supply is good because I don't have a complete picture of what's needed.

What does looking in the walls accomplish - it removes unknowns and makes the entire project understood.

"Understood" does not mean completely specified.  For example, I might need a database with some specific properties - handle a billion 50K records, retrieve elements in less than 2 milliseconds, whatever.

Now I can understand that - but understanding that does not say if that is even possible to do.

So its possible for the "boss" to have supplied a project with is in fact not doable at all - understandable yes, doable no.

If you think of each project a programmer works on as a recursive set of subprojects, i.e., the top level project is to accomplish X.  X has five parts, X.1, X.2, ..., X.5.  Each of these is treated as a project.  Each may be made up of subprojects, and so on, and so on, ...., forever until you get to the bottom.

Now depending on the application there can be understanding at various levels of subprojects, i.e., reusing technology, etc.

Again, you have to work both from the top down - do I have all the understanding that I need.

And from the bottom up - is everything I understand to need doing doable at all?  And, if so, how?  From the bottom looking up you need to see that each thing is doable in a coding sense and technological sense and that, from above, you have 100% of the understanding you need.

Adding people to the mix doesn't in my opinion fix anything - in fact it makes it more expensive and complicated.

And then there is the notion of "preventing internet surfing."

The problem here is this assumes that a "programmer" has a complete list of totally thought out and fully understood things to do and therefore should always be just "writing code."

This is a problem though because it is virtually never the case that this is true.  There are always unknowns: boundary conditions, incorrect test cases, etc.

Sometimes a programmer needs "idle time" to think about this.

So let's take that away... what happens - probably even less gets done.

Without a well thought out and fully understood solution its likely the code will be bad or incorrect.

But if there's no time to think then there's a strong likelihood it will be wrong...

The bottom line here is that there are very few people who know how to effectively run projects and teams and complete software on time so that it works correctly.

Sadly as far as I can see its not taught in school.

So people invent solutions like "paired programming."

Personally I have always believed that the only effect model for managing programming is to promote the most able programmers to managers.  Of course, this requires that the programmer is ready and able to become a manager.

Again this does not happen.  Programmers should be taught that as you age your skill as a programmer is amplified as a manager.

But management requires both aptitude and training - again newly minted programmers from schools don't learn these skills.

Of course, most programmers have some geeky aspects to them.  But that doesn't mean they cannot manage.  It just means that they have to be "brought along" to do so.  But this is hard in a world where everyone changes jobs every year or two for more money.  In fact they are limiting their futures by doing this and hobbling employers with a very stratified development staff.

Like everything else in the country today the programming train is going off the track - if two programmers work well, why not three?

My experience with modern IT is that is basically an ass covering model.  No one wants to address real problems or, in many cases, even admit they exist (no one wants co-workers to "feel bad").  Then they spend endless time on justifying anything they do - to the point of silliness - in one case a company had a very poor product offering - to the point of receiving legal threats from unhappy customers.

Their response.

Diddling around for six months and not solving the problem.

What do they think their customers are doing in the mean time?  (Looking at competing products.)

All this is a consequence of making everything "fair" and "the same."

The emperor is not wearing any clothes...