Compound Thinking

Will Ruby and Rails save my IT Department?

My client is not an IT person and he knows nothing about programming…. I started sharing [Ruby on Rails] with him…. About ten minutes into my presentation he interrupted me and said, “So, this could save my IT department, couldn’t it?”

This is from Dave Thomas’ blog, where he is quoting an e-mail where Eric Knapp just gushes about the possibilities that Rails brings to the table. It seems nice enough, and everybody is well intentioned. But, I must admit I have my doubts. First of all, it sounds like a thousand non-technical managers getting sold on some new technology without taking time to understand the real life benefits and risks.

But it goes further than that, I doubt that Rails will ever save anybody’s IT department.

Can it make IT departments more productive? Absolutely. But when a department is broken that’s not usually just because they have bad tools, it’s because the staff either aren’t interested in finding better tools, or they are crippled by organizational red tape, or they are too afraid to tell management that the current tools suck.

“Whatever they say the problem is, it’s always a people problem.”
– Gerald Weinberg

Rails, TurboGears, Django, Plone, and even Zope and EJB 3 all offer the hope of more productive web development. Better tools are important. But a growing, healthy, team can discover, evaluate and when necessary the fit between these new tools and their current projects is the critical factor in long term success.

Rails may appear to be the world saving framework today. But it is not the end of the road, people are hard at work inventing better tools (for example, SQLAlchemy is poised to become a far better Dynamic Language based ORM than ActiveRecord), and if your team can’t evaluate new tools as they come they will end up stuck when Ruby on Rails is surpassed by other tools.

If you Rails is the end of the line, rather than just a remarkable jump forward –which will itself be left behind by new tools in the future — you’ve been fooled by the hype machine.

By the way, since I’ve noticed a few people in the Rails/Ruby community have a thin skin, this whole post should in no way be understood anti-rails. The problem is not the technology it is the marketing and the the uncontrolled hype which doesn’t admit the limitations of the technology.

But, in the same way that Rails won’t save your IT Department, TurboGears will not save you, nor will Zope, or EJB 3.

You have to save yourselves by becoming a place where software teams have the freedom to learn, grow and experiment with new tools.

Python, Ruby, Rails and Readability

When developing code you should always choose readability over convenience. Code will be read many, many more times than it is written…

–Practices of an Agile Developer by Venkat Subramaniam Andy Hunt

This quote from Ruby advocate and Rails book author Andy Hunt, explains why I work in Python even though Ruby has anonymous blocks and slightly less historical baggage than Python.

I recently taught a couple of free introductory classes, one for Python and another for Ruby. People with little experience in either language, could quickly read Python code. But with Ruby — and Rails in particular — there is so much heavy use of the “power features” of the language — like dynamic classes — that code readability was severely compromised. New programmers were quickly confused and lost. There were lots of “where does this happen” questions. Dave Heinemeier Hanson carries most of the blame here: Rails is built on his philosophy that values “convention always trumps configuration” and “less code is better” so highly that other critical considerations like the value of locality and orthogonality play in making code readable. In my view this is a serious mistake. After all, Code is read more often than it is written!

Wherever possible methods should be understandable on their own. No matter how powerful dynamic classes and objects are, using them means there will always becode elsewhere in your system that changes the behavior of the code you write — that means you have to know about and understand all of that elsewhere just to understand — and debug — the object in front of you.
For example, Rails has this nifty feature where Database classes map to table names that are the plural of the class name. This auto-pluralization like other Rails hacks is cute and fun at first, and it certainly makes the surface of the code shiny and pretty, but it also creates a layer of indirection and “magic” that obscures what is happening under the covers.

Of course, sometimes you have to make hard choices and it’s worth sacrificing code readability for other concerns. I’m not disputing that, I’m just saying the code you write — if it’s used and maintained — is going to be read many, many more times than it is written. So, you ought to optimize for the code reading experience, and more than any other language I’ve used, Python is designed just that.

TurboGears at Penguicon

I’ll be doing an hour and a half introduction to TurboGears next weekend at Penguicon. So if you are in Great Lakes area, and you want to get a jump on developing dynamic ajax-enabled web applications feel free to stop by. It should be a lot of fun.

But, I’m not just plugging my talk, I’m also looking for help. I would like to video-tape my tutorial, and need a couple of people to help me make that happen. I think I can get one mini-dv camera, but I’d like to set up a second camera for crowd shots, close up shots, and various other pieces. To really make this work I would also need somebody to help with cameras and sound.

Ultimately, if we can make it work out I’d like to post this so that we can have a more extended TurboGears tutorial available online.

Framework Comparison Video

Sean Kelly has posted an interesting comparison (warning 60 min video!) of Rails, TurboGears, Django, Plone, and Java Sevlets/JSP, and full fledged J2EE development.

There is a lot of interesting commentary on this movie floating around out there, so I thought it might be worth while to try to gather some of that commentary in one place.

Overall, I think the message of the video is: The “Dynamic Language Frameworks” are all demonstrably better than their Java counterparts for web based application development. These frameworks allow you to make small incremental changes to the user interface as you test your ideas with real users.

And this conclusion is exactly right — user interface design is hard, and it requires the ability to iterate and deploy incremental improvements.
But before I move on to other people’s commentary, let me say a couple of things from my own perspective:

1. Plone rocks for a certain set of problems, which it can solve out of the box.
2. Sean uses TurboGears 0.8. Had he used the newly released 0.9 he would have been able to get authentication and automatic CRUD. Someone made his application with something like 9 lines of TG 0.9 code! :)
3. Rails and Django also have internationalization frameworks now too (For those of you where this is important, I think Django and TurboGears do internationalization better than Rails because of Python’s Unicode support).
4. His application is pretty trivial — a real test for these applications would look better for the TurboGears framework.

On the web people have been saying (I’ll do my best to be complete, and get the attribution right):

• He’s very kind to Zope/Plone, if you step out of the Plone box then the cliff is indeed there but if you stay inside Plone everything tends to look like Plone and act like Plone and that isn’t that useful. That said, I’m sticking with Zope. — Simon Lucy
• This Lessig-style presentation is mostly good, especially if you want to compare J2EE to web frameworks in general… it clearly shows how using any of these frameworks will drastically decrease your development time and lines of code, and generally make your life a lot more fun. — Jeff Croft
• I should point out, though, that his version of Django was a little outdated, and his impressions of it had a few inaccuracies. Django’s got excellent i18n support, and for a while now it’s been able to use it without a database. Still, as long as someone’s not using J2EE, that’s a win for all of us dynamic-language freaks :) — Jacob Kaplan-Moss

My complaint (and it is a minor one) is that Sean seems to get a lot of things wrong about TurboGears, Django, and Rails, so it’s not very good at providing insight into which of these frameworks is going to be the best fit for your particular needs.

Most of the problems I have with his analysis stem from the fact that these three “dynamic language frameworks” are growing and evolving very quickly.

TurboGears, Rails, Django, Plone, and Zope 3 are building the future today. I’m most connected with the future of TurboGears, and I have to say that the changes that are coming present a lot of exciting possibilities. If this is any indication of what is happening in Django, Zope and Rails, then the future of Python web development frameworks looks very bright indeed.

Ruby on Rails class

The folks over at the Ruby users group have decided to hold a Ruby on Rails class for free. Patrick Hurley will do the heavy lifting for the class, and Humantech is supplying space for us to use for the class. Patrick has significant Rails experience in real-world enterprise deployments, and I for one am looking forward to hearing what he has to teach.

The class is scheduled for the afternoons of Saturday, March 11 and Saturday, March 25.

If you would like to enroll in the class all you have to do is:

1. Go to Compound Thinking’s course site
2. Click on “Ruby on Rails”.
3. Create an account (if you don’t have one already!).
4. When prompted for the enrollment key, enter “rubymi-222″.

For now at least, this class is Ann Arbor–In Person only.

The first 25 people to sign up get in, so even if you sign up, you might not get a seat, since I have to close enrolment manually when the class gets full, but if you do enroll, and we don’t have room, I’ll let you know as soon as possible.