Monday 16 April 2012

100% Paired programming: The holy grail for business production

I recently finished a contract in a 100% paired programming environment. I thought it was an interesting experiment, and worth discussing, as it brings huge benefits.

The rules are quite simple:

Every developer works in pairs, whatever they are doing.
  • Pairs are swapped or allocated after tasks have been chosen in the morning stand-up meeting.
  • If a developer is pulled off a task to go into a meeting, his pair for goes with him.
Pairs swap every day.
  • 2 developer start a task
  • 1 developer swaps out after first day
  • The other swaps out after seconds day
  • So by day 3, a completely different pair is working on the task
The new developer drives
  •  This ensures they understand they system before they start coding, ie: knowledge transfer
  • It also ensures the task is kept small enough, because if it takes more than a day to explain the process crashes
Refactoring is a priority
  • As the new developer is driving, he will refactor anything he is unhappy with

The unwritten agile business rule:

Technical Decisions are made by the technical team.

This is team of great people, hired because they are very good at what they do. If the business dictates technical choices to them, you will lose them. Let the business determine business choices and then inform the team of the needs and requirements. They will come up with the best way to achieve it.

Assumptions:

The main assumption here is that your team is large enough to maintain this process,
But also large enough that you have lost the small team advantages, i.e.: start-up style.
As small teams get most of the benefits simply from their size and the fact they talk.

Pros and Cons

Pros

Total knowledge sharing across the whole team is implicit
  • you never need to worry about losing a team member because they are the only one who understands the system they built
  • for good or bad, developers become replaceable parts of the larger system
Code is very lean
  • All developers know they are leaving the task soon, so they implement the minimum necessary code to move the task forward quickly
Code review is implicit
  • All code is watched by 2 pairs of eyes
Reduced code smell
  • Bad code is refactored away far more quickly, as developers swap in and out of a longer task, the will refactor.
Improved Design and reduced technical debt
  • As developers swap in and out, they refactor to the most efficient design
  • Developed code will be production ready
Task motivation is maintained
  • Every day each task gets a new invigorated viewpoint from the developer swapping in
Improved team cohesion/bonding
  • All developers are effectively forced to communicate regularly, and to work on shared tasks. A team bonding situation is created
The team dynamic becomes the IQ of the most intelligent, not the most stupid
  • The quality  and quantity of rational discussion ensures a highly rational team
Team spirit propagates to new developers
  •  new developers can be brought in, and they will embrace the system, as it is highly rational, a developers dream
It can spread easily throughout the company
  •  Once the team spirit has matured and everything is working properly older team members can be used to create new teams, passing on the spirit to the new team. NB: at least half the new team should come from the original project

Cons

It is a lot more expensive to double up
  • Yes it is.
You need to hire a lot of great people
  • Again, this is expensive, but if you want a good product, you need great people
This is a long term proposal, it takes quite a while for the process to get going properly
  • The team spirit is like a baby, it needs nurturing to mature properly


Discussion

Many of these advantages come with a small start-up team, but you lose them as team size grows and management increases. The management problem is especially responsible for de-motivating teams.  

As management grows, they want to feel responsible for successful decisions, and technical decisions are an easy target, especially as business sales teams target management. It is very difficult for a lead developer alone to protest such a decision, but when the whole team is combined, they present a powerful front to stop bad decisions.

The communication problem also quickly becomes apparent in larger teams. Large teams tend to fracture and balkanize as factions grow inside it. The great developers will often be less communicative, so you lose their input, or they are great communicators and effectively shut out every elses opinions. Either way you have acommunication problem.

Conclusion


If you are a large company, building a large team, and you want to build a robust, production capable system as quickly as possible, using agile methodologies, while maintaining start-up ethos, and you have both the finances and political will to support it, then in my opinion, this is your best option to optimise production.

No comments:

Post a Comment