6

I'm working with a team of five developers working on a software product. The tasks range from very basic to rather complex.

There is no rule making it mandatory to use pair programming. The current practice is to ask to pair-program when one is facing a situation where pair programming would be beneficial: either an ambiguous or complex situation, or a case where there is a lot of logic or business rules which are not easy to understand or to transcribe into code, or a problem which may not be clear to understand later.

Some tickets clearly invite pair programming and are started this way. Some other tickets are simple, and are successfully performed by a developer working alone.

A few tickets, however, look simple, but as the developer is working on them, he discovers that the situation is much more complex. Usually, the discovery is not sudden, but grows organically. The original fifteen minutes of easy work become an hour of not so easy work, then two hours, then a day of a rather complex stuff.

I observe that in those cases, the developers usually remain alone, trying to persevere. It's only in retrospective that they notice that asking someone to come pair with them could have been very beneficial.

Why is this happening?

What should be done to ensure developers ask for help soon enough when they notice that the problem is more complex that it appeared originally?

It would be useful to note that when somebody from the team is facing a problem he cannot resolve, he would probably ask for help rapidly enough—likely within minutes after being blocked. The cause is therefore not the fear of looking incompetent or disturbing colleagues, but rather the inability to perceive the fact that the task became difficult enough, probably related to the boiling frog behavior.

Improve this question
2
  • What's your interest here? Do you not feel free to ask for pairing if you think it would help your work? Are you managing the team? If not, why are you trying to change its practices? And even if you are managing it, what is your specific basis for believing that pair programming will make these particular developers more effective in terms of net resource utilization on these particular tasks? If you are going to try to change things, you need very solid arguments in answer to all of these.
    – Chris Stratton
    Commented Oct 17, 2018 at 19:32
  • @ChrisStratton: my goal is primarily to understand the reasons of this phenomenon. I had my own theory, and the answers here brought a few other elements. The secondary goal is, as a consultant, to help the team to perform better. Given the lack of proper quality measurements in the company, the team is instead evaluated on a number of useless factors, including the time they spend doing pair programming. Understanding how the members should form pairs when blocked would directly improve this metric.
    – Arseni Mourzenko
    Commented Oct 21, 2018 at 8:56

3 Answers 3

Reset to default
2

Why is this happening?

Various cognitive bias are leading to this.

First, asking for help on a task that you started alone looks like failure. Many programmers are proud of being smart and managing to tackle problems on their own, they don't want to make this reputation fail.

Second, it is what is known as escalation of commitment : the more you have invested time in a problem, the more you are inclined to think you are close to its resolution. The programmer may have the false feeling it would be requesting help for something that's almost done.

What should be done to ensure developers ask for help soon enough when they notice that the problem is more complex that it appeared originally?

There are various ways to answer this problem, but my suggestion would be to have two developpers to qualify and agree on what is to be done in any given situation. This way, when the lone developper discover it grows out the scope, he or she can proudly report it's not as simple as initially thought.

Improve this answer
1
  • Excellent answer and I second the cognitive bias part, asking for help on a task alone looks like failure. It's a shame we have that kind of environment in software development and I have been considering moving full-time over to DevOps or Ops because I find more down-to-earth colleagues who are more honest with each others skill level.
    – Daniel
    Commented Mar 21, 2019 at 20:00
2

Unless they are losing more than 1 day, I wouldn't worry about it.

Its the nature of development. Sometimes the fix is a lot more complex than initially thought. The fact that you mention retrospective leads me to believe your job practices Agile. If this is the case, you should also be having stand ups. If someone is stuck on something they need to bring it to the stand up. If they do that, you have an in. Offer to help them with it, eventually they may get the idea that it could be solved quicker in pairs.

If they wont bring it to the stand up, there isn't really much you can do other than practice what you preach and hope it catches on.

Improve this answer
1
  • +1 don't sweat the small stuff, identify the problem in daily standup.
    – mxyzplk
    Commented Oct 20, 2018 at 22:46
1

I disagree with the notion that pair programming is better for more complex tasks.

Personally, I find it harder to focus and solve complex problems if I have to deal with the overhead of constantly communicating with another person.

Thus, for me, pair programming reduces the amount of complexity that I can deal with.

That's not to say I won't ask people for advice or second opinions from time to time, but constant pair programming simply does not work for me.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .