Pair programming / animations

Tried out pair programming the other day. I can definitely see it working, especially on hard topics (i.e. where you spend lots of time thinking, explaining, arguing and brainstorming that just typing in code). I am still not sure whether it really suits for "ordinary" day-to-day programming though.

The topic I and Joe tried it on was a pretty hard one - related to the core animation system. Now, of course I don't know anything about animation systems, but my impression is that there is just no "universal" way of designing it. The ones that are floating around inside free/open engines/libraries (cal3d, nebula2) are quite fine, but not much more impressive than my own very simplistic attempts at doing animations. There is nothing wrong with that of course - its simple, it gets the job done, and its okay in most of the cases when you're doing simple stuff.

But then, if you want something more advanced, you either have to go and get the big serious libraries, or just... well... not do it.

So, back to pair programming - making the core animation system that would have transitions, continuous blends, animation layers, bone masks and whatnot (and the kitchen sink of course!) is just not very easy. We paired basically on writing the pseudocode of the system, or some sort of outline; changed the implementation several times along the way, and in the end we're left with a really nice and fast system and the code is actually quite simple. Much of the credit for that goes to Joe, as he found out some really cool ways to optimize the expensive things away (at that time we were not doing pair programming anymore - I went to do some research on shadows!)

But to reiterate - pairing can definitely work. I guess mostly because the other person just keeps asking "why you're doing this?" or "this is wrong" or "we're in a deep shit now" or "that's awesome" :)

In a day to day programming pair programming is more of a quality assurance method. Like an extreme peer review ;) Two programmers are not just less likely to do unintentional bugs, but they are way less likely to cut corners. Two programmers will "do the right thing" even if it takes more time, is more difficult or boring.

And of course like with all the quality assurance methods - you get some quality you lose some speed, it's a trade off. Works for me though ;)
i had to do pair programming for a project in college. it did not work out well. i think an important part is for the pair to be peers - ie of similar skill/experience level.

at microsoft some of the benefits of pair programming are achieved by having code reviews for every checkin. this means you can go off and write a bunch of code at your own pace and then before you check in you get someone else on the team to go over it. in practice this was mostly a waste of time and the reviews didn't find too many bugs. instead it was lots of debating about equivalent ways of implementing things or trivial minutiae.

where i work now a much better system is used. you can check in code without needing a code review, but team leads take time to review the code that is checked in. so it's not every checkin, but more like every once in awhile or after an important change a lead goes through the changes carefully looking for errors. this plus a culture that encourages very efficient and clean code plus constant testing seems to work very well.
> I went to do some research on shadows!

What is your target to achieve with shadows right now? If that is not a NDA of course :)
ReJ: of course, shadows from everything onto everything, with zero artifacts, handling all corner cases and running insanely fast on any hardware!

Was that helpful? :)
Yeah, that was rather enlightening :)
Post a Comment

<< Home