Gentlemen’s Agreements
BMW and Mercedes produce cars in direct competition. Further, everyone else in the auto industry likes to use them as benchmarks. Read a car magazine and count the superlatives like “more legroom than a Mercedes S500” or “more horsepower than a BMW 330i”. Its a market out there; everyone is incentivised to produce better stuff every time around.
However, you won’t ever find them boasting about top speed1. BMW or Mercedes don’t make cars that go faster than 155 MPH. Many moons ago, these car makers made a gentlemen’s agreement to limit their cars to a certain top speed. They probably did this for safety reasons - there just isn’t much need to go that fast and its probably inadvisable for most folks.
Why adhere to these agreements? At any point, BMW or Mercedes could break this agreement and achieve some kind of short-term numerical superiority. But this would end in an arms race that doesn’t really improve the every-day usage of their cars. So really, it’s in each company’s interest to maintain the agreement.
In the land of software development, we have gentlemen’s agreements as well. When I picked up Python in 1999, I learned that they didn’t have a distinction between public, protected and private object attributes. Many decried this, but the general idea was that we’re all adults and do the responsible thing.
Fast forward six years years. At first I was somewhat put off that Rails modifies the standard Ruby libraries. Many people are still put off about this. But I’m OK with it. If you have the chance to drive improvements in an ecosystem without waiting for the core maintainers to release a new version of Ruby, why not?
Many also decry the situation we find around Rails plugins. Its argued that one shouldn’t go around mucking about inside Rails to add functionality. And sure enough, plugins sometimes break when the core team changes Rails, even in the slightest of ways.
No surprise, I’m fine with this. Improving a system from the inside is too appealing to pass up so that I can claim some kind of virtuousness.
Should Rails have a defined internal interface or extension mechanism? Sure, sounds great! But we shouldn’t stop improving it outside the Rails core process just because sometimes we get burned.
The alternative is to define a known set of hooks by which we can modify behavior in a post-hoc fashion. Merb is taking this approach, and I’m eager to see how it works out. My take is that limiting people to extension along axes that the core developers imagined in a pre-hoc manner is too limiting. I hope I am proven wrong.
When it comes to Ruby or Rails, I think we already have a gentlemen’s agreement. We accept that extending systems using the facilities Ruby provides is useful, so we don’t complain too much when we get burned2. Accepting this is, in my experience, an empowering aspect of using Ruby that lets me worry about really interesting problems.
1 Except maybe for the M and AMG tuner variants of their mass-production cars
2 where “too much” is defined by the prudence of the extension mechanism used
