What's wrong with "magic"?

Question

Well, consider a couple bits of Rails "magic": when you write a controller class, its methods have access to certain variables and certain other classes. But these variables and classes were neither defined nor imported by anything in the file of Ruby code you're looking at; Rails has done a lot of work behind the scenes to ensure they'll just be there automatically. And when you return something from a controller method, Rails makes sure the result is passed along to the appropriate template; you don't have to write any code to tell it which template to use, where to find it, etc., etc.

In other words, it's as if these things happen by "magic"; you don't have to lift a finger, they just happen for you.

By contrast, when you write a Django view, you have to import or define anything you plan to use, and you have to tell it, explicitly, which template to use and what values the template should be able to access.

Rails' developers are of the opinion that this sort of "magic" is a good thing because it makes it easier to quickly get something working, and doesn't bore you with lots of details unless you want to reach in and start overriding things.

Django's developers are of the opinion that this sort of "magic" is a bad thing because doesn't really save all that much time (a few import statements isn't a big deal in the grand scheme of things), and has the effect of hiding what's really going on, making it harder to work out how to override stuff, or harder to debug if something goes wrong.

Both of these are, of course, valid stances to take, and generally it seems that people just naturally gravitate to one or the other; those who like the "magic" congregate around Rails or frameworks which try to emulate it, those who don't congregate around Django or frameworks which try to emulate it (and, in a broader sense, these stances are somewhat stereotypical of Ruby and Python developers; Ruby developers tend to like doing things one way, Python developers tend to like doing things another way).

In the long run, it probably doesn't make a huge difference for the factor you say you're concerned with -- billable hours -- so let your developer choose whatever he or she is most comfortable with, since that's more likely to get useful results for you.

The primary problem occurs when you don't understand the magic. This can lead to anything from applications that are badly neutered all the way to sporadic, fatal crashes.

Magic is great until something breaks. Then, you've got to figure out how all those tricks work.

For more, do read Joel Spolsky's Law of Leaky Abtractions

Magic obfuscates functionality. It creates behaviors implicitly instead of explicitly, such that the programmer has no need to understand how the behavior works, and more importantly, how they might go about changing it.

When a coder has a complete grasp of the code base they are working with, "magic" can be a big productivity gain. But when working with a third-party system like a web framework, which has a high degree of complexity, it may take much longer to gain that level of expertise.

Now, to the matter of who you should hire to do the job: if you are concerned about the long term ability of other programmers to understand your contractors' code, it may make sense to go with Django (it is certainly my preference). However, there are many, many Rails experts out there who can maintain your website well into the future.

The choice should come down to who among the contractors you are evaluating, a) have a proven track record, and b) you trust. A good developer will do well on either Rails or Django.