Mass Fatality Identification System
Shipud writes "
Bio-IT World is running a
story on how Gene Codes corporation created the Mass Fatality Identification System (M-FISys) in the aftermath of the 9/11 attacks. The story goes into the details of processing large amounts of data, aiming for a 99.9% accuracy rate, and
extreme programing."
I definitely agree that having two programmers sitting next to each other is very distracting and ultimately counterproductive (at least for me). However, I have found that the Mac programming editor SubEthaEdit (formerly known as Hydra, but recently renamed due to legal issues) can be a tremendously productive alternative. In essence, you can think of it as an alternative implementation of paired programming. SubEthaEdit allows multiple users to edit a single document in real time. It uses color coding to distinguish who has added a modified what parts of the text to make real-time version tracking easy even in an highly chaotic environment, and even supports a fairly intelligent undo system. I've found that you get the benefits of paired programming (multiple people working and reviewing code at once), yet you also don't have to constantly explain everything as you're going or have that annoyance of someone leading over your shoulder, craning at the screen. Best of all, it becomes practical to have more than two people working on a single file at once. If you want, you can do NASA-style programming and have two people just searching for bugs and two people just coding. The results can be quite spectacular. SubEthaEdit may be not be everyone's cup of tea, but I'd highly recommend you at least take a look.
Throughout my higher education we have had paired and extreme programming shoved down our throats. I consider myself to be a fairly competent programmer, and have worked with others that have a wide array of skill sets. It has helped me personally in dealing with people that have such a wide array of skill sets. My communication skills have improved drastically. I'm sure there are other things which factored in to this, but paired programming certainly played a big role. My experiences overall have been pleasant. This is entirely subjective. I know people that feel completely different, and will rationalize it to the end. But, when I have worked with less knowledgable programmers we are able to get tasks done in almost the same amount of time it would have taken me to do it by myself, and a small fraction of the time it would have taken the other person to do it. When I work with people that have similar capabilities, and especially when we have personalities that work well together, we are able to get a ton more accomplished together than we ever could individually. And, when I work with people more knowledgable than mine, the earlier situation is reversed and I have the opportunity to learn at an accelerated pace. The most helpful thing I have found in my paired programming experiences is to have an open mind because in that kind of a close environment your ideas and thoughts can be trampled on rather quickly, and you have to be able to accept that environment and both acknowledge that some solutions are better and be able to rationalize any decisions you are making. In my experience it is entirely worth it. The code usually has less bugs when testing, and the end product is much more understandable in terms of structure and future upkeep.