Category Archives: Pair programming

Pair programming with Sankalpa

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)

Posted in English, Extreme Programming, Non-technical, Pair programming, Software Development | 1 Comment

Using pair programming to combat project waste

  • Less Overproduction (of unused functions in interface between team members)
  • Less Waiting (for the only person who knows a particular area)
  • Less Motion (as everyone gets more skilled)
  • Fewer Defects (because two pair of eyes see better than one)
  • Less Over-processing (from duplicate responsibility)
  • Less Inventory (as team works on focused set of features and tasks)
  • Less Transportation (handoffs inside a story)
  • Less Underused talent (as everyone gets to share their skills)
Posted in English, Extreme Programming, Non-technical, Pair programming, Software Development | Leave a comment

How to start a Coding Dojo

I recently attended the XP Days Ukraine conference in a rainy, but beautiful and Christmas-decorated Kiev. I conducted a coding dojo and gave a talk where I demonstrated pair programming live together with Dima Mindra. After the talk, I got a few questions about how to run a Coding Dojo.

This article is meant as a guide to anyone wanting to start up a Coding Dojo, whether it’s in Kiev (Mikail/Aleksey), in Odessa (I’m looking at you, Dima!) or anywhere else in the world.

A Coding Dojo is a place to learn and have fun while programming

Quite simply, a Dojo is a gathering of programmers who come together to have fun and learn while programming. It’s always hands-on and it’s always social. In Oslo there are about 300 people who have signed up their interest. We meet on average once per month, usually in a bar. There is anywhere from 5 to 25 people who attend any given meeting.

Alternatively, a Coding Dojo can be used to describe a single event for a company or team that wants to train their developers in a hands-on and engaging way.

Coding Dojo Style #1: Many programmers, one problem

In the martial art Aikido, “Randori” means that multiple people are attacking the same person. In the Coding Dojo, “Randori” means that multiple programmers are attacking the same problem.

In order to organize a randori-style dojo, you need a computer with a development environment, a projector, a place to meet, a facilitator and 4-10 programmers who attend. Here is one way to carry out a Randori Style Coding Dojo:

  • If the group is new to test-driven development, the facilitator demonstrates the red-green-refactor cycle with a simple example (no more than 10 minutes)
  • The facilitator introduces the programming problem (kata) to solve. The Prime Factors kata is a good first kata for a group
  • The faciliator invites a partner to join him at the keyboard. The facilitator writes a first test, makes sure it runs red and invites someone else from the group to take his place.
  • Each pair works on the problem for 5-10 minutes, the facilitator then makes sure that one person in the pair is switched out with someone in the audience.
  • After about 45-60 minutes of working on the problem, call a break and review what’s happened. Personally, I’ve had success with asking everyone to name one thing that they learned, one thing that surprised them, and one thing they want to change about the way they work.
  • After the review, the group can work on another kata (problem), try the same problem again or use another exercise form

The biggest barrier for most people to participate in a Coding Dojo is that most programmers have never programmed live in front of anyone else. This feels extremely awkward and vulnerable at first. As a facilitator, your most important job is to help everyone feel at ease at whatever level they are.

Coding Dojo Style #2: Pairs working in parallel

Some people report that a Randori-style dojo can feel slow and constrained. As an alternative, I sometimes use the CyberDojo software, created by Jon Jagger. For a CyberDojo style dojo, you need a place to meet, a computer with a projector and internet access, a facilitator and 6-30 programmers with their own laptops with a web-browser and internet access. Here is how I usually carry out a CyberDojo style Coding Dojo:

  • The group forms pairs of programmers
  • The facilitator sets up a CyberDojo on http://cyber-dojo.com. (It may be smart to send a quick tweet to Jon to make sure he’s not planning to restart the server at this time)
  • All the pairs work in the fashion the group has agreed to work for 30-60 minutes
  • After the coding session, the facilitator uses the CyberDojo dashboard as a focus for discussions of programming habits

If you’re thinking about facilitating a Cyber Dojo, just go to http://cyber-dojo.com, try creating a dojo and solve a kata. You can do this on your own now!

Coding Dojo Style #3: Working under stress

Extreme startup is a workshop based around a server that will ask questions of the software running on the computer of each participating pair. As the pairs answer questions correctly, they are awarded points. I usually run an Extreme Startup session after having run a strict TDD Coding Dojo. In the Extreme Startup, teams can work any way they want.

The Extreme Startup software is developed by Matt Wynne and Richard Chatley. There are several forks, including mine, which tries to maximize the stress.

In order to run an Extreme Startup workshop, you need a place to meet, a computer with a projector and the Extreme Startup software, a facilitator and 6-30 programmers with their own laptops with a development environment of their choice. All the computers need to be on a shared network so they can communicate using TCP/IP.

  • The group form pairs. If someone wants to work solo, or in bigger groups, that is okay, too
  • The facilitator starts the Extreme Startup software in warmup mode
  • The facilitator demonstrates how to get started (I use this collection of starting points in a number of languages)
  • The teams work for around 30 minutes until (almost) everybody have been able to get a web server running and registered on their computer
  • The facilitator starts the Extreme Startup software in real mode
  • All the teams reregister their servers. All hell breaks lose as they try to implement the questions as fast as they can
  • After the teams have worked for another 60 minutes, the facilitator breaks off the competition. Ask the teams on the top to describe how they worked

If you’re thinking about facilitating an Extreme startup, download my or Richard Chatley’s version of the software to your computer. The README file explains how to get it running. Then download Steria’s collection of starting point to your computer. Use the ruby/sinatra_for_dummies starting point to create a solution. Let me know of your experiences when trying out the software, so I can improve the README.

You can do this by yourself now!

Start a coding dojo

A coding dojo is a great way to build your professional network, become a better programmer, and to have fun! I hope this article can help you get started.

Posted in Communities, English, Extreme Programming, Pair programming | 7 Comments

Experience Agile Programming

The next half year, I’m scheduled to give the talk “Experience Agile Programming” in Kiev, Gothenburg and Riga. In the presentation, I pair with a local developer and show a coding kata in Java, Ruby or CoffeeScript. After the presentation, I engage the audience in a discussion of what they saw, when they would use it, etc. I might also show a few more programming tricks if time permits and the audience requests it.

If you are a local developer in Kiev, Gothenburg or Riga this could be a chance for you to improve yourself. I’ve got more than ten years of experience with extreme programming practices and chances are you will learn a few tricks that will put a smile on your face. I will practice with you before the conference, and my goal is to make you shine during the presentation. Chances are that your peers will recognize your skills after the conference, so this may help you get some local fame and build your personal brand. Finally, programming as an exercise is great fun and the experience is likely to leave you with a smile on your face.

Here’s what Jussi, who I paired with for #TampereGoesAgile has to say about the experience:

If you’re a programmer who’s willing to take a risk, learn a lot and get some attention from your peers, please get in touch via @jhannes, johannes@brodwall.com or comment on this blog post.

Posted in English, Extreme Programming, Pair programming | Leave a comment

How extreme is extreme programming?

The term Extreme Programming (XP) was coined in the nineties. Originally, it described a set of practices that have mostly been widely adopted today. Among these practices were continuous integration, test-driven development, user stories and frequent releases. These practices are hardly radical or extreme today. So what does “extreme programming” mean now?

To me, the idea behind Extreme Programming can be summed up as follows: What would happen if we take what we know works, and do it to degree that seems at first unreasonable?

You will quickly notice that testing will be more effective if you test earlier. What is unreasonably early: Testing before we have something to test. Thus the idea of test-driven development is born.

You will quickly notice that code review is an effective form of improving quality and spreading knowledge in the team. What is an unreasonable amount of code review: All code should be written by two people. That is, pair programming.

Similarly, the idea of user stories comes from the observation that communication between users and developers is key to effective development of a user friendly system.

Some of the ideas of extreme programming don’t feel so extreme anymore. But the spirit should live on. What would it mean to do what we know works today to an unreasonable degree?

Take continuous integration for example. Most teams use continuous integration to run tests when they check in the code. What would happen if we ran the tests whenever something changes? Most languages support continuous testing or autotesting today and teams are starting to adopt this now.

Frequent releases may mean once every 1-3 months for many organizations today. What would happen if you increased the frequency from months to weeks, or from weeks to days. Or from days to hours? Some extreme organizations actually push changes into production automatically when their batteries of automated tests succeed.

Short iterations work and reducing parallel work helps many organizations today. What if we got away from the iteration altogether, and a developers pick the next story when ready. What if we delayed all discussions about the user story until a developer was ready to start programming it? Many organizations are working with variations of kanban to increased flow and reduce waste.

Extreme Programming means pushing the things that work further than we’ve done before. What good ideas would you like to do to an unreasonable amount?

Posted in English, Extreme Programming, Pair programming | 5 Comments

Cyber Dojo and Extreme Startup

Last week, I was invited to do a coding dojo for the Java user group in Bergen. I chose a format that let people work more independently rather than the classical style of “lots of people passing the keyboard around and looking on the code on a projector”. The result was an informal, competitive and engaged workshop where people continued playing with the exercise long after the official program was over. While drinking and socializing, of course.

I found the format useful, and perhaps this blogpost will useful to others who would like to organize a coding workshop.

Part I: A longer introduction

In order to get people to have a shared vision of the activities of the workshop, we started slower than I’ve sometimes seen in other workshops. First, everyone in the room said a few words about what they were hoping to get out of the evening. Then, I demonstrated a simple exercise together with @karianneberg. In the exercise, we demonstrate how to do pair programming and test-driven development. After the demo, we discussed what aspects of this way of working were surprising or different from what the audience was used to.

Take-aways: Coding dojos often throw the participants out on deep water right away. By instead showing an idealized pair-programming session, we provided a model for the participants to follow.

Part II: Exercise

We started out with the simplest programming exercise I’ve been able to come up with: Calculate whether a year is a leap year. I took the instructions for of the exercise from @jonjagger‘s Cyber Dojo tool. The participants worked in pairs on this exercise.

Cyber Dojo can be a frustrating tool, and I offered people the option to use it or not as they wanted. In the end, almost all the pairs chose to use it for the first exercise. And we could see how their work was progressing on the projector.

After everyone had completed the leap year exercise, we switched around the teams and worked on an exercise to translate Arabic numerals to Roman numerals. Here, too, I used the instructions from Cyber Dojo. However, due to various problems, we decided not to use Cyber Dojo as the programming environment for this exercise.

We did a brief retrospective after each exercise. I decided to mostly use this chance to ask “too much or too little questions”, like “do you feel it would’ve been faster if you’d taken larger or smaller steps?”, “do you think you refactored too early or too late”, “did you switch which person in the pair was using the keyboard too much or too little”, “did you spend too much or too little time thinking about how you would solve the problem”, etc.

Take-aways: Coding dojos usually practice a stylized form of programming with as small steps as possible. By reflecting on how it would be to work with the same problem in a less forced way, it’s easier for people to find out how they can apply what they learn to their day-to-day work. In particular, the discussion about how big the TDD-steps should be brought up a lot of interesting debate.

I usually try to have bigger exercises, like Yahtzee scoring or Poker hands. I found the smaller exercises to work very well for this workshop as this part ended up acting as a warm-up for the competition.

Cyber dojo experiences (mostly for Jon): I’ve used the Cyber Dojo a few times now. It’s an interesting tool, and I find Jon’s idea about taking away features to avoid distractions to be a good strategy in general. However, I usually find that to some level, the tool becomes a distraction because of its limitations. In particular, I think the groups would’ve wanted to continue using it if they didn’t have to work so with the build script and if they could’ve switched between files and run the tests using the keyboard. The groups miss code completion etc, but are willing to accept these shortcomings because of the community and competitive aspects of the tool.

The real killer, however, was the setup. Using a Windows box, I didn’t get the Cyber Dojo to run natively. I tried using a VirtualBox setup, but kept running into technical problems. In the end, I decided to risk using Jon’s hosted dojo at http://cyber-dojo.com. Sadly, it turned out that Jon was doing upgrades of that system halfway through our dojo. Too bad, but as he provides this service out of the goodness of his heart, I knew the risks.

Part III: Competition

After the exercises, we had a competition where people got to use or ignore what they’d learned as they saw fit. The competition used the Extreme Startup workshop. There’s a lot to be said about it, and I’ll write a future blogpost on Extreme Startup.

Conclusion

Cyber dojo and extreme startup both create a competitive and social environment for small groups to practice programming. This can create really fun workshops. The Bergen Java User Group kept playing with Extreme Startup until midnight.

I will use Extreme Startup as a workshop in the future. Hopefully I will add more questions, too. I may use Cyber Dojo again, but I’m hoping for some changes to the software before doing so. As it is, there are too many aspects that distract the users.

Posted in English, Extreme Programming, Pair programming | 2 Comments

Three tricks to get better pair programming

One of best ways to get the full effect of pair programming is if everyone programs with everyone else. This maximizes learning in the team. Here are three simple tricks we’ve found useful to get the pair programming to flow better.

  • Magnets: Getting away from task ownership is essential to get pair programming to work. Instead of writing names on the cards that represents the tasks the team is working on, we place magnets with pictures of the team members on top of the tasks on our task board. This helps people remember that they don’t have to permanently commit to a task. Moving the magnets around during the stand up meeting is a good way to discuss how to organize the work today. We try to keep one person and exchange one person on every task every day.
  • Pair programming star: Deliberate rotation fosters learning in the team. Write the names of all team members in a circle on a whiteboard in the team area. Every day two people pair program, draw a line from the name of one to the name of the other. This both becomes the team’s own indicator of success, and an “excuse” to ask someone you haven’t programmed with if you could pair up with them today.
  • Don’t sweat it: When I started pair programming, I found it exhausting! It felt like I never had time that I needed to ruminate over the problems and that I never had chance to explore solutions on my own. During this period, it’s helpful to remember to give people the time they need to think through problems on their own. I do prefer that the code that’s actually checked in is pair programmed, though.

When I started pair programming, I found it to be an obstacle for getting into flow. After a few weeks, working solo has become an obstacle to getting into flow. You got to give it some time and take the breaks that you need along the way.

With pair programming, the teams share responsibility, pull together and have more fun!

Posted in English, Extreme Programming, Pair programming | 4 Comments

Pair programming = project reliability

What do you do if you want to have a reliable system? You make sure you have redundancy: More than one component can do a certain job. You back up you valuable data to a separate system. You have two servers to provide your critical service, in case on fails. Yet, many projects have no plan for the inevitable absence of people with critical knowledge.

We practice pair programming to get redundancy. This manifests itself in many ways:

  • When someone is sick, on vacation or leaves the project (to become a doctor, say), the project doesn’t suffer. Or rather, it doesn’t suffer as much. We do get less work done if fewer people are present, of course. And many of our developers have areas where everyone loves to get their help.
  • We can add new people to the team. Learning how the system works is just a matter of pair programming as part of the normal rotation.
  • We are very adaptive to varying focus at different times in the project. If we had someone who could only work with, say, databases, he wouldn’t have much to do at some times, and too much to do at other times. With pair programming, we still have people who’re especially good in some areas, but everyone can help out with whatever needs doing.
  • No parts of the code are off-limits. As every commit of the code is written by two people, no one person has the right to block changes to “his” code. Anyone can make the changes that they need to complete their current task as good as they can.
  • The team is working with fewer tasks at a time. As teams grow in size, there can be a lot of different things happening at the same time. This both increases the chances that people will step on each other’s toes (that is, work on the same source code files) and increases the amount of “Work in progress” at any one time. Pair programming effectively halves the amount of work in progress.
  • Everyone has a understanding of the whole system. During planning and design discussions, everyone can contribute. Instead of focusing on technical components and subsystems, the discussion is about how to solve the user story as a whole.

Some studies focuses on the impact of pair programming on efficiency, quality, progress, or even focus. I think it’s much more interesting to see how pair programming changes the dynamic of the team. From a group of individuals, we form teams where everyone is appreciated as a contributor. Everyone has their individual strengths, but more importantly, everyone has the same goal in mind: The success of the team.

Posted in English, Extreme Programming, Pair programming, Software Development | 6 Comments

Pair programming research misses the most important point

When I started pair programming daily, it changed my life and my projects for the better. I often point to pair programming as one of the most influential possible interventions on any projects. Very often, an audience member with a healthy degree skepticism will inquire about the research into pair programming.

Sadly, the practice of software engineering research has not come very far in this area, so the questioner is left unsatisfied. In this blogpost, I will summarize the current state of research into pair programming, and describe my hopes for the future.

(more…)

Posted in English, Extreme Programming, Pair programming, Software Development | 17 Comments

How pair programming and test-driven development looks in real life

Pair programming and test-driven development are some of the practices that are most often talked about and least often actually understood. So I’ve decided to undertake the task to teach myself to program a simple, yet realistic problem with a pair programming partner. The goal is to create an entertaining and realistic performance that portrays what it feels like to work like this.

I’ve been extremely lucky. I’ve found not one, but two programmers that have been willing to train enough with me to make a smooth performance of a pair programming session. The result is the Java EE Spike Kata. My colleagues in Steria, Anders Karlsen and Ivar Nilsen have been great to work with. Between us, we’ve showed the kata at three conferences, and more are coming.

Here is the performance at JavaZone 2010 by Anders Karlsen and myself.

The Java EE Spike Kata from JavaZone on Vimeo.

Make sure to watch the video in full screen mode as there will be LOTS of code.

Some things to watch for when you’re watching a (paired) code kata:

  • How are we working together? How often are we changing who’s at the keyboard? What will the person who’s not at the keyboard be doing?
  • How do we progress from one test to the next? When do we decide to modify an existing test and when do we decide to add a new one? How much of the test do we write before we start modifying the production code?
  • How are we writing the production code? How often are we refactoring existing code?
  • How are we using the IDE? What tricks do we use to take advantage of the code completion facilities? How often do we use the mouse and how often do we use the keyboard?

I also hope to be putting up the video of me and Ivar Nilsen at the TelecomCity conference in Sweden. As we’d both practiced even more for that performance, I think it’s even smoother than the JavaZone performance.

Enjoy!

(Kudos to Cisco Norway, formerly Tandberg, for excellent filming services at JavaZone. And thank you to Robert “Uncle Bob” Martin for turning me on to code katas in the first place)

Posted in English, Extreme Programming, Java, Pair programming, video | 10 Comments