Ethical Software by Alex Bunardzic

As an early Rails adopter, I am very curious about the adoption patterns of this framework. Just this past weekend I had the rare opportunity to witness first hand the inroads Rails is making into the local IT community.

I’ve spent approximatelly 14 hours (7 on Saturday and another 7 on Sunday) teaching Rails from the ground up to a very nice group of people. The group was fairly representative of the typical IT practices, ranging from the back-end database specialists all the way to the front-end user experience specialists, with pretty much every other IT-based walk of life in-between.

I must say that I’ve enjoyed the interaction that ensued during the two day workshop, but would like to focus here mostly on the challenges that were presented to me while teaching the course.

Challenge #1: Different Levels of Experience

Despite the fact that the workshop was dubbed as the absolute beginner’s introduction to Rails, there were a fair number of developers in attendance who were quite well versed in working with Rails. One of the participants was actually an advanced Rails programmer, with a couple of fairly nifty Rails solutions already under his belt.

This posed a bit of a challenge to the group dynamic, because the rest of the truly absolute beginners couldn’t really follow the discussions that tended to break the flow of the workshop. Luckily for the Rails newbies in attendance, the more experienced participants were incredibly polite and civil about their needs, and made their best efforts not to interrupt the prescribed flow of the course. I am very greatful to them for showing such level of tolerance and maturity.

That, however, made me a bit apprehensive of how to design future workshops. I strongly feel that we must strive to make it very clear what is the intended audience for the course. We are planning to offer an advanced Rails workshop, and similarly wouldn’t want inexperienced developers to join the course and slow down the proceedings.

Something to think about. Not sure if there is a readily available solution for these kinds of challenges.

Challenge #2: Show Me How!

Rails has been dubbed as a disruptive technology, and rightly so. There are several reasons why it deserves to be characterized by the disruptive moniker, one of which is that it tends to go against the grain. This was very apparent during this course. The ingrained tendency of most software developers (myself being no exception) is to focus, right out of the gate, on how. How is this thing working? How do I make it do such-and-such? The curiosity is insatiable, as we’ve been trained to pick everything apart, look under the hood, figure out what is it that makes it tick.

But right off the bat, the Rails fundamental philosophy is different. It introduces a radical, revolutionary shift from focusing on how to do something to focusing on what needs to be done. This is the promise of the radical simplicity that Rails brings to the table. Once we free ourselves from the tyranny of how, we will all of a sudden discover that we are quite spontaneously starting to focus on the quality of the product we’re building.

Prior to this revolution, the concerns about quality of the end product tended to get masked by our enthusiasm about figuring out various nifty tricks and techniques that allow us to commandeer the underlying technology. Now with Rails, many of these efforts had become superfluous.

Still, old habits die hard. It was painfully obvious during this workshop how much developers crave raw code, and how little they care for learning about the fundamental orientation needed for developing properly in Rails. Any time we switched from the orientation instructions to actually showing some code on the screen, you could feel the room come to life. The participants simply wanted to get their hands dirty, and didn’t show much interest in partaking in the discussion on the governing principles behind the code.

That made me very concerned. The tendency to want to stick only to the how violates the very essence of Rails. It goes directly against the laziness is virtue principle that Rails so successfully brings to the fore. I’ve tried very hard to instill this laziness principle into the participants, but didn’t leave the course convinced that all the attendees took the advice to their heart.

I will now have to think a bit harder about how to present to the potential Rails developers the importance of mastering the spirit of this technology before rushing into sticking to the letter, and to other formal characteristics of it.

We’re Not Going to Bore You with Theory

The situation is not much better out there. A quick perusal of what’s currently being offered in terms of Ruby on Rails training reveals similar disdain for a methodical and reasoned approach to mastering this technology. One of the instructors even promises not to bore course attendants with theory (Get Started with Rails).

This kind of shameless catering to the weaknesses of one’s potential clients is now pretty much only possible in the wild world of software. Imagine a driving school offering a course to teach people how to drive where they promise ‘not to bore the candidates with theory’. So yeah, forget all about the traffic rules, traffic signs and signals, and the myriad of other vitally important abstract information regulating the safe flow of traffic. Instead, why don’t you just hop into our training vehicle and get your hands dirty. We will show you how to drive the car, and will not expect you to understand what is going on around you. We will provide you with a nice flat lot where you can go nuts and step on the gas and knock yourself out driving around. Isn’t that fun?

And at the end of our intense one day immersion course, we will provide you with a nice shiny diploma certifying that now you’re the Master Driver!

Giving You Just Enough Rope to Hang Yourself

It is the above shameless catering approach (’we will do anything for your buck’) that worries me when it comes to the adoption of Rails. One thing I would hate to see even more than Rails not being adopted in the software development circles is it being adopted in a half-assed way. And if people continue insisting on attending such courses where no one will bother them with any theory, that’s exactly what’s going to happen. People will walk away from such sessions with just enough rope to hang themselves.

Talk about shooting oneself in the foot.