Frameworks and Productivity

Yesterday was frustrating; I spent far too long trying to debug some problems in a Rails application I am writing. Rails, and frameworks in general, are supposed to give us improved productivity by hiding the complexity and mechanics of the task at hand. This is great as long as the framework behaves as expected, but invariably causes problems when things go wrong.

The missing field

My application uses associations, and I had a belongs_to association that was supposed to be populated in a before_validation_on_create callback. In my tests I noticed that the linked model was not being instantiated. After much searching, it turns out I had forgotten to create the foreign key field. Unfortunately Rails was silent on this issue and the belongs_to association code seemed to execute quite happily without the field.

Can't dup NilClass

My models also use has_many associations, which I could populate with no problems. When I tried to access the association though, I kept getting Can't dup NilClass errors. This one turned out to be an issue with the generated collection.build method. As noted in the documentation by the somewhat cryptic Note: This only works if an associated object already exists, not if it‘s nil!, the method fails if the collection is empty (at least that's what I think it means). Explicitly instantiating the associated model and then adding it to the collection fixed the problem.

Bad choice of name

In my application I had a model named Target, which meant that models that associate with Target, such as my TargetProfile model, have a target attribute.

Unfortunately the target attribute in TargetProfile always returned the instance of TargetProfile - not quite what is expected. The problem was caused by the fact that ActiveRecord's AssociationProxy, used to implement associations between models, has a target attribute. The documentation contains another warning Don‘t create associations that have the same name as instance methods of ActiveRecord::Base, but mentions nothing of AssociationProxy, which isn't even part of the documented api. I call this broken encapsulation.

The Rails Way

Rails heavily promotes testing and Test Driven Development (TDD), which is linked to the "fail early, fail fast" paradigm. It seems strange that known issues (as partially documented) are allowed to persist and cause silent failures. All the issues above could have been flagged by Rails.

Conclusion

I am not picking on Rails, however, as these type of issues seem to occur in many frameworks. No software is bug free, and a framework has to work hard to hide the complexity and mechanics of its domain. When things go wrong, we are always left questioning whether the issue is in the framework or in our application and we invariably end up getting to know the implementation details of the framework, which does little for our productivity.