The Pair Programming Experiment — Part I
Why are we doing this?
This is Part I of a three-part series on our Pair Programming Experiment.For the experiment, we created two teams working on 2 projects for 2 weeks. One team worked in pairs, second as solo developers. After first week teams started a new project and swapped methodologies. Read Part II — The Retrospective here and Part III — The Results here
There are many controversies surrounding Pair Programming and for many its advantages are questionable. For example the most popular theory says that developers that work as a pair are faster and produce higher quality code at the same time. We simply think that not enough experiments and research has been done to prove whether this point is true or false.
In fact most of the data on the topic is old and uses passé metrics like lppm (lines per person-month). For years metrics related to lines of code have simply been considered to be deprecated and misleading.
That’s why we want to produce more data ourselves. That’s why we want to carry out The Pair Programming Experiment.
What exactly is The Experiment?
2 teams will be working full-time on 2 projects for 2 weeks.
During the first week Team A will work as Solo Programmers and Team B as Pair Programmers.
During the second week Teams will start an entirely new project and swap the methodologies.
We will measure their velocity, code quality, bugs and other metrics on a daily basis.
How will it look like?
Projects
- Two projects:
- Project 1: “Flashcards” — a learning web app inspired by Anki and Memrise
- Project 2: “News Aggregator”- live RSS and social media stream
- First week:
- Project 1 — Team A works as Solos, team B works in Pairs
- Second week:
- Project 2 — Team A works in Pairs, team B works as Solos
Teams
- 12 Developers that have attended our 2-month Ruby on Rails bootcamp for people with some programming experience. During the bootcamp, along Ruby and Rails, they’ve practiced Pair Programming, TDD and Scrum.
- Split into 2 teams of 6 (A and B). The members of each team have been chosen by the bootcamp mentor. He made sure that teams are as equal as possible in their skills.
- Members of Team A work as Solo Developers, members of Team B work in Pairs. Teams will swap the methodologies on the second week.
- Solo Programmers can talk to each other but they cannot work on the same machine at the same time.
Metrics
- Velocity
- Both teams start with the same project backlog estimated by an external person
- Burned story points will be the primary metric of speed
- Burndown charts will be presented with the results of The Experiment
- Code quality
We will measure Code Quality, Style, Security and Test Coverage using CodeClimate service and its GPA metric. - Amount of passing and failing builds
- Git/GitHub metrics
Amount of commits, pull requests and Code Review comments - Number of bugs
- “Done” tickets will be tested daily
- Bugs will be reported and added to Kanban Boards
- Amount of deployments
We believe that all of the above will give us data about Pair Programming that will be as close to scientific as possible. The numbers will show if Pair Programming has the questioned advantages of speed and quality.
When will it take place?
The Pair Programming Experiment will start Today and will finish in two weeks
Follow us on twitter, facebook and instagram for live coverage and results!
