Balancing Performance and Convention

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?"

Comments

Hard to say, but...

[SlashDotDotDot]

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

// MYCOMPANY Begin custom changes
// Optimized this block for queries where the
// search string is only one word long, and
// measured a 20% performance increase on the
// production server under moderate load.
// 3-Jan-2009
...
// MYCOMPANY End custom changes

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.