< >

Sep 18 2002 Kelly Norton

I'm up to my earballs in Software Engineering methodologies. Me, being sometimes neurotic and sometimes just plain idiotic, has decided that we need to patch some of the internal development processes at work before we embark on a big upcoming project. I started listing out problems and looking for ways to solve them and somehow ended just shy of Extreme Programming. One of the more interesting parts of which is a technique called pair programming. If you hang out with software nerds, you have probably already heard this term and done the obligatory initial scoff. Pair programming basically calls for two programmers to sit down in front of one computer to do all the coding on a project. “What the hell? One programmer for the price of two? Are you smoking crack on company time again?” yells the financial guy. Well, it turns out that it's actually hard to quantify the cost of pair programming because it tends to trim cost off the tail end of the process by helping to create a higher quality product the first go round. Is it really wasteful having two people work on the same thing if there are fewer problem tickets open on it down the road? That, though, is a very difficult result to verify so for now those who wish to take this route have to rely a little on faith. For smaller companies especially, its proponents boast the added advantage of setting up a periphery learning environment, which educational theorists would place under the apprenticeship model. This means simply that if you pair a java expert with a java novice, the java novice is going to get better just by watching and listening as the expert does his thing in the paired environment. But, by all means, don't listen to me babble about this; read (pdf).

I just can't help but think that this seems to be the Social Constructionist's method of software development. Why do all roads seem to lead to postmodern principles these days?