Archive for September, 2009

10 reasons pair programming is not for the masses

Tuesday, September 22nd, 2009

Here is a wonderful article about pair programming, written by Obie Fernandez, from Hashrocket. The article doesn’t just cover a few politically-correct, well-known principles about pair programming that everybody already knows and nobody cares about. No, he goes WAY FURTHER than that and dissects why it works at hashrocket and doesn’t in most software shops.

As a result, he covers hiring, hardware, salaries, skills, etc… really, really interesting  !

A little excerpt :

This reason is related to #5 in the sense that most software shops don’t have enough good people to take responsibility for the truckloads of work that they’re expected to do. You can’t put idiots in charge of important projects, therefore pair programming requires double the amount of “good” people as not pair programming. 

A good example of why code quality will never be objectively measurable

Sunday, September 13th, 2009

I like this refactoring example a lot. As pointed out, trimming down functions to do “only one” thing is a widely known best practice, but one man’s “one thing” might be someone else’s “two things”.

So… come on with your metrics, guys! they’re probably never going to match the “WTF/min” metric of a human-being senior developer.

Convincing/evangelizing is a turn off, so what’s the key ?

Sunday, September 13th, 2009

I came across this interesting article about agile evangelism (thanks to Mathieu for sharing the link).

The conclusion of the post is that if you insist too much and try to convince others that your way of doing something [in this case, agile] is superior to their way of doing the same thing, you end up being seen as a freak. So his conclusion is to let people “learn from themselves”. So, in this scenario, I guess darwinism will then help determine the best alternative, as the inferior solutions will eventually die. awesome !

Now, let’s say you have some kind of interest in the success of the projects (involved in the project, somehow)  using an “inferior” solution that you consider threatening for the project.  What are your options ? The ones I see are :

  • Debate forever in the hope that the others will rally in favor of your solution. In his article, Grant Joung seems to think it’s just making things worse, and I can understand that religious debates do not lead anywhere, as nobody is likely to rally (have you ever seen a muslim convert to Judaism just because someone made a point against  islam during a debate ??)
  • If a few others also support your solution, and depending on whether it’s worth it, you can always attempt a putch on the project and just let the unsatisfied people go away, and end up dealing with those that agree with you
  • Quit (which ends up being the same solution as Grant Joung suggests). You definitely do not want to be part of something that you know will fail

Hmm.. It looks like none of the options I see is ideal… Does anyone have a suggestion ?