My roomate for 3 years in college, D.R., was here over the weekend. We hung out on Friday night. He wrote today saying that he always seems to end up drunk on wine when he visits. All I can say is that it must be his fault because that hardly ever happens around here otherwise.
He's a real programmer doing some interesting things out in California. His company employs extreme programming. I've read some about this, but I've never talked to anyone who actually programs this way. The main idea involves pair programming.All code to be included in a production release is created by two people working together at a single computer. Pair programming increases software quality without impacting time to deliver. It is counter intuitive, but 2 people working at a single computer will add as much functionality as two working separately except that it will be much higher in quality. With increased quality comes big savings later in the project.
The best way to pair program is to just sit side by side in front of the monitor. Slide the key board and mouse back and forth. One person types and thinks tactically about the method being created, while the other thinks strategically about how that method fits into the class. It takes time to get used to pair programming so don't worry if it feels awkward at first. Seems cool, but my intuition accords with his findings: it's a good way to go if the people involved are very skilled programmers. On the other hand, putting me together with someone else on my level wouldn't really be very helpful. I wonder if it's something specific about coding that allows this to work, or could this approach benefit other pursuits?
it's a truism that productivity varies enormously between developers with similar levels of training and experience. i forget the locus classicus for this but i think the usual soundbite is that a great developer can be 5 x more productive in a given unit of time than an average one.
my experience around the outside of various development projects confirms this empirically to an extent...often a given team or department will have one "star" who always ends up doing all the hard stuff -- either because their manager assigns it to them, or because they can't bear waiting around for some other joker to get it done.
so my question would be, how do the "stars" react to this pairing? if they are amenable, great -- presumably they can muse aloud on what they're doing while their partner learns a whole lot by watching over their shoulder. a side benefit could be that the partner will understand the code well enough to document it (not a treasured past-time of the hot developer, i've noticed). and i could see lots of potential benefits for hands-on testing if they're self-testing, or for interacting with separate testing team if that's the structure...so far so good.
but what if the hotshots don't like it? then you ain't gonna get much upside...and you could potentially get blowback -- slowdown -- loss of interest -- assigning a signpainter to sit on every move Van Gogh makes isn't going to speed up production of the masterpieces...
very curious
Yeah. Again, I don't really know, but I think this is what Dave was saying. Namely, it works out if everyone is top level talent, but maybe not otherwise. In any case, if you have a star (I've heard 20X productivity is possible for one person, but maybe that's just bragging) then I guess you pretty much do what they want.
But maybe this is connected to why pair programming can work in some cases. I guess that the reason one star programmer can be so wildly productive is because they have the whole problem in their head. Sort of like having enough RAM to hold all the data in memory at one time. This gives a problem solver a tremendous advantage over someone working in a more piecemeal fashion. Perhaps working in pairs can allow a team to get a much bigger problem space fully inside the "cognitive RAM" of the team.
Resistence is futile.
Or maybe it's just about documentation, like you mentioned. That would be a lot right there.
Or maybe it's peer pressure. Like you'd be embarassed for someone to see the awful hack you are about to slip into the code, so you don't do it because you're buddy is sitting right there watching.
Still, I agree, it wouldn't make any sense to force something like this on an unwilling team.
|
He's a real programmer doing some interesting things out in California. His company employs extreme programming. I've read some about this, but I've never talked to anyone who actually programs this way. The main idea involves pair programming.Seems cool, but my intuition accords with his findings: it's a good way to go if the people involved are very skilled programmers. On the other hand, putting me together with someone else on my level wouldn't really be very helpful. I wonder if it's something specific about coding that allows this to work, or could this approach benefit other pursuits?
- jim 2-18-2002 5:26 pm
it's a truism that productivity varies enormously between developers with similar levels of training and experience. i forget the locus classicus for this but i think the usual soundbite is that a great developer can be 5 x more productive in a given unit of time than an average one.
my experience around the outside of various development projects confirms this empirically to an extent...often a given team or department will have one "star" who always ends up doing all the hard stuff -- either because their manager assigns it to them, or because they can't bear waiting around for some other joker to get it done.
so my question would be, how do the "stars" react to this pairing? if they are amenable, great -- presumably they can muse aloud on what they're doing while their partner learns a whole lot by watching over their shoulder. a side benefit could be that the partner will understand the code well enough to document it (not a treasured past-time of the hot developer, i've noticed). and i could see lots of potential benefits for hands-on testing if they're self-testing, or for interacting with separate testing team if that's the structure...so far so good.
but what if the hotshots don't like it? then you ain't gonna get much upside...and you could potentially get blowback -- slowdown -- loss of interest -- assigning a signpainter to sit on every move Van Gogh makes isn't going to speed up production of the masterpieces...
very curious
- big jimmy 2-19-2002 12:09 am
Yeah. Again, I don't really know, but I think this is what Dave was saying. Namely, it works out if everyone is top level talent, but maybe not otherwise. In any case, if you have a star (I've heard 20X productivity is possible for one person, but maybe that's just bragging) then I guess you pretty much do what they want.
But maybe this is connected to why pair programming can work in some cases. I guess that the reason one star programmer can be so wildly productive is because they have the whole problem in their head. Sort of like having enough RAM to hold all the data in memory at one time. This gives a problem solver a tremendous advantage over someone working in a more piecemeal fashion. Perhaps working in pairs can allow a team to get a much bigger problem space fully inside the "cognitive RAM" of the team.
Resistence is futile.
Or maybe it's just about documentation, like you mentioned. That would be a lot right there.
Or maybe it's peer pressure. Like you'd be embarassed for someone to see the awful hack you are about to slip into the code, so you don't do it because you're buddy is sitting right there watching.
Still, I agree, it wouldn't make any sense to force something like this on an unwilling team.
- jim 2-19-2002 1:43 pm