Hacks are not good. Hacks should not be done all the time. But sometimes, shipping is more important than beauty and elegance. Hacks you put up while you get the real, good code in place is next to godliness when working in multicomponent systems under tight deadlines. Rails just isn't as good when you need to do that sort of thing. It doesn't have that flexibility, by design!
When I write the hacked up glue code first so they can do their stuff while I write mine, they f-ing love that. It lets them do their job!
I do things "the right way" 99% of the time. That buys me incredible flexibility to use utter crap code that's otherwise functional that other 1% of the time when required by the job.
Regardless, I'm weary of claims that controller-level (django view level) code is a major pain point in Rails. In some ways it's actually easier since you can make fewer decisions by making them resource centric, but even deviating from that is as simple as map "/path", :to => "controller#action".
Rails/Django controllers/view and routing/urls aren't as elegant as micro-frameworks like Flask and Sinatra or not-so-micro-frameworks like Padrino, but they aren't anything close to serious stumbling blocks (though maybe routing to a very small degree in resource-centric Rails 2). Every blocking issue I've had with either framework has been on a deeper level. In Rails pre-3, it was usually configuration-related when trying to do something too unconventional. In Django, it's when trying to deviate from the overall Django philosophy and use something other than the included batteries.
Use case:
iPhone dev "can you do this"
Ruby dev "Sure, takes a sec to rejigger things to allow that"
A few minutes/hours later "Done, and its perfect"
Alternative
iPhone dev "can you do this slightly differently"
Django dev "Like that?" [Just mocked up the entire thing in pure text, django happily returns it]
iPhone dev "thanks"
Django dev "I'll go make that work right now now that you can integrate your code
I have a real problem with the inability to provide a good enough version now when its more valuable than a very good version later, especially when there is room in the schedule to deliver both.
I work in an integration based environment, where the turnaround on the backend development is the maximum schedule issue, not the overall development scheme. I don't want my software development effort to look like the execution of a python program in a GIL bound multiprocessor environment. I want the thing done asap, if that means I'm paying the backend guy to redo his code 3 times cause the prototype is valuable and speeds up final time, I want the flexibility to do that.
I'm Excited that rails 3 promises to help part of this (as you correctly surmised, it is mostly rails 2 code and coders and turnaround issues I've dealt with), but I haven't yet seen it very much yet at all.
Schedules, requirements and all that are great, but if you can put a little hustle in at the end when there is something big on the line and get paid for that, you have very happy customers and very fat wallets. Non software people like delivery and there is a modicum of debt that sometimes requires.
