8 ms·

The Costs of Keeping Your Rails App Up to Date, Or Not

51 points by samullen 13y ago

decasia 13y ago
As a Rails developer, naturally I appreciate the thought that testing is good and upgrading is nice. But it seems a bit odd to advocate a completely context-insensitive heuristic for deciding whether upgrading frameworks is a good idea. Surely there are cases where the costs exceed the benefits, for any number of unpredictable organizational reasons. For instance, the application is on life support and slated to be replaced, and there are other ways of mitigating new security risks in the meantime...
- pessimizer 13y ago
  >it seems a bit odd to advocate a completely context-insensitive heuristic for deciding whether upgrading frameworks is a good idea. For a contractor who generates income from upgrading Rails? Not likely. The answer will always be: "If it is possible to upgrade, you should have us upgrading for you." Excellent and traditional way to turn a 5 hour job into a 50 hour job.
  - decasia 13y ago
    Not going to disagree with that analysis. Relatedly, there was something odd to me about the tone or implicit audience of that article, as if it was written more to persuade managers than developers.
bdcravens 13y ago
I can’t even guess how much time I’ve saved by using Arel, CoffeeScript, SASS, and the Asset Pipeline I don't think that we've seen these types of "innovations" in 4.0 or 4.1 beta. (not saying they're not valuable, only addressing developer productivity discussion) Also, you have to subtract learning curve from time saved - over time, it's a net win, but not immediately. By keeping your application up to date, you ensure that you’ll have a larger pool of developers who can maintenance your application. Isn't there a period of time where this isn't true? For a while, you'll reduce the pool of available developers, as not everyone gets up to speed right away on the latest version.
- Robin_Message 13y ago
  Most decent developers will want the opportunity to work on the latest version. Certainly keeping reasonably current is much lower risk than not upgrading.
  - bdcravens 13y ago
    Wanting to work on, and being qualified to work on, are 2 different things. I'll agree that keeping reasonably current is best. To that end, I think there's a sweet spot - probably 6-12 months after a minor or major version upgrade.
krisdol 13y ago
While much of this is true, I feel like all complex web applications require almost all of this sort of maintenance. I don't see how rails is any worse in this regard than Django. If you can't afford to address the security concerns in rails, I'd like to know the alternative that provides rails-like functionality while improving the upgrade process.
- patio11 13y ago
  Consider using railslts.com. It's a drop-in replacement for Rails 2.3 and gets you off the security-patch treadmill. (I was sort of the instigator and first customer for it. Great people and a great product, even though things have been much quieter for the last 11 months or so than I was expecting on the Rails 2.3 security front.)
deleted 13y ago
[deleted]
nmcfarl 13y ago
This answer would completely put me off building a Rails app, as a business owner. My we might be using a four-year-old copy of Photoshop, or Word. But my Rails consultant tells me that after he builds my 3 user internal accounting app I'm going have to pay him for 10 hours every time a point release of rails comes out – which is about quarterly – at his rate, which is say $150 an hour. Now my three user app has upkeep costs of 6K year. With no improvements at all. No thanks – I'll go look for technology where every point release doesn't require $1500 worth of work. Or where I can find a consultant who actually weigh the costs and benefits to me.
- learc83 13y ago
  >my 3 user internal accounting app Why would you require bespoke accounting software for such a small company? I'm with you on the overall problem though. If you do need a custom solution, it doesn't really make sense to put it on the public internet where it's exposed to constant attack. A good old fashioned desktop app is your best bet for something like this (or a rails/django/whatever app that's not on the public internet).
  - nmcfarl 13y ago
    Honestly three accountants isn't that small of a firm - I was thinking of a firm that had around 500 employees and had such an app. They certainly paid for bespoke software for more than just their accountants.
- awj 13y ago
  Here's the upgrade logic I would use for your use case: * Is your accounting application exposed to the Internet? Then I'm going to recommend an upgrade for every security release. Because your app is probably handling something sensitive enough that you'd want to protect it. * If your app isn't on the open Internet, it probably needs upgrades at each minor release at most. Maybe not even then, but minor releases of Rails often include features that are meaningful to end users. * If we're already working on other changes I'm likely to try to bundle the version upgrade as part of it. Mostly because staying current means I can reduce new feature costs to you by the new/updated libraries I otherwise wouldn't be able to use. Sound better?
gaius 13y ago
Colour me naive, but there are two things in an application in a managed language: the runtime, and the actual app. For example, in Javaland there is the JVM, and maybe something like JBoss, and then there is your code. You can upgrade the JVM or JBoss, and obviously test, but it's not that big a deal, unless you have done something egregiously stupid, your code will "just work". The same if you have used .NET. Hell the same if you have used Perl CGI, you can upgrade Perl and Apache to your heart's content. So why is everything in Rails so much work? There are entire books written on "deployment". No other language has this.
- j45 13y ago
  Rails specifically does not prioritize being backwards compatible. Terms like "opinionated" are used to promote this as a feature and benefit by some who border on being apologists. As a polyglot, it's a little baffling. What concerns me is the ability to have a relationship with a codebase for more than a year or two in Rails without significant refactoring and reworking that Ruby and Rails was supposed to save me in another language. One of my very smart and experienced friends, a Rails developer, spent most of his time debugging and converting a existing Rails app. I don't think he was creating or adding, just trying to maintain it. How can one prepare for the reality that some of our projects may stick with us for more than a year or two? I more and more value the ability to deploy code easily, anywhere, without having to keep different versions of virtual machines for different gems/libraries and codebases. I've never experienced some forms of mandatory dev ops like I have in Rails. It's cool and configurable, but it's creating value for making my life easier, not my users. A reality is, every line of code written today can easily be seen as future "garbage code" in 5 years. The available tools and skills of the same developers generally will be better. Still, I have those half decent scripts and apps written over 10 years ago that I never got back to touching, because they kept working. Buddies of mine that still hack a script in Perl because they need it not to be expensive to keep long term makes more and more sense, except I never learnt Perl too much. Rails though, remains a reasonably fast way to prototype, but not the only one. If I were a Technical VC, I wouldn't fund a Rails startup because I know how much time they'd be spending re-factoring vs. creating value. Rails is not alone anymore (nor was it the first useful framework), most languages are very decent, and they all have more than capable frameworks. For Ruby, frameworks like Sinatra I've found to be inviting (and more open to making a mess). Choice and options in all syntaxes is good, along with opinions and preferences that pontificate that every framework is somehow an advantage when MVC, generally is MVC. All of this points to the fact that customers don't care what you code in as long as you don't have to re-code it because the cement will harden in a few years. Universally, what gets put off now, waits for me later in some form of tech debt, something worth considering in any language and framework.
dylandrop 13y ago
The conversation in this comments has become a lightning rod for Rails hate, and the "impossibility" of upgrading! (Somewhat to be expected on HN.) However, for almost all Rails developers, upgrading is usually not a huge issue, at least since Rails 3 came around. I've been doing Rails development for 3 years, and I've yet to spend more than a couple hours on an upgrade. All in all, you have to realize this -- Rails upgrading troubles are something that happen once a year, maybe twice a year at best. In the worst case it'll take about half a day of work. Is it really worth tossing the whole framework out just because of that? Here's my take on the 4 possible issues the author mentioned: 1) If you're >= Rails 3, almost all upgrades are painless. Even Rails 3 -> Rails 4 wasn't that bad, as the only sort of breaking change was strong parameters. The difficulty of changing that varies greatly on the size of your application, but it's more likely just a tedious couple hours of work and you're done. 2) Application size - see above. 3) Use of external libraries - eh, what I usually do is just wait a few weeks when the next edge Rails comes out, and by that point, the open source community has fixed its stuff. Or, even better, contribute! 4) Test coverage - I've never been at a legitimate Rails shop that doesn't do test coverage. Testing is brought to the extreme with all Rails apps -- and if you aren't writing tests, you probably aren't a Rails dev.
- bronbron 13y ago
  What usually happens is people decide to upgrade everything all at once, since they're investing the time anyway. So they upgrade to Ruby 2, Rails 4, JQuery 2, etc. all at once. Since the big driver was to upgrade Rails initially, Rails becomes the focal point of all the once-deprecated-now-removed errors that occur. That being said, upgrading from Rails 2 -> 3 was pretty annoying.
- stiff 13y ago
  Apps of how many LOCs have you migrated? I have been migrating one and the same Rails app from version to version for around 5 years now, and we are currently at around 50k lines of code. When you are taking about "couple hours of work" and "painless" I can only laugh out loud. Every new minor or major Rails version migration takes several weeks with any larger app, only patch versions can be migrated reasonably smoothly. Migration from Rails 2.3 to Rails 3.0 was a particular catastrophe, it took me more than a month of intensive work, after the switch the application became twice as slow, which turned out to be a regression in the PostgreSQL driver that went unnoticed for a year since Rails 3.0 was first released. Just diagnosing this single issue took me a week of frustration, where I step by step peeled the onion of abstraction upon abstraction, having to profile Rails internals in the end. We are now looking into the Rails 3 -> Rails 4 migration, and it's not much better, after just changing the gems the application won't start, the console won't start, and the tests run into an infinite recursion and explode the stack. I routinely spend a week even to get just those three basic things to start at all, and it was this way even when migrating 1.x to 2.x. After every upgrade of this kind, some gems turn out to be abandoned are not upgraded by the authors to support the newer Rails, and seldom they will work with them without changes. The ones that were updated, often require a separate upgrade procedure of their own, there goes another week. Just fixing all the deprecation warnings will take another one. It's not just strong parameters, a lot of the old routing code does not work, conditions on relations don't work anymore, config settings become obsolete and so on and so forth, 80% of the things that have to be changed are not even in the release notes, for example Rails 4.0 happened to introduce an internal Options class that is visible from every controller and shadows our global Options constant which is the object with application configuration. It does not mean Rails "sucks" or anything like this, but keeping a very nice API while adapting a framework to requirements evolving over the years has the cost of sucking at compatibility, that's just a fact of software engineering. So please lets not pretend the Rails team top priority is ease of long term maintenance and lets put things as they are. If you are not systematically keeping up with newer Rails version, after half a year or 9 months since the last update you won't even receive bugfixes, because they often aren't backported even to the previous minor version. That the 37signals guys threw out their own biggest app and rewritten it from scratch is also telling about their attitude to things of this kind. So Rails is bad at compatibility, in exchange it keeps delivering a really nice API for a wider and wider scope of tasks.
rartichoke 13y ago
I'd rather have semi-painful upgrades if it means making progress and not being stuck with a horrible base of a product. Being stuck with bad design decisions because the framework core team is too busy worrying about making incompatible changes and moving at a snail's pace for new features is exactly how you become obsolete. For some reason large changes in society rarely happen until entire generations of people die. Things move so slowly because people somehow fear change. I for one love rails because I know the core team will make big changes if it's clearly for the better without worrying about pissing people off because in the end it's obviously the correct move.

51 points by samullen 13y ago

As a Rails developer, naturally I appreciate the thought that testing is good and upgrading is nice. But it seems a bit odd to advocate a completely context-insensitive heuristic for deciding whether upgrading frameworks is a good idea. Surely there are cases where the costs exceed the benefits, for any number of unpredictable organizational reasons. For instance, the application is on life support and slated to be replaced, and there are other ways of mitigating new security risks in the meantime...

pessimizer 13y ago
>it seems a bit odd to advocate a completely context-insensitive heuristic for deciding whether upgrading frameworks is a good idea. For a contractor who generates income from upgrading Rails? Not likely. The answer will always be: "If it is possible to upgrade, you should have us upgrading for you." Excellent and traditional way to turn a 5 hour job into a 50 hour job.
- decasia 13y ago
  Not going to disagree with that analysis. Relatedly, there was something odd to me about the tone or implicit audience of that article, as if it was written more to persuade managers than developers.

bdcravens 13y ago

I can’t even guess how much time I’ve saved by using Arel, CoffeeScript, SASS, and the Asset Pipeline I don't think that we've seen these types of "innovations" in 4.0 or 4.1 beta. (not saying they're not valuable, only addressing developer productivity discussion) Also, you have to subtract learning curve from time saved - over time, it's a net win, but not immediately. By keeping your application up to date, you ensure that you’ll have a larger pool of developers who can maintenance your application. Isn't there a period of time where this isn't true? For a while, you'll reduce the pool of available developers, as not everyone gets up to speed right away on the latest version.

Robin_Message 13y ago
Most decent developers will want the opportunity to work on the latest version. Certainly keeping reasonably current is much lower risk than not upgrading.
- bdcravens 13y ago
  Wanting to work on, and being qualified to work on, are 2 different things. I'll agree that keeping reasonably current is best. To that end, I think there's a sweet spot - probably 6-12 months after a minor or major version upgrade.

krisdol 13y ago

While much of this is true, I feel like all complex web applications require almost all of this sort of maintenance. I don't see how rails is any worse in this regard than Django. If you can't afford to address the security concerns in rails, I'd like to know the alternative that provides rails-like functionality while improving the upgrade process.

patio11 13y ago
Consider using railslts.com. It's a drop-in replacement for Rails 2.3 and gets you off the security-patch treadmill. (I was sort of the instigator and first customer for it. Great people and a great product, even though things have been much quieter for the last 11 months or so than I was expecting on the Rails 2.3 security front.)

deleted 13y ago

[deleted]

nmcfarl 13y ago

This answer would completely put me off building a Rails app, as a business owner. My we might be using a four-year-old copy of Photoshop, or Word. But my Rails consultant tells me that after he builds my 3 user internal accounting app I'm going have to pay him for 10 hours every time a point release of rails comes out – which is about quarterly – at his rate, which is say $150 an hour. Now my three user app has upkeep costs of 6K year. With no improvements at all. No thanks – I'll go look for technology where every point release doesn't require $1500 worth of work. Or where I can find a consultant who actually weigh the costs and benefits to me.

learc83 13y ago
>my 3 user internal accounting app Why would you require bespoke accounting software for such a small company? I'm with you on the overall problem though. If you do need a custom solution, it doesn't really make sense to put it on the public internet where it's exposed to constant attack. A good old fashioned desktop app is your best bet for something like this (or a rails/django/whatever app that's not on the public internet).
- nmcfarl 13y ago
  Honestly three accountants isn't that small of a firm - I was thinking of a firm that had around 500 employees and had such an app. They certainly paid for bespoke software for more than just their accountants.
awj 13y ago
Here's the upgrade logic I would use for your use case: * Is your accounting application exposed to the Internet? Then I'm going to recommend an upgrade for every security release. Because your app is probably handling something sensitive enough that you'd want to protect it. * If your app isn't on the open Internet, it probably needs upgrades at each minor release at most. Maybe not even then, but minor releases of Rails often include features that are meaningful to end users. * If we're already working on other changes I'm likely to try to bundle the version upgrade as part of it. Mostly because staying current means I can reduce new feature costs to you by the new/updated libraries I otherwise wouldn't be able to use. Sound better?

gaius 13y ago

Colour me naive, but there are two things in an application in a managed language: the runtime, and the actual app. For example, in Javaland there is the JVM, and maybe something like JBoss, and then there is your code. You can upgrade the JVM or JBoss, and obviously test, but it's not that big a deal, unless you have done something egregiously stupid, your code will "just work". The same if you have used .NET. Hell the same if you have used Perl CGI, you can upgrade Perl and Apache to your heart's content. So why is everything in Rails so much work? There are entire books written on "deployment". No other language has this.

j45 13y ago
Rails specifically does not prioritize being backwards compatible. Terms like "opinionated" are used to promote this as a feature and benefit by some who border on being apologists. As a polyglot, it's a little baffling. What concerns me is the ability to have a relationship with a codebase for more than a year or two in Rails without significant refactoring and reworking that Ruby and Rails was supposed to save me in another language. One of my very smart and experienced friends, a Rails developer, spent most of his time debugging and converting a existing Rails app. I don't think he was creating or adding, just trying to maintain it. How can one prepare for the reality that some of our projects may stick with us for more than a year or two? I more and more value the ability to deploy code easily, anywhere, without having to keep different versions of virtual machines for different gems/libraries and codebases. I've never experienced some forms of mandatory dev ops like I have in Rails. It's cool and configurable, but it's creating value for making my life easier, not my users. A reality is, every line of code written today can easily be seen as future "garbage code" in 5 years. The available tools and skills of the same developers generally will be better. Still, I have those half decent scripts and apps written over 10 years ago that I never got back to touching, because they kept working. Buddies of mine that still hack a script in Perl because they need it not to be expensive to keep long term makes more and more sense, except I never learnt Perl too much. Rails though, remains a reasonably fast way to prototype, but not the only one. If I were a Technical VC, I wouldn't fund a Rails startup because I know how much time they'd be spending re-factoring vs. creating value. Rails is not alone anymore (nor was it the first useful framework), most languages are very decent, and they all have more than capable frameworks. For Ruby, frameworks like Sinatra I've found to be inviting (and more open to making a mess). Choice and options in all syntaxes is good, along with opinions and preferences that pontificate that every framework is somehow an advantage when MVC, generally is MVC. All of this points to the fact that customers don't care what you code in as long as you don't have to re-code it because the cement will harden in a few years. Universally, what gets put off now, waits for me later in some form of tech debt, something worth considering in any language and framework.

dylandrop 13y ago

The conversation in this comments has become a lightning rod for Rails hate, and the "impossibility" of upgrading! (Somewhat to be expected on HN.) However, for almost all Rails developers, upgrading is usually not a huge issue, at least since Rails 3 came around. I've been doing Rails development for 3 years, and I've yet to spend more than a couple hours on an upgrade. All in all, you have to realize this -- Rails upgrading troubles are something that happen once a year, maybe twice a year at best. In the worst case it'll take about half a day of work. Is it really worth tossing the whole framework out just because of that? Here's my take on the 4 possible issues the author mentioned: 1) If you're >= Rails 3, almost all upgrades are painless. Even Rails 3 -> Rails 4 wasn't that bad, as the only sort of breaking change was strong parameters. The difficulty of changing that varies greatly on the size of your application, but it's more likely just a tedious couple hours of work and you're done. 2) Application size - see above. 3) Use of external libraries - eh, what I usually do is just wait a few weeks when the next edge Rails comes out, and by that point, the open source community has fixed its stuff. Or, even better, contribute! 4) Test coverage - I've never been at a legitimate Rails shop that doesn't do test coverage. Testing is brought to the extreme with all Rails apps -- and if you aren't writing tests, you probably aren't a Rails dev.

bronbron 13y ago
What usually happens is people decide to upgrade everything all at once, since they're investing the time anyway. So they upgrade to Ruby 2, Rails 4, JQuery 2, etc. all at once. Since the big driver was to upgrade Rails initially, Rails becomes the focal point of all the once-deprecated-now-removed errors that occur. That being said, upgrading from Rails 2 -> 3 was pretty annoying.
stiff 13y ago
Apps of how many LOCs have you migrated? I have been migrating one and the same Rails app from version to version for around 5 years now, and we are currently at around 50k lines of code. When you are taking about "couple hours of work" and "painless" I can only laugh out loud. Every new minor or major Rails version migration takes several weeks with any larger app, only patch versions can be migrated reasonably smoothly. Migration from Rails 2.3 to Rails 3.0 was a particular catastrophe, it took me more than a month of intensive work, after the switch the application became twice as slow, which turned out to be a regression in the PostgreSQL driver that went unnoticed for a year since Rails 3.0 was first released. Just diagnosing this single issue took me a week of frustration, where I step by step peeled the onion of abstraction upon abstraction, having to profile Rails internals in the end. We are now looking into the Rails 3 -> Rails 4 migration, and it's not much better, after just changing the gems the application won't start, the console won't start, and the tests run into an infinite recursion and explode the stack. I routinely spend a week even to get just those three basic things to start at all, and it was this way even when migrating 1.x to 2.x. After every upgrade of this kind, some gems turn out to be abandoned are not upgraded by the authors to support the newer Rails, and seldom they will work with them without changes. The ones that were updated, often require a separate upgrade procedure of their own, there goes another week. Just fixing all the deprecation warnings will take another one. It's not just strong parameters, a lot of the old routing code does not work, conditions on relations don't work anymore, config settings become obsolete and so on and so forth, 80% of the things that have to be changed are not even in the release notes, for example Rails 4.0 happened to introduce an internal Options class that is visible from every controller and shadows our global Options constant which is the object with application configuration. It does not mean Rails "sucks" or anything like this, but keeping a very nice API while adapting a framework to requirements evolving over the years has the cost of sucking at compatibility, that's just a fact of software engineering. So please lets not pretend the Rails team top priority is ease of long term maintenance and lets put things as they are. If you are not systematically keeping up with newer Rails version, after half a year or 9 months since the last update you won't even receive bugfixes, because they often aren't backported even to the previous minor version. That the 37signals guys threw out their own biggest app and rewritten it from scratch is also telling about their attitude to things of this kind. So Rails is bad at compatibility, in exchange it keeps delivering a really nice API for a wider and wider scope of tasks.

rartichoke 13y ago

I'd rather have semi-painful upgrades if it means making progress and not being stuck with a horrible base of a product. Being stuck with bad design decisions because the framework core team is too busy worrying about making incompatible changes and moving at a snail's pace for new features is exactly how you become obsolete. For some reason large changes in society rarely happen until entire generations of people die. Things move so slowly because people somehow fear change. I for one love rails because I know the core team will make big changes if it's clearly for the better without worrying about pissing people off because in the end it's obviously the correct move.