pair programming

There are 2 posts tagged pair programming (this is page 1 of 1).

Supersize Your Startup Dev Productivity


AttributionNoncommercialShare Alike Some rights reserved by Dav

Since I wrote the interview with Farhan of Xtreme Labs on Pair Programming, I have exchanged a number of emails on pair programming & developer productivity with some of Canada’s best developers. Most of them are pure gold that I am posting raw and unedited.

———————————————————————————————

“The main thing we like to stress on development is Test Driven development. We just find that it both ensures all the code is well tested, but also guides the architecture in a way that really improves maintainability. We use pairing in our interview process and also like to pair for the first couple of weeks to get developers up to speed, but after that we tend to split up work for the day and then attack separately.” – Jesse Miller, CEO of attachments.me

———————————————————————————————

“Whether to use pair programming or alone model really depends on the team personality and the kind of culture the leaders want to shape up. Some people do work better alone, and some prefer more teamwork.

Personally, I usually value teamwork more than individual results. At the end of the day, individual work will have to be integrated to form the end product, which is what really matters. There are too many examples where people think they got great ideas, but end up in epic failure during implementation. It is a result of not doing deep enough design validation. Coding alone is definitely more effective when you got the design details flushed out. Personally, when I am coding alone, I still ask for 2nd or 3rd opinions on a day to day basis. It forces me to think through the design again and again, which helps to refine my idea further. It is all about attitude. Never believe that you got it right until see the end product.

Another interesting thing is “pair troubleshooting” is more effective. When you’re trying to debug in an extremely stressed environment, it is always good to have some mental support and another pair of eyes.” – John Yuen, heads up dev for Fixmo

———————————————————————————————

“I think that pair programming does actually increase productivity, in most cases, and there are two reasons for this:

1. It keeps programmers from doing other things:private email, browsing, day dreaming, etc. I doubt that the average programmer actually spends even 50% of their time doing their job. If you can hire two developers, and get the work of one full programmer out of them, then I think, in a lot of cases, that would be an improvement. However, you could get almost the same result by pairing each
programmer with their own full-time low-cost supervisor who sits beside them to make sure that they’re actually working. This would be a lot cheaper and almost as productive, but the developers would find it insulting. This isn’t always the case of course; there are certainly many self-motivated, disciplined, highly-focused and productive developers who don’t need supervision.

2. Studies have shown that programmer productivity is limited, not by the time it takes developers to write code, but by the time it takes them to detect and correct errors. The limiting metric isn’t lines-of-code-per-hour, but rather, errors-debugged-per-hour. This is why Java is more productive than C++, despite the two languages being of similar expressive levels, Java’s runtime exceptions make it quicker to detect and recover from many times of errors, and garbage collection completely eliminates many other types. This is where pair-programming comes into play, if someone looking over your shoulder can spot an error as soon as it’s created, then that can lead to a lot of time savings. Maybe it would have only taken you two minutes longer to detect and fix a particular bug, but then gain, maybe it would have taken a week. Your partner wouldn’t need to early-detect very many problems in order to justify the overhead.

Maybe one developer sitting in a control booth, like a security guard, monitoring the work of half-a-dozen developers all at once, would be a good compromise between pair and pair-less programming.

Yes, it’s true that ACM programming contests are performed on only one computer, but you rarely have more than one person working on the same problem. While one is typing in and debugging their solution, the other programmers are working with pencil and paper solving their own problems (with occasional help from their team mates as required).

People are more important than any process or any tool. The best process is to hire the best people and a better developer is the best tool.

I half agree with what the original article says about hero developers. They say that you don’t need them, and that you’re better off with the a consistently productive 9-to-5’er. I think they’re
confusing heroes with heroics. I think that you do need heroes, but you don’t need the heroics of pulling all-nighters. Instead, you need the heroics of consistently creative and proactive problem solving which keeps you efficient, effective, and ahead of the game, day in, and day out. Effort should not be confused with results. I think they have the wrong definition of heroics, which leads to the wrong definition for heroes.” – Kevin Greer, Framework Lead at Redknee.

———————————————————————————————

Point #2 from Kevin Greer’s comments is widely unappreciated. Most people judge productivity by features and the “to do” list – when in reality it is not the to do list of features that usually makes projects late, it is the killer game of bug squashing, especially as you get to the stressful end of project delivery. Processes that reduce the upfront bug rate or increase the bug solving rate, even at the expense of adding features pay off quickly. This is were pair programming, test driven development, code reviews, architecture chats, etc all come into play. And why “pair troubleshooting” or other tools to debug problems fast are important. And also, use the damn debugger, it is there to make solving bugs faster.

I’d love to hear from more of the programming community in the comments. Tell us how you supersize your development productivity.

Is 1 the Loneliest Number?

Last week Tim Ferris, of 4 Hour Work Week fame interviewed the guys from Pivotal Labs and learnt the secret of their success – pair programming! It was a very thought provoking piece on how to get stuff done.

Well here in Canada we have our own super hot mobile dev shop, Xtreme Labs, @xtremelabs, who are absolutely killing it, picking up huge customers like GroupOn. The guys at Xtreme Labs are also infamous amongst the tech scene for being pushers of pair programming.

Now at Peek, where I’m CTO, we are all “Lonely Hero Programming” all the time. Our “bus count” is precisely 1. If somebody died tomorrow you know what I’d do? I’d hire somebody new!

The Best Way To Program - By Vinoth Chandar, Some Rights Reserved

So, being from this totally opposite world to pair programming, I wanted to learn a bit more about why a company would choose pair programming, and I thought I’d start up a friendly dialogue with Farhan Thawar of Xtreme Labs to gather this thoughts.

Dan: Hey Farhan, how are things? I’d love to hear more about how you guys program at Xtreme. How are you setup?

Farhan: Our work environment is what I call an Agile Team room. Super low cubes, everyone in one area, with programmers focussed in a particular technology seated close to each other (so iOS devs sit together, Android devs sit together, etc.).

Dan: I’m going to start right off the bat with some basic math. If I have two people solving one problem versus two people solving two problems, doesn’t that automatically make me less productive? You know 1+1=2? How can I as a lean running startup afford to be half productive???? You guys have to pay your 2x workforce in real cash, right?

Farhan: So the simple math is misleading, i.e. that 2 programmers working on the same task is less effective. For example, most agile shops typically get 4-5 hours of coding done per day. The rest is spent in email, meetings, Facebook, Twitter, Youtube, reading blogs, etc. With pairing, we can focus our folks for 8-9 hours together to get a full days work done. Yes, it’s 8-9 hours / 2 = 4-4.5 hours of coding each, so at a minimum it’s the same hours. However, we have instant robustness (bus count), higher quality (i.e. less hacking), instant knowledge transfer (two people touch every line of code).

Dan: I am a programming god. I go on tears for 2-4 weeks where I am an absolute machine. Knuth himself would have a hard time keeping up with me as I weave around in my language du jour (i.e. Haskell, gods only program in Haskell.. the language of the heavens). The last thing I need is some assclown developer tethered to my leg slowing me down. How do you handle god coders like me in pair programming?

Farhan: Lol, badass programmers get better by pairing, just one example: http://cycle-gap.blogspot.com/2007/09/extreme-pair-programming-guy-steele-and.html. The reason is that it’s an intense learning environment, much like apprenticeship in the old days (you apprenticed to learn your trade). There’s no better way to get better and faster at your trade than to work with someone else who is as smart as you are.

Dan: How does this work if you work on a lot of projects? What if you are doing maintenance on a few projects as well as new dev’t on another project? We have lots of guys who probably touch 2-3 projects on any given day? Do they have to find their pairing buddy for each project every time?

Farhan: So the key is to not swap projects often. Almost 100% of our pairs are on a single project for the entire week. So week to week things my change (most time they don’t), but our devs are focused just on one project, on one platform. We do have R&D pairs and a Sustained Engineering pair who focus on multiple updates and fixes, but they aren’t dedicated full-time to any project. Folks also don’t find a pair, they are allocated before the week starts. We take tons of feedback on pairings and it’s very easy to see pairs that aren’t working well (they don’t talk much, or one person is driving the whole time)

Dan: In a debate in my company a great coder I know basically said something like this “don’t most coders do pair whiteboarding/pair designing anyways? By the time it comes to actually coding, isn’t that the trivial part?” Lets pretend this is a law office or consultancy shop, would you pair (i.e. do teamwork) at the strategy phase/problem solving phase or would you pair during the document creation phase?

Farhan: So the coding isn’t the trivial part, as the end product is based on the code. It’s almost like saying the ingredients and the recipe are the hard part but the cooking is trivial. It’s not (and I know, cause I can’t cook for shit). You want to write code that is elegant, understandable, maintainable, etc. and pairing forces that as two people have to understand what is going on at all times.

Dan: Have you guys ever tried doing like a race? Put two coders doing 1+1 vs two coders pairing on the same project? Should we try to sponsor this type of event?

Farhan: Bring it. We’d love this. Don’t forget, ACM programming competitions only use one computer :)

Process Matters

So here’s my take overall. Process matters. Even for dev teams of 1-3 people selecting the right language, technology, tool chain, and software process make a big difference in productivity and quality. Software engineering has improved by leaps and bounds over the past 5-10 years. Here are some of the best changes:

  • Opensource software and the explosion of re-usable software components
  • Iterations and demos
  • Continuous Integration, build servers and automated test suites
  • Continuous Deployments, i.e. the newer devops movement
  • Explosion of tools & infrastructure in the build, test, deploy area (think of tools like Heroku, Chef, Capistrano, build tools, etc)
  • Test driven development, test automation & significantly improved testing frameworks

(Sometimes I write in ANSI C on proprietary embedded plaforms, where the tool chain and quantity of re-usable code is a fraction of what I want. You take for granted how much Java, Ruby on Rails, Python, PHP, etc have been built up.)

These days, I rarely come across startups that haven’t adopted most of the above to a certain degree. And pair programming, truthfully its just not widely adopted compared to the list above. To me pair programming seems to be an overkill solution to solve the real programming productivity problem – communication. Engineers are classically trained to solve problems independently (though this is changing at the university level finally). Dr Amol Sarva, CEO at Peek, always mentored me with the following advice on communication, picked up during formal structured problem solving training at McKinsey.

“Basically there are three stages of any problem where one can communicate and practice team work:

1. Structuring – during framing of the problem. What are the steps I am going to take to solve this problem? Read the internet, talk to an expert, write quick hacks to test it, etc.

2. Solving – during solving the problem. “Hey, I did this and this and here are the raw results, interesting, right?”

3. Synthesis – communication while synthesizing the results of problem solving. “Hey guys, I solved this, here’s how. Code is checked in.”

Engineers classically wait until synthesis to solve the problem. Which is too late. Others, (e.g. your classic ice-breaking consultant) do too much communication during structuring.”

Pair programming forces engineers to communicate much earlier on in the problem solving process. Which is good! It also forces them to communicate across the whole problem solving spectrum from structuring to synthesis. Also good! But god it sure feels like an inefficient oversolve to the problem. Managers can bake in communication to their dev process without forcing pair programming in my opinion.

Having said all that, I am always willing to try something new (good engineering demands experimentation and learning), so we are going to try pairing it up on a project at Peek and see if it works well or not. I’ll report back the results.

I’d love to hear what others think. Is pair programming the real deal, have you found it to be more efficient in getting your code on? Or do you like to pound it out solo with headphones and your favourite hoodie?