Ryan Sloan

or The One in which I Rebuke all things Shiny and Cutting Edge

Living your life on the bleeding edge can be exciting (I mean heck, Aerosmith wrote an entire song about it.) The Edge is an exciting place — gadgets are shinier, smaller, and more expensive there. It’s hard to resist the allure of a new gadget, or the features of a new technology. We’re all guilty of it from time to time. All it takes is one press release, one vague and over-hyped magazine article, or (for some of us) a late night TV commercial with a 1-800 number plastered across the bottom of the screen. Next thing you know you’re busting out the plastic. Trust me, I own a Snuggie or two. I think there’s some law of nature that says “He who Dies with the Shiniest Stuff Wins.”

It’s bad enough to spend roughly the money supply of Turkmenistan on new gadgets, but it’s when this mentality carries over into other fields that it becomes really dangerous. When I say “other fields” what I really mean is “software development.” I have had two experiences with this, and both of them had one thing in common (other than the fact that the projects were overwhelmed by the shininess.) In both cases, it was decided (once by an executive decision and once by a vote) that we would be using Ruby on Rails for a new project. There is nothing wrong with Ruby on Rails, but on both teams, there was only one person who had written so much as a line of Ruby in his life. I’m going to talk about the most recent project in this post, because it was equally stressful and frustrating but it has a happier ending. Blogging is a lot like writing a summer blockbuster in that respect.

DISCLAIMER: This post is about to descend into what many will call “RoR bashing” but I assure you it’s not. Rails is a badass framework, and I hope it’s going to be around for a long time. This isn’t about the technology itself, it’s about the “let’s use what’s hot right now” mentality.

One of the Computer Science courses that most every Computer Science student at Georgia Tech has to take is CS3300 - Introduction to Software Engineering. It’s the second course where students are assigned a large team project. (The first being CS 2340, which I wrote about in my previous post “Adventures in Teamwork“) In this course, each team is instructed to come up with an idea for a software project, and go through the Software Development process to bring it to life. We decided to build a web app that would detect the user’s location (using HTML 5 geolocation services) and find the nearest restrooms with crowdsourced cleanliness ratings and comments. (We decided to call it “Poopt,” for anyone who was wondering. I can never resist a pun. Apologies to Sam Altman.) It would run in any web browser that supports HTML 5, but the target would be mobile phone users. I got the idea from an episode of Seinfeld where George told Jerry to give him any street corner in New York, and he could tell him the nearest clean public restroom.’

Before we even started design, one of my group members turned to us, and with a twinkle in his eye, suggested we develop our project in Ruby on Rails. The other three of us got pained looks on our faces — we had never written a line of Ruby in our lives. He assured us that both Ruby and the Rails framework were easy to learn, and that RoR could essentially do the hard parts of our project for us. Nothing gets a bunch of overworked Georgia Tech students on board like the promise of less work. On top of that, this could be a cool opportunity to learn something new! So, with some free RoR resources on hand, we decided to dive in.

Now, group work is a funny thing. It can bring out the best and worst in people. In any team, you can find at least one or two slackers (if you can’t find one, it’s you.) In my case, every member of the Poopt (it might be juvenile but I bet you grinned a little) team had agreed to learn Ruby and do their part. Things started off well — our RRoRG (Resident Ruby on Rails Guru, pronounced “Rawrg”) gathered the three of us together and started explaining things. Unfortunately, after day 1, interest started to dwindle in learning Ruby. There is supposed to be this little voice in your head named “Common Sense” that says things like “Now Ryan, maybe deciding to build a (tightly scheduled) project in a language no one knows is a bad idea.” Unfortunately, my little voice was too busy drooling and saying things like “so…shiny…”

Needless to say, by the second week of our project, the team had realistically dwindled to two: RRoRG, and poor Ryan, just trying to keep up.
In the end, we finished our project, and managed to pull an A out for every milestone, but it was largely because Mr. RRoRG worked really hard. I did what I could, but we both recognized that because of our timeline, there was no time for me to try to learn, the best I could do was tweak displays and templates.. RRoRG worked long nights, and I sat at the table and try to take care of all the bureaucratic and administrative legwork. I was totally willing to learn, but with the time constraints and my other coursework, there just wasn’t enough time.
Now, RRoRG was right about one thing — Ruby on Rails DID have a lot of features that made our project much easier. It would have been perfectly suited for our project if the rest of us knew what we were doing. Sometimes, you just have to settle for the old fallback. Maybe it’s less shiny and less exciting, but when it comes down to it, you’ve got to work within the constraints of your system.
I think I can sum up this long diatribe with one sentence: Next time you find yourself rushing out to buy a Snuggie, ask yourself: will a blanket do?

Epilogue
I’d like to say thank you, RRoRG, for working long hours, trying to teach me when you could, and not lumping me in with any other dead weight that we may or may not have had. You know, some day (when I have the free time) I’d really like to learn Ruby on Rails…