Showing posts with label pair programming. Show all posts
Showing posts with label pair programming. Show all posts

Sunday, December 17, 2006

Big Screen

Martin Fowler in his recent blog post about big screen emphasizes the importance of the workspace size, as in the size of the screen. He says that you cannot see much on a small screen and must switch between windows that overlap each other. I totally agree with him.

I was lucky enough to work at companies that could afford spending a little extra for the benefit of increased productivity. At Siemens I had 21" monitor, which was the biggest you could get at that time. Then at 3D3.com, I had two 17" monitors, which was again an excellent choice (one screen for programming, second screen for running the app/testing).

Fast forward to present, I work at Atlassian and the choices are great. If you work fulltime you can choose between a huge 24" widescreen monitor or TWO 20" widescreen monitors. When I got my 24" monitor, the pair programming just got better.

I use a laptop at home and I used laptops for work at MSC and Agreon. I never had any problems with my eyesight. Except the time when I worked for Agreon and used a Dell laptop. My eyesight got worse and I had to wear glasses at the end of the day as my eyes were strained. Now at Atlassian, with 24" monitor in front of me, I don't need to use my glasses any more. My vision is just fine. (It must've been the screen of that Dell laptop, IBMs and Toshibas are fine) If you use a laptop, at least ask for a stand so you raise the screen to your eye height. A simple bookstand will do as long as it is strong enough. Anyway, laptops are no good for pair programming.

So a big screen is good as you can display more valuable information on the screen. However, one screen still does not save you from application switching. If you are lucky enough to have two screens, you know what I am talking about. It's just a pleasure not to be forced to switch between apps as you can easily have one on one screen and the other on the second screen. A typical scenario is coding and running the (web) application, or coding and reading documentation.

At Atlassian we take turns in support. A developer from each team takes a fortnight turn to join the support team. We usually move to support area (so we can be close to the members of support team). We have a dedicated "support desk", which has all hardware necessary. The only piece missing is the computer that the developer brings along. The monitor on support desk is a 24" widescreen monitor.

When people move to support they bring their own desktop computers. I drag my monitor as well. It's the same 24" monitor and I always think that it'd be a waste to let it sit unused on my "dev" desk for two weeks. I hook it up and voilá! Two 24" widescreen monitors give me the greatest work space I can get (for now). I gotta tell you, it's really fantastic to have these two screens. You can be digging in the code on one screen and doing something else on the other screen. I usually have a virtual machine running on one and a browser in the other. No switching, no overlapping windows.

If you want to see me in action with two 24" monitors, have a look at these videos about Atlassian and my bosses Scott and Mike [mp4] or [wmv] (around 1 min 40 sec).

Tuesday, June 27, 2006

Pair Programming Habits

I finished reading Pair Programming Illuminated, a book written by Laurie Williams and Robert Kessler. I talked about this book in my previous blog: "The Seven Myths of Pair Programming". I really enjoyed reading this book. It's time to put it back the shelf, so other developers in our office can get their hands on it, but I am sure I will come back to is sometimes. I want to talk a bit about one of the chapter at the end of this book.

Seven Habits of Effective Pair Programming

Habit 1: Take Breaks

This was one of the things that we identified early on. Pair programming is a very intensive activity. We worked in pairs whole day. And then at the end of the day, exhausted, we were still in the office catching up with the pile of e-mails and other administrative stuff. Take breaks on regular basis. Have a coffee, tea, talk to other developers, stretch, do whatever - simply, have a break!

Habit 2: Practice Humility

One of my favorite quotes that I use on daily basis: "Pair programming makes me feel stupid everyday. I love it!"

Habit 3: Be Confident / Be Receptive

Do not be afraid to appear dumb. Nobody expects you to know everything. You do not expect the others to know the answers to all your questions, do you? And remember, this is a teamwork, not a competition.

Habit 4: Communicate

This is very important. Today I had an encounter with one of our staff. He is not usually exposed to pair programming that we practice in our team. He came over to my computer and typed commands rapidly on the command line. No words said. I could not follow him. I was not experienced enough in that particular area and wanted to learn from him, so I asked him if he could comment what he was doing. I felt stupid again... but hey, I learnt something!

Habit 5: Listen

This is important as well. We all dive deeply into our thought when we type away our code. Sometimes I found myself not really listening to the navigator. When I finished, I had to ask what he said and reiterate thought his thought.

Another case is when you listen but assume you know what he or she is going to say. Do not assume. Listen! If he or she wants to say something, there is probably a good reason for it.

Habit 6: Be a Team Player

No much to be said here. Just be part of what is happening. Be actively involved in the process, whether it is coding or just thinking as a navigator. You need to be able to understand what is going on at any moment. If you don't, ask!

Habit 7: Hone the Balance between Compromise and Standing Firm

It's hard to find balance if you try to go separate ways. Always think that this is a teamwork and the way the project should be heading.

Friday, June 16, 2006

Pair Programming and Office Environment

Everyday I come to the office and I see people working. We all work in different ways. Sometimes we work by ourselves, sometimes we pair up to work together on a card we pick from the wall (card = task from the story board). These two ways of working are very different and I would like to share my thoughts on them with you.

Caves

People need privacy. They need to take or make phone calls or do some other things without disturbing others in the office. They also need to have a "home base", where they can keep their belongings. Such places could be small offices or cubicles.

Caves are also great for pairs whose task is to investigate something that none of the developers in that pair have experience with. This way some new things can be explored in a much more efficient way and different approaches can produce various results. These can be later discussed and a common solutions can be found. If the pair worked on one PC, the productivity would be only slightly better than of one developer working alone.

Commons

When it comes to pairing, people typically use their "personal spaces" or designated spaces, such as pairing desks or pairing rooms. There are two roles in each pair. The driver is the person who is in control of the keyboard and mouse at that moment. The other person is usually called the navigator.

In the case of the personal spaces, each desk must not limit the access to the PC. What I mean by that, is that the desk is best to be straight. Corner desks do not allow the developers to sit next to each other. Then it looks like the navigator is breathing down the driver’s neck and has very limited visibility of the screen. So, the "cave" is unsuitable for this task.

There are several variations of the pairing desk set-up. Let's talk about them in more detail.

One PC, one screen, one mouse, one keyboard

In this configuration, there is only one screen, so the settings must be so the navigator has as good visibility of the screen as the driver. Otherwise the navigator can not contribute much and the productivity of the pair is impaired. The navigator has no active control of what is happening. The only way the navigator can influence the process is by telling or suggesting to the driver. The limitation of having just one keyboard and mouse typically results in "switching" roles. When the navigator decides to drive, the control is passed onto him/her obviously by handing of the keyboard and mouse. Therefore everyone in the office can see who has what role in each pair at that given moment.

The usual way the developers drive is that they share a larger space in front of the screen. Ideally the developers should sit side by side and share the same (50%) of the screen space. This can only be achieved by having large and/or widescreen monitors (21 inch or larger). See the images below to see how large screen can work for a pair.

For the smaller screens the percentage the driver occupies is related to the size of the screen. For the 19 inch monitors it is approximately 60%. As the roles switch the developers shift to take or give space as shown on the images below.

One PC, one screen, one keyboard, two mice

A step up is to have two mice. Having USB mice is great. Just plug one more mouse into your PC and voilĂ . You are good to go. The OS should recognize both mice and you should be able to use them. Unfortunately, there is only one mouse pointer on the screen, so you have to fight for it. (Well, at least I did not find a good software that would allow you to have two separate mouse pointers.

Having two mice has a significant benefit. The navigator does not need to be told: "DON'T TOUCH MY SCREEN" when pointing at something on the screen. A mouse can be used for that. Moreover, the mouse is a powerful tool these days. There is so much you can get done with just a click.

Alright, so we have two mice, how do we switch roles. It's almost the same as before. The keyboard gets passed around. This setup usually results in the navigator sitting on the left and having the control over the spare mouse. The driver typically sits on the right having the control over the keyboard and the mouse. When the roles changes, as displayed below, the driver who becomes the navigator (on the right) loses the control and because there is no extra mouse on the right the navigator is quite passive (same as in the configuration with one keyboard and one mouse only).

The only solution to the right-side navigator's passivity would be an extra mouse on the right. It can work, I have never tried it and personally, it's just too many rodents on one's desk.

One PC, one screen, two keyboards, two mice

This is another step up for a better working configuration. In this case another keyboard is added to the PC. Each developer has his/her keyboard and mouse combo. In this way the developers can very effectively switch roles, almost instantly a navigator can jump in and drive for a few moments and then give the control back to the driver.

If your company can not afford to have spare sets of input devices, just bring your own to the pairing desk. All of us have the PCs, the keyboards and the mice, right? So, just unplug them from your PC and bring them to the pairing PC. Ideally, you would not have to do this. There should be some spare sets. The best results are if these are wireless as they tend to clutter the desk less and are easily portable. The only problem that can arise is that their frequencies may start to interfere, so wired ones might prove the best.

One PC, two screens, two keyboards, two mice

This is an ideal configuration and if you have it, you can call yourself lucky. There are not many companies that I know of that would provide their developer with such luxury. In our company we have several pairing rooms equipped with fast PCs and dual 21 inch screens with two sets of keyboards and mice.

This configuration is not only ideal from a driving point of view, but as a navigator you have a full view of the screen. Sometimes you might feel that when you are the navigator the machine is doing your work (that is if you ignore that dude on your side, but be nice to him as he might feel the same when you drive.)

Alternatively, the real estate of the two large screens can be used more efficiently by splitting the desktop. This can be done by stretching the desktop the way the one half is of one screen and the second half is on the other screen. This is useful most typically in cases when you need one window with source code and another window for testing the application (web browser for web applications.)

Laptops and pair programming

Laptops are nice little useful things. I love them. But they are not ideal for pair programming. Well, unless some special setup is done.

Read more about why the laptops are no good for pair programming.

What can we do? How can we be pair programming and using laptops at the same time?

The answer is not that difficult. All you need to accommodate the second developer is a screen, a keyboard and a mouse. Have you heard about USB? Get a USB keyboard and a mouse, and you are set. Well almost. The second developer needs to see as well. Give him/her a screen. Laptops have video outputs these days. It should be no problem to plug in additional monitor. The only

trouble might be setting up the resolution so it fits the laptop's screen as well as additional monitor's.

Alternatively you could configure the desktop to be stretched onto the second screen and this way you can use more real-estate as long as you maintain good visibility of both screens for both of you.

Office layout

So far, we have talked about the desk configuration. But what about how the desks should be organized in the office?

There are two factors to consider. Noise and communication. The communication is important not only within the pair, but also inter-pair. It is most beneficial if you can communicate quickly and when needed. The layout of the desks in the office should allow you to see and talk to other pairs easily. The layout documented in many XP books and articles describes the setting of six desks as on the picture below.

If you have enough space in the center of the room, this setup can work the best. The pairs can see each other and can talk to each other without shouting across the room. They also have a semi-private space where the pairs can work without generating too much noise disturbing the others.

These desks should be big enough to easily accommodate both developers, equipped with fast PCs and two sets of keyboards and mice. These should belong to the common area, they should not be personal caves of anyone.

We do not have this setup. We have pairing rooms that are well equipped, but they are rooms. And as such they isolate the pair from other pairs. The downside of it is that the developers very rarely communicate between pairs outside the meetings (formal or informal) when outside of the pairing rooms. Not all developers get to use these rooms. Simply, it's just too many of us and too few rooms. So we use our personal spaces for pairing as well. Neither our desks are located in the middle of room. The are lined-up along the walls and windows around the office. And so on some occasions there are big gaps between us and we have to walk across the room to talk to our peers.

No matter what the layout of the desks in your office is, try to respect the solo developers who require a quiet atmosphere for their thought flow. Pairs generate more office noise but can also effectively block out the noise generated by others. Solo programmers can not (unless they have earplugs and some loud music). Ideally, the pairs could be in a separate room from the personal spaces where we all work alone.

Pair Programming just got better

Today I got a new monitor. I had a 20" widescreen monitor before and the things just got better. After I had unwrapped and assembled my new 24" monitor, I sat in front of it and felt like in the cinema. The old 20" monitor (on the left) now looks like a dwarf...

Pair Programming is a lot easier on a big screen.

Wednesday, June 14, 2006

Why laptops are no good for pair programming

Laptops are great! There are small powerful gadgets that you get to drag to anywhere you want and use them as they come. I love laptops! Laptop is like your super-sized personal organizer. I use my laptop for all my office-type-of-work. By that I mean e-mailing, writing documents, blogging, Internet whatevering (substitute with browsing, banking, surfing, etc.)

They are great, if you are using them by yourself. But when it comes to pairing, they are no good. And I tell you why.

  • Laptops have usually smaller screens.

    • The navigator can not see as clearly what the driver sees (if anything at all, depending on the screen resolution).

  • The control is harder to pass around.

    • When the control is passed to the other person, that usually means that the whole laptop is handed over.

  • Laptops are less powerful then full-blown desktop PCs

    • One could argue that it is not true, that laptops can be as powerful as desktops. Yes but at what price? And all we developers need is computing power to run the compilations as fast as we can.

  • Laptops are usually more expensive

    • You can get more on desktop for the same price. No need to say more.

    • On a bright side, the laptops are tax deductible, and you can salary-sacrifice it in one year. Every year. Well, in Aussieland we can. It takes three years for ordinary PCs to be written off.

  • Laptops are harder to upgrade

    • They are simply less pluggable than desktop PCs. Therefore they age quicker.

Would I choose to have a laptop? Definitely! But not for pair programming. For that, I'd choose to have a nice and fast desktop PC.

Wednesday, May 24, 2006

How to reduce a risk of losing a key person

Pair programming is the answer. Let's have a look at your current project state. We will use an informal metric introduced by Jim Coplien - the "truck number" metric. The very essence of this metric is the question "How many or few people would have to be hit by a truck (or quit) before the project is incapacitated?" Obviously, the worst number is "one." How does your project score?

What can you as a manager do about the minimizing of this risk? Well, you may object that you do not want to put two people to work on a job that can be done by one. But the fact is that one of the benefits that pair programming brings is that it spreads the knowledge across the team and that in turn increases the truck number and project safety.

Monday, May 22, 2006

The Seven Myths of Pair Programming

I am lucky that I work for a company that embraces XP. Moreover, there are lots of interesting books on the shelf in our office bookshelf; books about XP, Java, Software Engineering and many more.

Last night, I started reading Pair Programming Illuminated written by Laurie Williams and Robert Kessler. It is quite easy reading and I will share my opinions about XP with you as do through the book over time. Today:

The Seven Myths of Pair Programming

  1. It will double the workload with two doing the work one can do
  2. In fact it lowers it. Two can produce a better quality code in less time and less time is spent debugging later as well. Need to say more?

  3. I'll never get to work alone. I couldn't stand that!
  4. Nonsense! You'll never spend 100% time pair programming a day. In most cases the "alone time" ranges from 25% to 50% a day. Pair programming is intense. We need to have breaks from pairing. During those we get to do stuff that you got to do, but it'd be a waste of time if done in pairs - like checking and responding to your e-mails. If you want to do some programming alone, then pick something simple. Leave the heavy stuff for pair programming.

  5. It will work well only width the right partner
  6. Again, we think that there is the "right" partner, but as we realize that we all are different and work differently, we can influence each other in many ways. Thanks to pair programming I got closer to many people in the team and feel more comfortable working with them. I feel being part of the team. Pair programming enhances the feeling of trust and improves the teamwork.

  7. Pair programming is good for training. But, once you know what you're doing, it's a waste of time
  8. Not necessarily true. It's a great way for knowledge transfer. I started working on my current project much later than my peers. Pair programming with them gave me a real boost in getting my head around the application and frameworks used. Pair programming can be looked at as never ending learning where we all learn from one another, not necessarily realizing the teaching part.

  9. I'll never get credit for doing anything I'll have to share all recognition with my partner
  10. Who cares! This is teamwork, forget your ego! Thanks to pair programming I feel stupid every day. In a good way, that is. I know I learnt a lot and I did a good job every day. You know how much you learnt and your partner will tell you if you did a great job. Don't be shy, do the same for him/her. Besides, you can develop an approach of task ownership. You pick and own the task. Then you "recruit" a partner to pair on that task with. Still there is no code ownership and you can get credit for the task well managed and done.

  11. The navigator fins only syntax mistakes. How boring is that! Compilers can do that better than humans can any way
  12. Navigator usually has the time to focus on the problem on a larger scale or consider various cases or scenarios while the driver works and concentrates on the particular one the pair is solving. This approach shortens the time - one, after finishing a step, would have to stop and think about the next step before continuing. Two, on the other hand, can work in a "flow" and maintain a steady pace.

  13. The only time I ever get any real work done is when I'm alone. Now, Ill never get anything done! Pair programming would drive me crazy!
  14. Well, pair programming is a different way. You can't get into the "flow" as described in Peopleware : Productive Projects and Teams written by Tom Demarco and Timothy Lister. But on the brighter side, if you develop in pair it does not take you 15 minutes to get back to the "pair flow" when interrupted. Plus, when people see you are busy, they are less likely to interrupt you anyway.

Pair programming has only one drawback for me so far. I don't get to listen to my MP3 collection that much, well almost at all. All that joy is left for my little home projects I work on just by myself.


Creative Commons License This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.5 License.