Balancing Performance and Convention 171
markmcb writes "My development team was recently brainstorming over finding a practical solution to the problem that's haunted anyone who's ever used a framework: convention vs. customization. We specifically use Rails, and like most frameworks, it's great for 95% of our situations, but it's creating big bottlenecks for the other 5%. Our biggest worry isn't necessarily that we don't know how to customize, but rather that we won't have the resources to maintain customized code going forward; it's quite simple to update Rails as it matures versus the alternative. What have your experiences been with this problem? Have you found any best practices to avoid digging custom holes you can't climb out of?"
Switch to django and python for starters (Score:2, Informative)
I worked in a small shop that used rails, we found that rails is... constricting, just for the reasons you posted to slashdot for. We looked at our options and switched to django+python. Maintenance wasn't a problem after that. I'd suggest investigating a switch now while you have an opportunity.
Hard to say, but... (Score:5, Informative)
Making this sort of decision really requires more technical details than you provided in the summary or the linked article.
If you do choose to make custom modifications to Rails (or any other third party dependency in your system), make them very carefully. Keep notes about what you changed, and why. Comment the modified source code with a consistent, searchable tag, like
Also, check the third party source into your own version control system so that you can track the changes explicitly.
Since you are talking about making changes for performance reasons, be sure to follow good optimization practices. Measure first, optimize only the true bottlenecks. Measure under realistic scenarios. If optimizations are even slightly confusing or subtle, comment them thoroughly. Keep the original, unoptimized code, maybe just in comments next to the new code, or maybe in a separate "reference implementation" function so that you can fall back to a known reliable version.
Extend sanely (Score:2, Informative)
First off, I totally agree with Samschnooks that as a development team, that 5% is your responsibility, and what you're really getting paid for. But given your concerns about maintainability, and what I'm reading as your concern that custom code that you create may end up being addressed by the framework, I do have some advice.
See what of your own code can be crafted into a plugin to extend the framework. Rails plugins are quite easy to create and insanely easy to use.
Be diligent about abstracting the functionality that you need, keeping domain-specific business logic out of the plugin and in the application instead. You'll find that plugins are easy to write test cases for and will keep your custom logic very modular.
If someone else ends up releasing a plugin that addresses your needs, you can simply swap it out; the same applies if the framework gets extended to include what you need.
If maintenance is a real issue for you, release the plugin yourself as open source and recruit some assistance from the community. Chances are, you're not the only one in the world who needs the functionality.
Just start replacing stuff (Score:3, Informative)
My company started writing a big app in Rails. We hit limitations (for us) fairly quickly so just started replacing the bits we wanted to work differently. The great thing about Ruby is you can just switch stuff in and out. The great thing about Rails is that it's well-designed enough that you can do that fairly easily.
Sessions, for example. We wanted to share sessions between sites, so just stopped using the Rails one and started using ours. We just put a new session class system in a gem, require it, and talk to that instead of the built-in. Works brilliantly and with a little finesse you can make it totally transparent.
I think the key is to think of Rails as a framework - as in, a literal scaffolding that you place things in. The basic structure is sound enough and very useful. It's filled with some useful default code, but if that doesn't meet your needs, feel free to start replacing it wih things that do.
JRuby (Score:4, Informative)
Re:Switch to django and python for starters (Score:3, Informative)
And when the guy knowing Django moves on, what's the chance of finding a replacements who knows it? How much will that reduce the number of eligible applicants for a position -- will you disqualify fifty really smart guys for five mediocre ones who happen to know Django?
Probably not. In my (admittedly limited) experience, I find that Ruby on Rails and Python/Django are similarly supported, and have similar user/developer base sizes. Frankly, if I was choosing between Rails or Django, finding developers for either would be pretty far from the top of the list of my worries.
Re:Language is not the answer (Score:4, Informative)
I still remain skeptical about the benefits of model-driven-development. I recall that, at the latter end of the 1980s, developers were promised much the same thing with the push toward CASE tools. Of course, developers and managers quickly learned that such tools were only of use in a certain limited number of scenarios, and that attempting to use those tools outside of the scenarios for which they had been designed quickly led to the same problems.
Frankly, I'm not sure that "software entropy" is solvable by any sort of tool or language. Rather, it is solved by training developers to write tests, and enforcing certain minimum style standards on the code, so that any developer can look at any portion of the codebase without feeling too unfamiliar with it.
Re:That's rich! (Score:4, Informative)