Software Engineering – Week the Fourth
“Pair programming revisited.” That’s what the second assignment should be called. I still have flashbacks to the horrible deadlines of Operating Systems last semester. But this time it’s going to be different–namely we aren’t writing an operating system. So all that bias aside, pair programming is perhaps one of the best activities someone can do. Too much code is written in metaphorical “caves” by single architects and looks like crude scrimshaw on half-decomposing animal bones. To put it bluntly: ugly and sometimes scary. Pair programming helps this.
The benefit is two-fold: firstly, if you’re usually more conscious about appearance when you’re in public–the same goes for code–unless, of course, you write ugly code with impunity. Secondly, your partner has the power to force you to make good code. The second part is true because of the fundamental structure of the official rules of pair programming (this may or may not be a real thing) which state: each individual, usually human, assumes a different role. These roles are as different as your frontal lobe and your motor cortex. Actually, the roles fit those parts of the brain fairly well. While one individual does the typing, the other sits, possibly with a glass of scotch or a cup of Earl Grey (like a sir), telling the typer what to type. And here’s how one user can force the other user to write better code: the typer can just say “what the heck am I typing,” get up, argue their point, assume the role of the dictator, and go happily on their way (until, of course, the coding requests start getting ugly and the roles again are reversed).
In addition to the aforementioned benefits, there exists another more long-lasting benefit: information osmosis. If your partner knows how to write better code, they’ll teach you. If you know how to write better code, you’ll teach them. Also, since the architect and the typist are separate and it is in human nature to like adorable, cute, fuzzy, clever things, if the typist knows a shorter way to code something, they’ll probably balk at writing some long stringy code. This leads to conciseness and hopefully better readability.
Finally, pair programming sometimes causes a lot of overhead and takes more time than coding a solution out oneself, however, I have yet to see a case where pair programming hasn’t created better code. It’s worth the struggle. And, even if you’ll be coding alone 90% of the time on other projects, you still will become a better programmer (and even, perhaps, person) through the 10% of time spent on a collaborative project leveraging pair programming.
2/9/2014