As developers we toss around quite a few acronyms. Most of them are positive like, TLA, REST, and TATFT. And of course there are few of them which are not so good, like NIH. Today, I propose a new acronym for the not-so-good list: ISTR or I’m Smarter Than Rails.
We developers like to think of our self as an intrinsically smart bunch. Well of course we are! We create web sites and applications out of funny spelled words and esoteric symbols. We can be smart within the confines of frameworks, or we can be smarter than our frameworks. But be careful, being smarter than our frameworks will only doom as all.
We all love frameworks because they remove lots of the heavy lifting we have done in their absence. Rails is pretty good implementation of a web framework. More and more sites are popping up using Rails because it is easy to use and extend.
At some point, we have all bumped into a limitation of Rails. Either it didn’t exactly fit the mold of what we were trying to do, or it was too slow, or it just did something completely different than we would have done it originally. We have a few options at this point.
A) We can embrace the constraint, and potentially come up with another solution which doesn’t defy the conventions.
B) We can extend the framework with the conventions, and contribute our change back to the Rails core.
C) We can defy conventions and patch Rails to our will.
At some time or another all of these conventions are the right course of action. But I’m here today to evoke the feelings of bad juju when go with route C. When you patch Rails to your whim and break conventions, you start a chain of potential problems.
The first problem is that you might not be able to upgrade Rails to the newest versions that may contain important security patches or other functionality. Being able to upgrade Rails is pretty important. The farther you drift away from the base, the more likely it is that you won’t be able to drift back when you are ready.
Another problem is unforeseen complexity. If you are changing the Rails framework, you are in no doubt introducing new complex idioms. These idioms may seem perfectly fine to the implementer, but will be Greek to the person who will inherit this code in the future. The new maintainer won’t have the benefit of the community when it comes to diagnosing and amending the code base.
So, to all of you who think ISTR, why don’t you prove it by implementing easy to understand solutions and contributing the community for further scrutiny and maintenance through submitted patches to the core or through plugins?
Previous Topic
