The Power of Pair Programming

I never wanted to sit with another developer and do my job. I know what I am doing, and google can help me figure out anything I get stuck with, right? This is my code, I know how it works, and I don't want other people messing it up.

It wasn't till I started working with a second developer at my desk for a couple hours a day till I realized the true potential and power that pair programming can bring to a team. We would lay out what we wanted to accomplish and it seemed like we always finished, never hitting road blocks or getting stuck debugging for long periods of time. We would get in "the zone" and just crank out functionality. We would knock out in two hours what could have taken me more than a day to do on my own.

There are many ways to pair with another programmer. Just sitting there while they write code and providing input as an observer. Taking turns on the keyboard with one person driving and one observing, and switching periodically. Playing ping pong, where one developer writes a failing unit test while the other follows with an implementation which causes that test to pass. There are even teams which have put together developer setups which include two keyboards and two mice such that either developer can take control at any given time without having to move over.

Pair programming can bring a team together and spread the knowledge. When a senior developer picks up an easy task, it becomes a great opportunity to pair with a new team member and use it as a teaching opportunity. It is recommended to let the junior developer drive. There is no better way to learn than doing, yet having the support of someone in the know right next to you provides a feeling of security that they can't mess it up. When the next story is taken by someone which may not have the skills to solve it, this again becomes a great opportunity for learning, but also involves team communication to find the individual which may know more about the particular component. This can greatly reduce the "truck factor" of the team.

While all the above are true, and can help justify why pair programming should be done, I must say that from my experience the biggest gain from two people working together is the focus and ability that two people have to stay on task. Working with another person typically does not allow me to be distracted. People also know better than to interrupt when people are working together in front of a computer screen. You put those two things together and a pair can get in the zone and do amazing things.

So pull up a chair and spend some time developing with a teammate.

Photo by by ntr23 via flickr.com

How much will it cost?

The first thing they want is the estimate: How long will it take? How much will it cost?  These are not easy questions to answer- especially when no one knows exactly what the customers want to build. How can we give you an estimate when you don't know what you want?

We are on a project where they hired someone to figure it all out first. The analysis team spent a year, with numbers around one hundred people, learning about the customer, researching technologies, and spewing out documents- in the thousands of pages.  Then they came up with a schedule for someone else (eventually including us) to start delivering systems incrementally- and called it Agile (with a capital A): fixed-scope, fixed-schedule Scrum.

Unsurprisingly, it didn't work.  The analysis team missed half of the requirements for the most important application.  Their technology selection process came up with numerous wrong answers. The first few incremental reviews were perceived as having come from a year of work. A battle began between the implementation and analysis contracts.  It got ugly.

So they started over from a contracting perspective. Good-bye to fixed scope. Good-bye to fixed schedule.  A new dawn for "real Agile"?  Except that now the customer wanted a schedule- they wanted a price and a schedule for scope- scope that was not at all agreed upon.

We had a modest proposal- if you want a fixed cost, fixed scope contract, make it short. Make it a month or a quarter.  Give the customer the option to cancel at any time. Use rolling wave planning.  Of course, the customer budgets work years in advance, and uncommitted funds often disappear.  So you have to write a contract that specifies these iterative and incremental development cycles for about the size of the team the customer can support.  Use a little bit of data to at least put you in the wide part of the cone of uncertainty. Refine the estimates with each increment based on real evidence.

Stay tuned to see how it goes.

Are you creating value?

In the Lean view of the world, the theory of business that emanates from the Toyota Production System, the focus is on delivering a continuous flow of value and avoiding waste. Our business is formed around delivering value to customers. When our team arrives on the scene at a project- often a project that is in trouble for one reason or another, the first thing we look for is the customer. In order to provide value to the customer, one must understand what the customer values.

How do we understand what the customer values? The values must be communicated to us- but, still how, and by whom or what? Too often, we show up on a project and there is a huge document that purports to represent the customer's needs. In some cases, we are told to look at the existing systems they have and recreate them, with changes. In other cases, we are told that some other project functionaries will be spending their time visiting with the customer, and the the people designing and building the system will not be dealing with the customer. What does the lean approach tell us to do?

The Toyota Way recommends a simple thing- "Go and see for yourself to thoroughly undertand the situation." Also known as going to gemba (Japanese for "real place") or genchi genbutsu (Japanese for "real thing"), this allows you to make accurate decisions based on real observations. Rather than acting based on reports or hearsay, we should strive to create real human interactions with the people involved in the mission and understand what they are trying to accomplish. This will help put the technology in the right place.

Your job, your primary goal, is to help accomplish the mission of your customers. If you do not deeply understand this mission, you can only act in a shallow fashion. You will only be providing tools, and you will not be aware of whether or not you are providing value.

What is this about?

We work on a lot of projects. We see a lot of opportunities for improvement (aka problems). We provide a lot of solutions.

There are patterns to the kinds of things that go wrong on these projects. There are root causes that need to be addressed. There are things that we know really work, and we're trying our best to make them happen.

That process would be far simpler if people already understood what we are trying to do. Therefore, we are kicking off this effort to attempt to work out the specifics of the process and communicate it in an effective manner to the necessary individuals such that everyone's chances for success are improved.