language parallax

Several months ago I ran across the video of a keynote talk given by Martin Fowler at RailsConf ‘06.

I’m not a user of Rails, or of Ruby for that matter. But I’ve been keeping an eye on it for a while. All the fancy Domain Workbench stuff isn’t going to be ready for years, and so there remains the question of how to be an efficient developer of web applications using today’s technology. Fowler puts Rails in a larger technological and even philosophical context:

It starts off on an unexpected note:

It’s a little bit odd, I think, that I’m giving a talk at the Rails conference. […] I actually haven’t used Ruby on Rails. […] I just haven’t had the need to write a database-backed web application. I do keep asking my wife: ‘Dear, would you like a database-backed web-application for anything?’ Because I’d like to use rails, but I want to use it on something real, not just something pretend.

Which almost sounds like a thinly-veiled insult… I think his intent is to force the audience out of their comfort zone and get them thinking honestly about the limitations of Rails and its position in the ecosystem of programming environments.

Ruby on Rails decided it wasn’t going to try to be the faramework that was the right framework for all kinds of applications. But instead it says: “We have a definite philosophy about the kinds of applications that this framework is good for.” Which is, unsurprisingly, is linked to the application that it was harvested from.

He gives a specific example of one of the assumptions it makes: Active Record, which is the pattern that assumes a 1:1 mapping between objects and tables.

It works really well if you’ve got a relatively simple application and you’ve got control of the database schema and you’re quite happy with this 1 to 1 mapping. It really sucks if you’ve got some dba group, and trying to get a new column added to a table requires sacrificing three virgins and one of your fingers. As a result, a lot of people — including myself — saw active record as a pattern that wasn’t really that useful in an enterprise setting.

BUT:

If you can live in a world where Active Record makes sense, it makes things a lot easier.

So why bother working with a framework that has limited applicability?:

The result is a focus and a simplicity on a particular kind of problem, which i think is at the essence of Rails’ success. I’m quite happy with the fact that it doesn’t cover a lot of cases.
[…] The idea of one framework that will do everything for you is in my mind an absolute disaster. […] Even if rails was to die tomorrow as a application framework, it’s already had such an impact that the whole things has been worthwhile.

Next he addresses a notion of a basic tradeoff in software engineering: That quick necesssarily means dirty.

If you look at a lot of the discussions about software development, you kind of see two camps. Over here is the visual basic or the php crowd. Being in the enterprise crowd, of course, I have to say that with disdain. There attitude is, “Yeah, we can build it really fast, we can get something up and going. We’ll get you the application you want by the end of the week.”

And then over here, of course, is the true enterprise-y people, who say, “Well, yes, you can get us this by the end of the week, but then it will be an unmaintainable mess, because as these kinds of applications grow, there’s no structure to them, and as a result it’s all going to have to be thrown away and rewritten and its all going to have to be redone in a proper enterprise style. And we can give you that 1-week application in 9 months done properly.

[…]

And at the heart of this is that to do something quick, it has to be dirty, and therefore an unmaintainable mess. And that if you want to do something well, it has to take a hell of a long time to do it. […] But I don’t believe that that’s actually the tradeoff.

Rails’ automatic file layout generation is an example of this.

The next big theme he discusses is the nature of the conversation between the customer and the engineer.

“Conversational Software Development” At the heart of this is the notion is that it’s not a 1-way stream of”this is what I want’. Very much embedded in a lot of the thinking about software development is the notion that out there are customers. They know what they want. And if you can only get them to tell you exactly what they want and you then build it, then everything will go well. But of course the dark secret around this is that people don’t really know — well they may know what they want — but they don’t really know what they need. The hard part about software development — in fact the hardest part of software development (and most likely area to send software projects down the tubes) is when you’re not really building what people need. You can build exactly what they want and still screw it up because you didn’t give them what they needed.

[…]

The essence of the way in which Kent Beck [the eXtreme Programming guy] thinks about exploring it […] is the notion of a very rapid feedback cycle between the developers and customers that turns it from a “listening to the customer” requirement into this “conversational” mode.

An analogy:

It’s kind of like if you’re going to shoot a gun, you’re going to fire first, and then you’re going to aim. And that’s clearly a stupid way of doing things, isn’t it? Well, it depends on what you’re firing at and how cheap the bullets are.

He describes it as “fire aim fire aim fire aim…” vs. “aim aim aim aim aim aim aim… fire”, and argues that rails provides us an environment to change the nature of that conversation.

He briefly touches on the advantages of close physical proximity to the client. “Being close to the customer is important,” but he notes the process has to work such that you actually have things to show them in those little conversations.

He also mentions the fact that websites can push the requirement gathering step all the way out until after the code has been shipped to production by guessing at something reasonable and then observing how real people actually interact with it. Though again, the “bullets have to be cheap” in order for this process to work.

He explores further the role of the software engineer:

I’m actually not that interested in the software part of software development in many ways. I’ve written a book that’s got several hundred pages on database mapping, but frankly I wish it would just go away. All of this technical plumbing stuff is terribly interesting for lots of people, but it doesn’t really interest me that much. What I’m more interested in is how does the business work? What are the business rules? Database mapping is boring, but the weird and wonderful arcane rules that a payroll organization has to have for a big company are actually quite fascinating. […] But the problem is that there’s so much complexity in the plumbing that you get dragged into object/relational mapping and other pointless stuff. The great thing about rails is that they can make that stuff go away.

Amen to that. I think most programmers I know are pretty sick of dealing with the plumbing.

Then he gets a little philosophical:

One of Smalltalk’s great failures was and is the fact that it wants to be everything. [..] You can start up the virtual machine, but you can’t pass it any arguments. […] “There’s only smalltalk, because why would you want anything else.”

There’s a little software movement out there called “postmodern programming”. […] A modernist building is plain and simple and all the little pieces look the same and build up to a big thing that kind of looks the same. The idealist world of software in this world is kind of like building with legos. We have all of these lego bricks and they’re all kind of the same, and they fall fit together neatly, and everything’s the same across the world.

Look at any real software system, like for instance one of these [holds up a PowerBook], […] this is the closest thing we’ve probably seen to Alan Kay’s dynabook. […] On the other hand go on the inside of this stuff, and what’s it running? Its running UNIX — the biggest hunk of cobbled together stuff that the world has ever seen. […] Lots of people then make it even worse by downloading all sorts of crap off the internet, and runnning that on top of it as well. And the crap is so bad that you even need package management systems to keep track of it all for you.

[…]

The point is that UNIX is an incredibly successful piece of software. It’s still around. There are tons of better designed operating system out there that have disappeared.

[…]

This is the point the postmodernists make. yeah, it’s a hodgepodge of all sorts of stuff. big complicates of environemnts and frameworks like gnome, and tiny little things like iconv or something. it’s a whole mess of different stuff at different scales […] just like if you look at nature.

[…]

The Smalltalks and LISPs have always looked at that stuff with a real disdaining eye: “I want everything to be an object or a function.”

The part about postmodernism is the most interesting part of the talk. At no point does he get into all the stuff he’s seen at Intentional or JetBrains. I suppose in the interest of time and focus, he can’t cover everything at every talk. But I think this hat-tip to postmodern programming is his way of alluding to a larger host of issues out there. I’m particularly happy that he addressed the single-minded lego-like dogmatic cleanliness that many developers succumb to at some point during their careers.

Finally, he ends the talk on a warm and fuzzy people-oriented note:

Tools are interesting, but they’re not really that important. The most important thing is people.