Let's Talk
Programming is hard. Yes, little things like typos can ruin your day, but that's not what makes programming hard. Programming is about constantly making decisions. When programming anything, decisions that you make at the beginning of a project often come back to haunt you. There a lot of things that you can do as a programmer to make sure your code works. You could write tests, you could review your code after you write it, or you could have somebody use the program and find all the bugs in it and then fix those - all things that we do here at Fusionbox every day. However, these do not really get to the root of many bugs - poor decisions. To help avoid bad decisions, the developers at Fusionbox have started pair programming.
Pair Programming!
Pair programming (or pairing) is a way to work on a project where two programmers sit at the same computer and work together. One programmer is called the driver. The driver controls the keyboard, types, and in general is in charge of the computer (aka drives). The other is sometimes called the navigator (but we don't usually use that terminology.) The navigator focuses on what the program is doing and possible gotchas! that arise from what the driver is doing. And, the programmers will often switch roles.
Not every task is pair-able. We will usually pair program for large projects that have a long timeline. Any that is very important and difficult, like payment processing, also warrants pairing. If we are training a new programmer, we will often pair with them, even on a simple project. However, things like simple bugfixes and the more common parts of a website are not ideal for pairing. One programmer can do it well enough and an extra programmer may not help.
But What About Productivity?
On the surface, it seems that if two programmers are working on one project with only one of them typing at a time, they will produce less than if each programmer was working on his or her own project. Obviously two programmers on two keyboards can type more than two programmers on one keyboard. However, programming is not all about typing stuff, and the fastest transcribers are not always the programmers. Pair programming improves programming in several ways.
- Fewer Bugs
The navigator often finds bugs before the driver is finished typing a line. Typos are caught quicker and avoided. Bugs can take a long time to figure out and if there are fewer bugs, you spend less time bugfixing. - Less Re-architecting
When you make poor decisions at the beginning of a project, sometimes you will need to redesign the way your wrote the code. Changing how code works is dangerous because it can have unexpected ripples across a program. This is especially difficult when people are already using your software. - More On-taskedness
Programming is tiring and frustrating. Sometimes programmers lose focus because they are frustrated or they've got programmer's block on a certain problem. Pairing can be a sort of tag team system to switch out when you become tired.
There is also a sort of peer pressure to stay on task. When somebody is sitting next to you, waiting on you, it is awkward to pull up a news article and read it. I feel a lot less inclined to check my email when somebody is looking over my shoulder.
Productivity in programming cannot be measured solely in output. Pairing produces higher-quality code, which saves everyone time in the long run.
Code Quality!
Pair programming leads to better code than traditional programming. Whereas a single programmer can just jump into a project without any real plan, this is not possible with two programmers. Just as in a car, the driver and navigator need to agree on the destination before starting. We haven't developed the ability to read each other's minds (yet), so in order to chart our programming course, we need to communicate.
Pairing forces programmers communicate their ideas to each other. Just being forced to explain an idea can help elucidate its shortcomings and advantages. As the Zen of Python, a set of guiding principles to programming, says
> If the implementation is hard to explain, it's a bad idea.
> If the implementation is easy to explain, it may be a good idea.
Pairing, like all collective action, is difficult. We have to agree on which libraries to use, how to write a certain portion of the program, how the program should work, and what features are most important. On top of this, we all have different priorities. Programmers approach problems from different perspectives and this makes settling on a solution harder. But again, like all collective action, decisions made by a group tend to address more factors and are generally better than decisions made by one person. Expressing and considering these different ideas ensures that a more holistic and robust solution is adopted.
Not only the design of the code is better, but the actual written code is improved. Pairing encourages better code practices sort of like peer pressure. Having somebody watch you as you type is going to force you to write clear and readable code. Because somebody has to read and understand it, you have to write intelligible code.
Down the line, a project that had more than one programmer is more likely to be extensible. If it is architected well and the code is readable, a programmer new to the project will be more able to contribute to it. It is easy to read code that was written for somebody to read. This extensibility is crucial to the long term success of a project.
Programming is hard in general, but pair programming alleviates some of the problems with programming. Pairing leads to better productivity and better code quality. It's useful for large projects and as a training system, but not suitable to every task. We at Fusionbox have started pairing for some projects and I think that it's proving worthwhile.
If you are interested in Python Web Development Services, contact Fusionbox today!