Tony has been working with computers long enough to remember when we had to reservice time to compile code. Becuase computer access was extremely limited they used Peer Review to try and resolve bugs and optimize code before accessing the computer. It turns out the process is very similar to pair programming today.
Tony Writes:
“Nearly 50 years ago when I started programming, we were not blessed with copious machine time. We used to get 1 hour a week at an IBM service bureau while awaiting delivery of our machine. So we used to peer review our work and desk test our code together.
Additionally when you had 8 or 16K of storage then you needed to work hard to remove redundant code and streamline your program. In 1975, more than 25 years after Prof Wilkes worked on building a machine in Manchester, he said that there wasn’t anything new in computing, just faster, more of it and smaller. I am now of the same mind set!”
It worked well for me then and since. I have been very much in favour of peer review (rather than Pair) since it is often the original programmer who spots the problem as he explains his code. There also has to be a leader with experience in the pair.
I have involved myself in assisting programmers in seeking problems/solutions and it is surprising that the same issues continue through the years. I might add that I was questioning programmers with problems even as CEO of a technical company of 1500 – once a programmer always a programmer!
Editor:
I have had similar experiences decades ago where code was written by hand while waiting for access to a terminal to compile your program. Peer review saved a lot of time in those days because if your program didn’t work you had to wait quite some time to try again. There were no real time debuggers, etc.
In my experience, pair programming is the modern equivalent of peer review. It can have a mentoring component. But you may ask the question as to how to keep both individuals engaged while one individual is using the keyboard? And that is the magic of pair programming.
If you embrace Agile processes which is normally where you will see pair programming, then you are probably also writing automated unit tests. Depending on your testing strategy, you identify a method to be developed; one individual writes the method; the other individual writes the test for the method. Once the test works you move on to the next item.
You decide if you work from test driven design, test first design, or test after. But the key is that both individuals are engaged in the process because they are both working on the question of what needs to be tested and how to test it.
IMHO both individuals need to have a keyboard and mouse in order for pair programming to be productive. Otherwise it is too much hassle to switch back and forth.
To be fair, pair programming is not always efficient. There are a lot of times when you are simply following a well understood pattern and implementing it for the 100th time on a new object. Pair programming doesn’t add value. Another time I have found that pair programming isn’t as valuable is creating POCOs or data transfer objects such as JSON.
Thanks, Tony, for sharing your insights. You can participate in the conversation by leaving your comment online, or sending an Email to btaylor@sswug.org.
Cheers,
Ben