What (if any) technical debt am I incurring with Ruby on Rails?

Question

I'm a big fan of ruby on rails, and it seems to incorporate many of the 'greatest hits' of web application programming techniques. Convention over configuration in particular is a big win to my mind.

However I also have the feeling that some of the convenience I am getting is coming at the expense of technical debt that will need to be repaid down the road. It's not that I think ROR is quick and dirty, as I think it incorporates a lot of best practices and good default options in many cases. However, it seems to me that just doesn't cover some things yet (in particular there is little direct support for security in the framework, and plugins that I have seen are variable in quality).

I'm not looking for religious opinions or flamewars here, but I'd be interested to know the community's opinion on what areas Rails needs to improve on, and/or things that users of Rails need to watch out for on their own because the framework won't hold their hand and guide them to do the right thing.

Answer 1

Regardless of framework the programmer needs to know what she's doing. I'd say that it's much easier to build a secure web application using something as mature, well designed and widely adapted as Ruby on Rails than going without the framework support.

Take care with plugins and find out how they work (know what you do, again).

Answer 2

I love Rails too, but its important for us to understand the shortcomings of the framework that we use. Though it might be a broad topic addressing these issues wont hurt anyone.

Aside from security issues, one other big issue is DEPLOYMENT on Shared Hosts. PHP thrives in shared hosting environments but Rails is still lagging behind.

Of course most professional Rails developers know that their apps need fine-tuned servers for production and they will obviously deploy on Rails-Specific hosts.

In order for Rails to continue success the core team should address this issue, especially with Rails 3.0 (Merb +Rails) coming..

An example of this is simple: I have a bluehost account, and i noticed the Rails icon in my cpanel. I talked to the bluehost support and they said its more or less a dummy icon, and that it doesn't function properly.

Having said that any professional who wanted to deploy a Rails App would not use bluehost. , but it does hurt Rails, when hosts say that they support it and then users run into problems which their support know nothing about..

Answer 3

The article you refer to defines technical debt as

[the] eventual consequences of slapdash software architecture and hasty software development

With rails, any development that is not test driven incurs technical debt. But that is the case with any platform.

At an architectural level Rails provides some deployment challenges. A busy site must scale with lots of hardware or use intelligent caching strategies.

My advice to anyone adapting Rails would be to:

• use TDD for all your development
• verify the quality off any plugin you use by reading its tests. If they are not clear and complete, avoid the plugin
• read "Rails Recipes" and "Advanced Rails Recipes" (Advanced Rails Recipes has a good recipe for adding authentication in a RESTful way)
• be prepared to pay for hardware to scale your site (hardware is cheaper than development time)

Answer 4

From my experience, by far the biggest tolls you end up paying with RoR are:

• Pretty big default stack (not counting plugins you might be using)
• Updating models tends to be a pain in the ass, at least in production servers.
• Updating Rails or Ruby themselves is a bit more complicated than it should, but this differs depending on your server setup.
• As ewalshe mentioned, deployment is sometimes a drag, and further down the road, should you require it, scaling gets a bit iffy, as it does with most development frameworks.

That being said, I'm an avid user of RoR for some projects, and with the actual state of hardware, even though you do end up paying some tech debt to using it, it's almost negligible. And one can hope these issues will be reviewed eventually and solved.

Answer 5

With any level of abstraction there is a bit of a toll you pay - genericized methods aren't quite as fast as those specific to something built just for your purpose. Fortunately though, it's all right there for you to change. Don't like the query plans that come out of the dynamic find methods? write your own, good to go.

Someone above put it well - hardware is cheaper than developers. I'd add "at a sufficiently low amount of hardware"

Answer 6

I'm reading Deploying Rails Applications and recommend it highly to answer your concerns.

The book is full of suggestions to make life easier, taking a deployment-aware approach to your Rails development from scratch, rather than leaving it to later.

I don't think the choice of RoR implies a technical debt but just reading the first few chapters alerted me to practices I should be following, particularly on shared hosts, such as freezing the core rails gems so you can't be disrupted by upgrades on the host.

The 30-page chapter on Shared Hosts includes memory quote tips such as using multiple accounts (if possible) with one Rails app per account. It also warns about popular libraries such as RMagick possibly pushing your memory size to the point where your processes are killed (such as a 100MB limit, which it suggests some hosts periodically apply).