Dualoping our Mod

It was not long ago when I read about pair programming. The idea is that two programmers sit tandem in front of one computer and one drives (types the code) and the other navigates (fixes, supervises, guides). Basically, the idea behind this concept is that two heads are better than one, and alot more can be brainstormed with two programmers working on the same code than a single one.

We accidentally tested this method, one day, with our mod development (hence dual development or dualoping - har har). I was struggling to program, when my brother decided to come watch me code (if you can call it that). First he sat there looking at the lines of code on the screen, not really knowing what they all mean. Then, slowly, he began to ask questions about certain lines of code. When I started to answer him, I realized that he was indirectly helping me to see the big picture and some of the mistakes that I had made. Unknowingly, he had become my navigator as I drove drunkly down coding lane in my C++ Lada.

The next time he was modeling, I sat down with him, and I started to observe quietly at first then little by little I gave him some ideas and my opinions on what he was doing. Soon, we were modeling together, asking each other how this would look, how that would look. We also textured the models together and it did not even take us that long to finish our model. Thus we see that the pair programming idea

We would like to also extend this idea to level designing too, and see how that will affect our creations.

To sum up, we extended the concept of pair programming to almost every facet of our mod development, and noticed an increase in the productivity (we were encouraging each other also) and the overall quality of what we were doing. Of course, this is possible if two members live in close proximity, something that does not always apply to every mod team. However, this could perhaps be applied to game developers, who house mostly everyone in the same work place.

On the bright side, if things start to get awry during development, you can always blame the person next to you...