We here at the community group have committed to the software development methodology known as Agile. Agile makes working in small groups better by, among other things, shortening the development cycle, encouraging knowledge transfer, and offering programming paradigms to make coding more efficient and enjoyable. But Agile is still new to many of us, and we're still experiencing some growing pains.

Pair programming is tough. The idea is simple: two coders working on one machine will produce code in less time that is more bug-free. The reality so far has been that time spent coding hasn't improved much and bug-freeness is arguably worse. Granted, there has been some knowledge transfer (though not nearly enough) as a result of pairing, but all told the process hasn't been nearly as effective as advertised. That being said, we're not doing pair programming correctly - it's impossible to with our group. We have people working on non-project related work. We have people who can't screen share for one reason or another. We have too much work to pair all the time. When we do pair, the non-coding programmer often has their own laptop with them, doing other work (we all have too much); they aren't always actively participating and keeping an eye out for inefficiencies and buggy code. But I also believe we the coders aren't solely culpable.

The scientific evidence backing pair programming is shoddy at best. Also, the learning curve is steep, and the potential gains are not necessarily worth it. Personally, pair programming still feels weird to me. Often I find myself just watching someone code. Usually it's with Cody who happens to be an excellent, dare I say expert, coder. So while I've definitely learned a lot pairing with him, I've only really caught typos watching him code. I haven't seen any glaring bugs in his code, nor any glaring examples of inefficient code. And I don't want to speak for him, but I think for the most part the experience for him has been similar while watching me code. So is it worth it to lose the code we could be producing separately in order to have us sitting together watching each other code? I'm not sold that it is.

Behavior Driven Development with RSpec is a programming paradigm our group has made a priority. In a nutshell it involves writing specs first, defining how your program should behave, making sure they initially fail, and then writing the code to make them pass. Henry and I used RSpec and BDD when building Envoy and it was really, really fun! We produced an extremely lightweight, yet powerful, application with 100% test coverage. And as is mentioned by BDD supporters everywhere, the psychological boost you get from seeing your tests pass as you're coding (using autotest) is not inconsequential. Every time that autotest goes green your pride gets a little boost. But BDD is also not without its problems; namely, doing it. Our group is having an awful time getting itself to write tests for its new code, partially stemming from our existing projects having very little test coverage (which I assume makes us subconsciously ask, "Why start now?"). And RSpec is fairly difficult to learn. There are the Peepcode screencasts. And there is an upcoming book - we really need this David! So hopefully as we get moving on to new projects our test coverage will consistently be at or near 100%, and we'll all become comfortable with Behavior Driven Development as a programming style.

In addition to these two coding factors, Agile as a group and project management style is a little too touchy-feely for me We have weekly meetings where we thank people and reflect. I could see the guy in this video liking it a lot (and I pick this video because this is my favorite Gilberto Gil song and I'm mildly obsessed with Brazil). It often feels excessive and over-the-top. Maybe if we had longer iterations - 2 weeks (1 month?) instead of a week - retrospectives wouldn't feel like such a drag. And perhaps as we move onto bigger and much, much better things that feeling will subside.

But Agile has some good parts. I have no qualms about User Stories, which are an extremely effective way of organizing project features. Due to my overwhelming competitive side, I of course like the point system aspect of Agile. Although with that there is the danger of becoming a workaholic. I like it when Ed, our boss, gets involved with projects as a pseudo-product owner. I think it brings an interesting perspective on the work we're doing. So while overall I have a sincere fondness for most of Agile as a programming methodology, some of it is either detrimental or superfluous to our group's ability to produce good code efficiently and many of the parts that aren't are a pain to adopt as part of our group's official programming and management style.

Just came across this awesome post that describes how to fix an annoying bug with autotest that causes it not to show up like half the time. I hated having to go back to the terminal whenever growl didn't popup; every time it was another half second of my life wasted. I must've wasted upwards of 3 minutes because of this bug. I could've killed like 3 level 11 Goretusks in that time (just started playing WoW - level 15 Human Lock, username merckens, keep an eye out for me - I'll be the guy dominating everyone). If you've noticed this problem with your autotest-growl interaction, read the post. Worked for me.