Agile Zone is brought to you in partnership with:

Programmer, solution architect, user group and conference organizer, conference speaker and traveling fun code evangelist. Johannes tries to apply Agile principles to large software projects, but what he's really passionate about is sharing the experience of more fun programming with other coders around the world. Johannes is a DZone MVB and is not an employee of DZone and has posted 37 posts at DZone. You can read more from them at their website. View Full User Profile

Pair programming with Sankalpa

06.28.2014
| 4965 views |
  • submit to reddit

One of my favorite ways to develop software is to do it together with others. Pair programming has always been a motivating and fun activity for me, but some pairings work better than others.

When our team was formed we decided to pair program and rotate partners every day. I had lots of fun programming with Milina, Asanka, Manoj and Chamath, but my favorite session was the one I had with Sankalpa. In this session, we achieved something that we would be helpless to do alone.

The task Sankalpa and I was working on was to include information from a calendar in Confluence in a date picker in a web application. As we sat down, I was dreading the integration part. Integration is often dreadful. More than anything, I wanted to hide from the problem. But with Sankalpa sitting next to me, I didn’t feel that I could give up, so I suggested we took a look at our Confluence calendar to get started. Sankalpa was at the keyboard and he found a “calendar feed” where I hadn’t thought of looking for it.

Looking at the feed, I exclaimed “Oh, I know this – this is vcalendar”. A quick Google later and we had found a library for parsing vCalendar in JavaScript. We quickly finished the code to adapt it to our desired format and moved to the date picker.

I was at the keyboard and I had used a date picker library called jQuery datePicker before. We quickly integrated it and I proudly refreshed the page to show the calendar events in the view! But it turned out that all the functionality that depended on picking a date was now broken.

I started grumbling about how I was much more comfortable with jQuery than with AngularJs. Unfazed, Sankalpa mentioned that Manoj had gotten the date picker to work with AngularJs in an earlier project. “Hey, Manoj, where did we use this date picker?”

Having much more experience with AngularJs than me, Sankalpa integrated the code into our code base and everything was working.

All in all, I had expected this to take 2-3 times as much effort. If we had been alone, we would probably wouldn’t have the courage to start with the integration right away. If he had been alone, Sankalpa probably wouldn’t had known how to parse the vCal feed. If I had been alone, I probably would have searched the Internet for hours to find out how to make AngularJs play well with jQuery date picker.

Together, we did what neither of us could have done alone. (At least not anywhere close to this quick)

Published at DZone with permission of Johannes Brodwall, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Dave Glasser replied on Sat, 2014/06/28 - 6:01pm

As we sat down, I was dreading the integration part. Integration is often dreadful. More than anything, I wanted to hide from the problem. But with Sankalpa sitting next to me, I didn’t feel that I could give up, so I suggested we took a look at our Confluence calendar to get started. Sankalpa was at the keyboard and he found a “calendar feed” where I hadn’t thought of looking for it.

[Emphasis added.]

I don't mean to be a troll. Really. I don't.

But this is pathetic.

I think pair programming is a dumb, inefficient practice. I've been saying it for years.

No offense, but I don't think your problems are solved by pair programming, I think they're only papered over.

I think your problems would be better addressed by getting more knowledge, more skills and more experience. Having those, in turn, would give you the confidence to tackle the trivial tasks you describe above all by yourself.

And if the other programmer has equal skills, knowledge and confidence, you can both work separately on two different tasks, at the same time! The two of you would be twice as productive!

What a concept.



Johannes Brodwall replied on Sun, 2014/06/29 - 4:41am in response to: Dave Glasser

Dave - your comment contributes nothing but negativity to the conversation.

Your offer no experience or information, only gut feeling and a poorly reasoned analysis. I do not care about your opinion, and you do not offer your experience. If you have been called a troll before, this is probably why.

Do not comment on my articles again unless you understand and accept this criticism of the style of conversation in your previous comment.

Dave Glasser replied on Sun, 2014/06/29 - 11:39am in response to: Johannes Brodwall

Dave - your comment contributes nothing but negativity to the conversation.

I disagree. I think my comment contributes a sorely needed alternative perspective on the overhyped and oversold practice that is Pair Programming.

Two programmers collaborating and sharing knowledge is one thing. But having 100% Pair Programming imposed by management is ridiculous.

The economic aspects should be obvious. Compared to Pair Programming, it is less costly, and therefore more efficient, to assign a task to a programmer who is capable of completing it in a reasonable time, on their own, acquiring any knowledge they need along the way. Unless the salary of the single programmer is twice that of each of the paired ones, in which case it would be comparable. Unfortunately, it's been my observation that the distribution of programmer salaries is not as wide as the distribution of programmer capabilities.

In my view, Pair Programming is an embarrassment to the profession of software development. Two journalists may work together on a single, long, magazine article, but they're not sitting behind the same keyboard working on the same paragraph at the same time.

And I would not want to be operated on by a surgeon who had once expressed how much he dreads the sight of blood.

Lund Wolfe replied on Sun, 2014/06/29 - 10:58pm

I think this is a good example of doing something because it works.

I'm not a pair programming fan.  It reminds me of decision by committee.  At the same time, I think it can be very efficient and do less harm than one developer can do by himself.  This is a business where, almost by definition, most of us are in over our heads.  We don't know everything or care about everything.  Two people working together can accomplish the task much faster than one trying to get up-to-speed on the half he doesn't have experience with.  It's also probably faster than breaking it up into two, possibly unnatural, subtasks and integrating them later.

Dave Glasser replied on Sun, 2014/06/29 - 11:35pm in response to: Lund Wolfe

I think it can be very efficient and do less harm than one developer can do by himself.

There are, unfortunately, developers in our industry who are as likely to do harm as make a net contribution on any given day. If they're clueless incompetents by themselves, I don't see any net gain from pairing them with a competent developer. I think it only masks their incompetence, by creating the illusion that they're adding value to a project.

This is a business where, almost by definition, most of us are in over our heads.

I'm not sure what you mean by that. Could you elaborate a little?

Two people working together can accomplish the task much faster than one trying to get up-to-speed on the half he doesn't have experience with.

Two points in response to that: First, in the enterprise IT world where PP seems to have the most foothold, isn't it mostly developing CRUD screens using the same technology day in and day out? I'm not saying a developer won't ever have to get up to speed on some new, daunting technology, but I don't think it's an everyday occurrence. It sure wasn't when I was in that world. Most of the stuff I had to do, I could knock it out in my sleep.

Second, in the example given in the original post, the happy ending occurred purely by chance. It was just the luck of that day's rotation that he was paired with someone who was well-matched to the task. He probably could have gotten the same result by asking his teammates, "hey does anyone have any experience with XXXX and YYYY? Could I pick your brain for a few minutes? It may be even have resulted in he and Sankalpa sharing a keyboard for a few hours, tacking the problem together, as he described above. It didn't have to be Official Policy in action. The absence of pair programming does not imply the absence of collaboration.

Johannes Brodwall replied on Mon, 2014/06/30 - 12:11am in response to: Dave Glasser

Dave - I told you that your behavior is unwelcome here. I have asked the curators to remove your comments. Please refrain from further commenting.

Lund - thank you for your comment, but please do not feed the troll.

Dave Glasser replied on Mon, 2014/06/30 - 7:27am in response to: Johannes Brodwall

 Johannes, I've saved a copy of the page and the comments. My words will live on. If not here, somewhere else, where they'll be seen by a lot more people.

And I think any fair-minded person would agree that there's nothing wrong with my "behavior". I just gave my own brutally honest opinion of PP and your post. My intent wasn't to offend you. It was your own words I was commenting on.

Benjamin Ball replied on Mon, 2014/06/30 - 10:56am

Hi Johannes and Dave,
We don't delete comments unless they're truly hostile, and I don't believe that was the case here. We want to encourage discussion and engagement at a deep level that often includes people of wildly varying opinions, which seems to be the case here. I don't think Dave meant to offend, and I want to remind everyone that while we don't censor posts, we very much encourage that we keep comments in a constructive range. Thanks.

Aaron Holmes replied on Thu, 2014/07/03 - 9:47am in response to: Dave Glasser

Interesting take on pair programming... It sounds like you might have been involved in an environment where pair programming was mandatory regardless of whether or not it was practical and it must have been torture. 

I think issues arise when people try to find silver bullets and blindly prescribe methodologies, tools, practices, etc. without taking into consideration what needs to be accomplished. 

I'm actually an advocate of pair programming but I tend to use it sparingly - 2 hours or less a day. I've had some good things come from this:

- Developers have a habit of working in silos and 'disappearing' for periods of time. This can be problematic when knowledge transfer does not occur between developers or when they go off and build what they thing needs to be built and not what the stakeholders actually need. Pair programming has helped the teams I lead to avoid some of these issues, and usually increases overall team engagement in a project. I've found that most programmers that I interact with have the required technical skills, but often lack the necessary communication skills to really work effectively within a team. 

- Programming by definition should be time mostly spent on working on things that are new and have not been done before (otherwise we would have better success with things like code reuse and automated code generation). Pair programming helps an individual to get over some of the mental hurdles in new work and usually improves quality along the way. I find this to be mostly independent of programmer knowledge / skill level and have seen many cases where a junior dev will influence the design and teach the old dogs a new trick or two :) 

I think the problem you are mentioning is a bit different though - saddling good developers with bad developers just to mask poor skills has an obvious overall negative impact. At that point I think you have to address the real problem and either develop the poor quality programmers or replace them.  Practising pair programming just because it's in some agile book is also silly - you could get these benefits from some other method (peer reviews, scrums, etc.).

Just my ramblings - I think the article presented a good recap of a successful pairing session. Both developers appeared to be happy with the outcome and accomplished the task successfully As a result I think that pairing should be accepted and actively encouraged. Speaking as a manager I think that we should mostly get out of the way and just offer gentle guidance instead of forcing our methods onto others. 


Dave Glasser replied on Thu, 2014/07/03 - 3:23pm in response to: Aaron Holmes

I'm actually an advocate of pair programming but I tend to use it sparingly - 2 hours or less a day.

Out of curiosity, how does that work?  If two programmers are working by themselves, on two separate tasks, do they, at some appointed time, stop what they're doing and pair up on a single task? Even if they're both cruising along nicely on their own?

And reading through your rationale for PP, I notice that it can be summarized as, "PP helps counteract the effects of various programmer deficiencies." I realize the deficiencies you mention are not uncommon, some even among above-average developers. However, I think there are better, more direct, less oblique ways of correcting them. It's not even obvious to me how PP would help, but if you say it helped in your organization I'll believe you.

And finally, there are the fabled 10x programmers. IMO, these people will, without exception, be hobbled by having someone breathing on them while they try to work. IMO, their output is too valuable to let anything impede it. And I suspect few of them would put up with it for very long.

I don't claim to be a 10x programmer, but:

A.) I love programming, and
B.) I do it best when I'm able to focus intently on it, and
C.) the only thing that makes it difficult for me to focus is external distractions, like for example, someone sitting next to me looking at my screen or talking to me.

PP, I'm quite sure, would not make me more productive, only less. And I would not enjoy it, so I would not stay long in any job that required it. (The chances of that ever happening are next to none, anyway.) And I would never use it on my own team to mitigate developer deficiencies. If there's a problem with a developer that cannot be resolved through direct management, I'm sure not going to devote the time of a good, productive developer to resolving it. I would rather replace the problem developer with one that doesn't need a pair to work effectively.

Aaron Holmes replied on Thu, 2014/07/03 - 9:44pm in response to: Dave Glasser

There are no hard and fast rules, and there should be no absolute requirement to pair at any time so in your example if the job is getting done well then it wouldn't make sense to force shoe-horn pair programming into the process. For me, I find certain tasks work better done in a paired environment so I'll just leave them for that time. If I'm fleshing out an architecture or coming up with something that others will have to use I usually like to have a second pair of eyes on my work and at least a second opinion.

Productivity is also a funny one - many programmers tend to look at productivity as a metric of raw work generated (even something as simple as lines of code written or tasks completed). I've seen many a programmer disappear and work in their own bubbles in the name of productivity, but when they return they've ended up producing a lot of code that accomplishes the wrong things / has the wrong assumptions. This problem grows exponentially depending on the size of the task / time required and the amount of isolation they've had. Pair programming could help with this, although it's just one tool in the box. 

Also, I think we're trivializing programming a bit here. Developing an application of any substantial size / complexity is <strong>hard</strong>. At some point in the process you're going to have to rely on the strengths of your team to get the job done. Effective communication skills and teamwork become at least as important as raw technical prowess. 

Think of this scary situation - let's presume we have a wizard programmer and she only works well alone. She finishes a bunch of tasks but there ends up being an information silo because only she knows how large parts of the system work. Ultimately, everyone else on the team produces at a slower rate because of this (even if they have the technical know-how, picking up someone else's logic takes time and can be difficult). I've seen extreme cases where the gurus refuse to let others in on their work at all and the overall net productivity of the team can be less than if there was no wizard on the team to begin with. In this case, bringing in a process that makes the individual less productive but the team more productive is a net win for the business. 

Ha, sorry for the long winded replies. I like discussing differing viewpoints and seeing how other people like to work. I'm not a pairing prophet coming down to convert people to my ways so don't take things that way. 


Dave Glasser replied on Sat, 2014/07/05 - 5:30pm in response to: Aaron Holmes

I've seen extreme cases where the gurus refuse to let others in on their work at all and the overall net productivity of the team can be less than if there was no wizard on the team to begin with.

Aaron, virtually everything you describe has to do with using pair programming as a remedy for some sort of programmer or team dysfunction. Maybe you should stop for a moment and ponder why you have so much dysfunction to deal with.

I have seen developers who were loathe to share knowledge with others, because they saw it as a sort of wealth to be hoarded. They apparently thought knowing things few others knew made them more valuable relative to their teammates. But they were far from "gurus" in my view. They were of average programming ability with way above-average insecurities. Had I been their supervisor, I would have told them to start answering their coworkers' questions to the best of their knowledge or start looking for another job.

I do think there are some things that are fundamentally broken in software development, as a profession. And I think they stem from the fact that too few programmers feel significant pressure to really be at the top of their game in order to keep their jobs. Because of the shortage of talent, it seems almost anyone with a modicum of ability can get a job in software development, bringing down the average level of ability. And the proposed remedies seem to all be about how to get above average results from a group of average developers, rather than how to build a team of talented, dedicated, socially well-adjusted developers who can produce stellar results with a minimalist management approach.

Lund Wolfe replied on Sat, 2014/07/05 - 9:53pm

Dave, You are making me play the devil's advocate defending average developers.  I'm the last person to suggest pairing or otherwise slowing down a strong developer.  I think that is a separate issue belonging in a programmer competence article.

I don't know what your team experience is, but I personally have seen very few strong developers.  It is only pragmatic to build software that needs to be built with what talent is available.  Much of this programming is not repetitive CRUD screens either.  We don't have to look very far to find poor code, poorly designed apps.  It's usually the good ones that stick out like a sore thumb.  I think that's our first clue that most of us are in over our heads.

I think it's safe to say you can forget about hiring a strong developer and concentrate on minimizing the damage done by average or worse developers.  I'm not suggesting that two heads or ten heads are better than one, but I take it as a given that they will do less harm together than apart, and that is the best of all possible/real worlds.  In my opinion, it really is about risk management and building software that is "good enough".  This in itself is a challenge, apparently.  If software development is easy and obvious to you, then you may find this type of thinking humorous or just pathetic, but you would also be in a small minority.

Regardless of skill level, some developers and some pairs do work very well together.  Absolutlely, I wouldn't mandate it, but I certainly wouldn't discourage it either.

Andrew Thorburn replied on Sun, 2014/07/06 - 9:04am

I think your problems would be better addressed by getting more knowledge, more skills and more experience.

So what do you think he's doing by pair-programming? Gaining knowledge and skills. Might not be the most efficient way to gain those things, but it's still happening. Well, assuming he paid attention and didn't just close his eyes while the other person did their magic.

I don't do a lot of pair-programming, personally. Company is too small for it. But the main reason I see for it is knowledge transfer (e.g. someone new has joined the team, and they need to be brought up to speed), and it probably shouldn't be a thing you do all day, every day. Is it the fastest way for someone new to learn? Maybe, maybe not. Depends on too many variables. In an ideal world, there'd be documentation, examples, unit tests and whatnot, so it'd be a wash, best-case scenario. Thing is, the world's not perfect, and sometimes you don't have these things. You don't have comprehensive, up-to-date documentation. You don't have sample code. You may (God forbid) not even have unit tests.

So what do you do in that situation? Hope they pick up the knowledge by osmosis? Not many people can do that (I'd like to think I can). So what do you do, living in the real world? Pair programming is not a bad solution to this, and may be the best way for some people to learn - not all, but some.

Dave Glasser replied on Sun, 2014/07/06 - 11:19am in response to: Lund Wolfe

I think it's safe to say you can forget about hiring a strong developer and concentrate on minimizing the damage done by average or worse developers.

I disagree wholeheartedly. If you pay well above the local market rates, you will attract some of the top-tier developers in the market. Most will be already solidly employed, so you have to make the offer high enough to lure them away from their current job and discourage counter-offers by their current employer.

Myself, I don't have the patience to spend my days trying to "minimize the damage done by average or worse developers." If a developer imposes that burden on me, I fix the problem by firing them. Then they become someone else's problem.

Your post, Lund, only affirms what I wrote earlier, to wit, "I do think there are some things that are fundamentally broken in software development, as a profession." The slugs that you describe go on their merry way, staying securely employed, making good money, while someone else has to "minimize the damage" that they do.

Think about that.

If you were laying in a hospital bed, how would you like to wonder whether or not the nurse sticking needles in you and giving you powerful drugs was the one whose "damage" everyone else had to try to "minimize"?

I think the software development profession has far too much tolerance for the kind of incompetence you describe. And I understand that you're only trying to do the best you can with the resources available to you, but in the big picture I think your approach only serves to perpetuate the problem.

If the real incompetents were continually being culled from the ranks of software developers, then the average would go up. And the fact that employment wasn't a given might be an incentive for the below-average to work harder to improve their skills.


Lund Wolfe replied on Thu, 2014/07/10 - 3:31am in response to: Dave Glasser

Software development is serious business, and we should treat it more seriously than putting nuts on bolts.  Hire one or two good developers, not ten mediocre ones.  This is a business decision.

You may well be right about having enough talent available given the right incentives, like environment and sufficiently high pay.  I'm sure those conditions are being met in a few places with mutually beneficial results.  There is also a matter of matching the conditions with the developer, though.  I like to think talented and mature individuals can work together but personal preference may be a significant factor, too.  There also seems to be a lot of debate about how to filter in all these talented developers from the list of candidates.  This is a very hard job to do, too.  Who is qualified to do the hiring ?  Again, you may think this is easy, but it is only easy (to do well) for a very few.  Admittedly, the hard part is getting started, and that may be a roll of the dice.  Once the ball gets rolling, you may just get more of what you've got, good or bad.  We can't get there because we're not there yet.  It's a very steep curve or barrier to entry for the business.  I'm only saying that these are very significant challenges/risks for the business, regardless of it being the right thing to do.

I'm not enough of a snob to think that software development should be reduced to a trickle because almost everyone should be fired for incompetence.

I think it is more a matter of intelligence, natural ability, and attention to detail than level of effort or work ethic, so raising the average is still going to require filtering out the bottom x percent.

I'm guessing that a hospital has constraints, regulations, processes to prevent serious accidents by nurses so that they can almost do their job in their sleep.  Mistakes are followed by new rules.  I could be completely wrong.  Nurses are well paid for a reason.  I'm sure some nurses and doctors are still much better than others.  Constraints and processes are also used in software development to minimize damage and make the resulting output more even and predictable.  This is very questionable but understandable.  We need a lot of nurses and a lot of teachers.  We also need a lot of software developers, or at least there is demand for a large quantity of developers.  Maybe this is wrong headed, but I don't think it is going to change anytime soon.  Like you said about something being fundamentally broken in software development, a crying baby (or a growing business) only knows that it needs.

Dave Glasser replied on Thu, 2014/07/10 - 9:59am in response to: Lund Wolfe

There also seems to be a lot of debate about how to filter in all these talented developers from the list of candidates. This is a very hard job to do, too. Who is qualified to do the hiring ? Again, you may think this is easy, but it is only easy (to do well) for a very few.

To the contrary, I don't think it's easy, and if I gave that impression I didn't mean to. It's not easy, in fact it's quite difficult, but it's not impossible.

Here are some observations I've made in a decade of hiring developers:

1. If I go against my gut feeling and hire someone I have doubts about, hoping they'll be the kind of developer I'm looking for, my gut is almost always proven right.

2. You know very quickly if you made a good hire or not, within a few weeks. The traits of a good developer go way beyond their depth of knowledge in a particular set of technologies. The ones that are at the top of the heap are there because they have a burning desire to be at the top of the heap. I think practically everything else flows from that.

3. Developers are what they are, and you, as their manager, are essentially powerless to mold them into the coding dynamo you'd like them to be. Only developers can do that to themselves, if they have the desire. (The majority don't.) When someone enters the software development profession, they quickly settle into their spot on the bell curve of abilities, and pretty much stay in that spot their entire career.

4. I think this applies to most employees, not just developers: When someone just isn't cutting it for some reason, and you have "the talk" with them, i.e. "shape up or ship out" (or be shipped out), it's almost always a formality, and you end up parting ways with them shortly afterward. They may improve for a short time, but soon settle back into their old patterns. I've seen exceptions to this, but they were extremely rare.

Johannes Brodwall replied on Thu, 2014/07/10 - 10:33am in response to: Dave Glasser

I have seen stark exceptions from your observation #3, but mostly when teams use pair programming. Developers will benchmark themselves against each other and if handled well, a manager can use this as a motivating factor for everybody to improve. Even the best developers will find things they can learn from their team.

Dave Glasser replied on Fri, 2014/07/11 - 1:10pm in response to: Johannes Brodwall

I have seen stark exceptions from your observation #3, but mostly when teams use pair programming.

Johannes, that leads me to wonder, in a shop that does 100% pair programming, how do you even accurately evaluate the value an individual developer provides? They may seem either more or less effective than they actually are, depending on who they're paired with. For reasons I already described in this thread, I'm sure I would be less able to concentrate and think through difficult problems with someone sitting next to me, talking to me, watching me, or, worst of all, typing on the keyboard in front of us. I think the only way to accurately measure someone's ability it to measure how well they handle various tasks all by themselves.

I recall a project I was on in 2000. Upper management insisted that bodies be thrown at the project, so my boss was hiring as many serverside Java contractors as he could. The team size was, at its peak, around 40 developers. And of course, every contractor the body shops sent to us was purportedly a seasoned expert (even though Java was still relatively new) and we were paying top dollar for them.

Anyway, one contractor seemed to not show any perceptible progress on his assigned task, day after day. When called on it, he had a million excuses. While letting the contractor continue, and without saying anything to the contractor, my boss gave the exact same task to one our in-house "junior developers", a young guy not long out of school. He had it wrapped up in less than a day, while the contractor continued to flail about. (But it was not his fault, of course.) My boss told the contractor to take his stuff with him and get out, and not come back the next day. Then he called the contractor's employer and ripped them up and down for sending him a supposedly vetted expert who was actually an incompetent buffoon.

That contractor probably would have hung on a lot longer than he did, if we were a PP shop. He would have wasted money and other project resources.

I have no doubt whatsoever that contractor is still working as a developer today, if he still wants to be. That's one of things wrong with our profession.

Lund Wolfe replied on Sun, 2014/07/13 - 11:26pm in response to: Dave Glasser

You do occasionally have to work with an internal or external clown developer, whether it be Java, C#, or whatever.  That's when you can appreciate a "mediocre" developer.  It is all relative.  Fortunately, these are pretty easy to filter out if you ask any technical questions.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.