The "real world" can eat my shorts
Yesterday, Robby messaged me that he was invited to be a speaker at Sys-Con Rails Conference. (Sorry, I’d have a link for you, but I’m getting a 500 page right now.) Right in the title, it mentions Ruby on Rails in the “real world”. I am unable to suppress a groan every time I hear that quoted phrase ”real world”.
The “real world” label is used to legitimize. If something works in the “real world”, that basically says it’s not a toy, it’s for real. But if you look around at what works in the real world, you might ask yourself, “Why on earth would I want to imitate that?” I certainly do. The “real world” is filled with lame, difficult, buggy, costly software.
This relates to a point from DHH’s keynote at RailsConf that I’ve been meaning to reiterate. DHH essentially said that he lives in a fantasy world. I don’t think most of us realize how lucky we are that he does.
Imagine if he didn’t. Imagine DHH working on a nascent ActiveRecord and being closely in touch with the “real world”. Certainly, he would want it to be legitimate, not merely a toy. To be legit, it should solve “real world” problems. The “real world” is full of complex databases. It better support any imaginable scheme for primary keys, even composite ones. Anything less would… hmm, not work well in the “real world”.
The point is, we should be eager to say no to features. But in the “real world”, it is rare to find someone eager to do so. Sure, I can imagine my super-gizmo-mondo-cool coffee cup that is also a mobile phone, razor, electric toothbrush, talking tire gauge, and bottle opener. But why?! Just because it’s possible, does not mean that it’s desirable.
Really, our ability to live in a fantasy world, even briefly, is a terribly two-edged sword. It gives us the ability to imagine a world that does not exist, and execute the steps necessary to manifest it. For example, Rails. At the same time, it gives us the ability to imagine a world that does not exist, and execute the steps necessary to manifest it. For example, J2EE.
One of those two is thriving in the “real world”, according to the connotations normally associated with that phrase. I think we’re trying too hard in the wrong direction if we are chasing the “real world”. Rails is a disruptive technology; and that is something to be celebrated.
Rails does not need to be legitimized.
That’s my opinion. In fact, I think we do a disservice to the disruptive potential of Rails by trying to legitimize it with the “real world” label. I may be reading too much into the “real world” phrase in the Sys-Con event title, but since it is billed as being for CEO’s, CTO’s, etc., I don’t think so.
I think Rails is highly relevant to creating real world applications, meaning those that assist people to achieve their goals by doing much more with far, far less complexity. That requires us to have a vivid imagination and vibrant fantasy life. In other words, a good, healthy distance from the “real world”.
2 Responses to “The "real world" can eat my shorts”
Sorry, comments are closed for this article.
July 21st, 2006 at 02:24 AM The real world can eat mine too. Reminds me of an IBM business consulting ad I saw at PDX on Tuesday. The copy: "What sets you apart?" The image: several coffee cups on a table, one with a headphone jack. Real-world inspiration.
July 21st, 2006 at 06:50 AM Lovely rant. I'm thinking you might be better off co-opting the term "real world" then fighting the natural connotation that real world technologies are serious, legitimate, and desirable. Who wants an illegitmate solution to anything? Only anarchists and outlaws (not that I have anything against either class). You want Rails to be legitimate. You don't want it to be overly complex, unimaginative, and enterprisey. Change the meaning of "real world" from heavy complicated, buzzwordy, everything for everybody to light, agile, effective, and capable of economically solving real world business problems. Some of those real-world issues which comlicate info systems are real issues -- things like scale, distribution, fault tolerance, data integrity, security, and modeling the neccesary complexity of your application domain; others are just cruft designed to let you get away with failing to refactor 30 year old cobol schemas and engage armies of mediocre code monkeys without them shooting each other in the feet. We want to address _real_ problems and continue to opinionatedly ignore the noise. That makes the technology ready for the Real real world.