Slashdot Mirror
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."
From XP web site:
"Extreme Programming (XP) was created in response to problem domains whose requirements change. Your customers may not have a firm idea of what the system should do. You may have a system whose functionality is expected to change every few months. In many software environments dynamically changing requirements is the only constant. This is when XP will succeed while other methodologies do not."
I'm no expert, but isn't this exactly what OOA and OOD is all about? Isn't the whole point of OOA and OOD to get away from the "waterfall method" and allow changes in requirements, use cases, code, etc...?
what? that's not extreme programming! that's regular programming! XP goes against "big up-front design" -- which is exactly why they chose it for this particular project!
xp wants: no big up-front design (just small "user stories" and maybe use cases), plus no big arduous code reviews (because of collective ownership and paired programming)!
get a clue!
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.
I have all the respect in the world for these guys... programming methods or no, what they did and are doing is priceless.
.
I was in New York on Sept 11... flown in on a C-141 as part of the rescue/relief effort (the rest of my Urban Search and Rescue team had to drive... I beat them there by a number of hours). That was the most unique flight I've ever been on, since by then the entire civilian air fleet had been grounded... between us and the f-15s, we were basically the only things flying...
Closure is important, and these guys are providing it... I'd like to shake their collective hand and buy them a nice cold beer.
Even if a man chops off your hand with a sword, you still have two nice, sharp bones to stick in his eyes.
I have been doing extreme programming for 4 years, and I started with pair programming. Since from the wording of your comment, I take it you haven't tried pair programming for yourself, please, allow me to share my experience.
First, let me begin with how I started pair programming:
I started pair programming in the tutoring way you describe. I was "coder B" in your scenario: fresh out of university, I just joined a development team between projects, so there wasn't too much pressure. But the environment and tools used were mostly new to me. Our team wasn't doing any Extreme Programming at that time, but our "Coder A" read about it and wanted to try it out. There are serveral practices in Extreme Programming, and pair programming was the one he found the most intruiguing. Since I was the newbie, he wanted to use me as a guinea pig to see if he could bring me up to speed faster.
Like you, I really wasn't convinced at first, but he was the guru, and me just a newbie, I really couldn't refuse. So after a few days, I finally accepted and reluctantly sat next to him in front of his console. All I would do for now is watch, while Coder A codes stuff and explains what he is doing so that I can follow what is going on. Luckily, it was some Python code. Even I at that time I hadn't even heard of Python, I could kind of figure out what was going on in a particular loop. But I had no idea about the higher level of the design, and the first pair programming session was very painful. After 2 hours, my head was about to explode. I did learn a few things about Python, but that was about it.
The next day, we tried again. I was even more reluctant given the previous bad experience, but anyway, I sat down, repressing a sigh. Again, painful time, headache... But somehow, the code structure started to appear to me, like pieces of a puzzle magically putting themselves together. But one piece wasn't fitting. Coder A was stuck on a problem and asked me if I had any idea. Again, I wasn't even sure what was going on, I had only a very high level and blurry view of the system. Yet, somehow, I could see the problem with that piece had something to do with granularity. Being a newbie talking to the guru, I sheepishly apologized for not being sure what a certain function really did, but suggested anyway adding an argument and removing a certain loop. I really had no idea what I was saying. Just, in my blurry picture, that would make the puzzle piece fit. Coder A pondered the idea for a few seconds, then his eyes popped wide open and he exclaimed: "You're a genius!". Then he went into a coding frenzy by himself and I was lost again, but I knew something special happened there. Sure, that was in a tutoring setup you described, but that is actually a generality of pair programming: while the driver (the coder at the keyboard) takes care of the low level details, the navigator (the coder watching) keeps track of the higher levels of the implementation, and thus can point the driver in the right direction.
Now, let me answer your concerns with what I have learned from practicing pair programming:
Wasteful:
You do loose some raw speed from having only one keyboard typed on instead of two, but actually not that much: whenever you get stuck on something, pair programming gets you unstuck really quick. In raw lines of code per hour, I think the loss is something around 15%. But this is largely made up for in code quality. I found that pairs produce much higher quality code than individual programmers. Therefore, you also save time on debugging and code maintenance.
Stressful:
It can be at times. See my first session of pair programming. First thing: pair program with someone you get along with well. After you got used to them, pair programming sessions are still very intense, since they keep you totally focused, with constant peer review, for the 2 hours they usually last.
However, I found an overall reduction in stress level thanks to pair programming. It's a bit like doing a lot of sports h
I code, therefore I am.