I’m struggling to find a balance between convention over configuration. I’ve been pounding out another Rails project and have come to benefit from many of the conventions (eg. less time spent) . But I’ve been programming for 10 years now, and there’s one thing that keeps bugging me with “convention” style programming.

• ramp up - understanding the conventions requires significant start time to using a framework.
• maintenance - most of the code you write will be maintained by someone else. All those nifty auto-dynamic-realtime tricks may take the next programmer more time to figure out than what you saved in the beginning!
• perl effect - unless you code a framework day-after-day and use the conventions, you’ll forget them in 2 months. Just like perl.

There’s something to say for spending extra time up front to be as explicit as possible. Because the time spent up front will save in maintenance over the life of the software. On the other hand, having some amount of convention prevents chaos… For example, I’ve written my fair share of new project directory layouts with make/ ant build scripts… they all look the same, take a while to customize and perfect, and each take away time from real programming. For counter-example, the Rails ‘partial page template’ mechanism loads a file where the initial underscore of the filename is ignored as long as the filename matches a the name of class invoked at runtime and is located in the /layouts directory. Good luck tracing an application bug if you missed that tidbit in the rails documentation.

I believe in the evolution of programming by creating meta-frameworks that eliminate the minutia of the past… but at what expense?

This entry was posted on Monday, June 12th, 2006 at 12:26 am and is filed under .plan.