
The Costs of Keeping Your Rails App Up to Date, Or Not - samullen
http://www.samuelmullen.com/2014/01/the-costs-of-keeping-your-rails-app-up-to-date-dot-dot-dot-or-not/
======
gaius
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.

~~~
aaronem
tl;dr: "Rails: Not even once."

Everything in Rails is so much work because Rails is a rolling disaster; every
new major version replaces enormous chunks of framework functionality with
enormous _new_ chunks of functionality, which imposes a heavy load on the
developer; "convention over configuration", plus major changes to the
convention _du jour_ in every major version, equals a necessity to re-learn,
at every major version change, where the new magic lurks and precisely how it
works. If I'm being entirely fair, I can't say that the Rails developers have
_no_ interest in backwards compatibility, but such interest in my experience
is both quite spotty and heavily concentrated on obvious and conventional
behavior, which means anything non-obvious or unconventional is probably going
to need heavy rework. (I have yet to run across a Rails app which did not, at
least occasionally, do something non-obvious or unconventional, and
necessarily so; no framework can cover _every_ use case, but Rails in
particular seems interested in covering only the most common ca. 60%.)

To make matters worse, no one in the Rails community has the slightest
interest in yesterday, and even today tends to be neglected in favor of
tomorrow. You talk of entire books on the subject of Rails deployment, and
while the necessity for such books to exist is certainly a problem, actually
_having_ such a book means you're doing better than average; I've recently
been fighting my way through an upgrade of a Rails 2.3 app to run under Rails
3.2; it's a difficult enough task to begin with, and is massively complicated
by the fact that no real documentation exists on how to perform such an
upgrade. What's there is mostly to be found on various Rails devs' Tumblrs, or
in IRC logs or commit comments, and these are both poorly curated and
evanescent; I've spent quite as much time trying to collate information on
_how_ to perform this project as I have actually editing code, and if not for
the Internet Archive, a couple of critical Tumblr posts would no longer be
available at all, thanks to the Rails dev who wrote them having apparently
decided to "reboot" his blog.

The whole process has been enormously frustrating, not to mention slow; I
started this project better than six months ago, as a novice Rails developer,
and I'm just now getting to a point where I can see the light at the end of
the tunnel. I am also strongly convinced that Rails is never the right
solution; as long as I'm employed at this organization, it will embark upon a
new Rails project only over my metaphorical smoking corpse. There's just too
much to go wrong, and the underlying ideas of the Rails community are too
wrong-headed to make for a reliable platform; the purpose of a framework is to
free the developer from having to rearchitect the same infrastructure over and
over, yet Rails not only forces developers to do so during upgrades, but the
massive changes to core functionality I mentioned earlier make the
rearchitecting task enormously more complicated and painful than it'd be in
the absence of any framework at all -- I do not engage in hyperbole when I say
that I've led upgrades from PHP 4 to PHP 5 which were both less painful and
more quickly completed than the task of upgrading a single, rather small,
site, from Rails 2.3 to Rails 3.2 has been.

Rails, overall, is the worst example I've ever seen of the development model
which Zawinski calls "CADT" [1]; between that, and the deep-seated and
dangerous problems Shaw identifies with the Rails community as a whole [2],
anyone other than a Rails core developer, who involves Rails in a project of
any sort save perhaps a tiny single-developer throwaway prototype, is
borrowing trouble on a potentially catastrophic scale both for himself and for
any unwitting organization on which he chooses to inflict the resulting
disaster.

[1] [http://www.jwz.org/doc/cadt.html](http://www.jwz.org/doc/cadt.html)

[2] [http://harmful.cat-v.org/software/ruby/rails/is-a-
ghetto](http://harmful.cat-v.org/software/ruby/rails/is-a-ghetto)

~~~
trustfundbaby
I think there is some merit in this, upgrading from Rails 2 to Rails 3 was an
absolute nightmare, and after beginning, I had to stop, create a new app from
scratch and manually copy files over and edit configuration files to get where
I was going ... and that was for a very small Rails app, so I absolutely share
your thoughts there.

Upgrading from Rails 3 to 4, though, feels much easier as there haven't been
so many fundamental changes in the way Rails does things. And things that have
changed have usually been moved to gems that you can include to keep your app
working as it was before.

Fundamentally though ... Rails has an attitude that makes it pretty difficult
to adopt at big organizations precisely for the reasons that you've mentioned.
I'm yet to encounter a Rails version upgrade that wasn't a massive task , and
I can imagine having to deal with that as a startup whose life's blood
depended on it. (airbnb's experience on this is here
[http://nerds.airbnb.com/upgrading-airbnb-from-rails-23-to-
ra...](http://nerds.airbnb.com/upgrading-airbnb-from-rails-23-to-rails-30/),
and lots of companies don't have the resources or talent that they do). And
supporting older versions in the Rails community does get short shrift though
it is getting A LOT better these days.

However, I have to take issue with your assertion that

"I am also strongly convinced that Rails is never the right solution"

Which I feel comes from a place of frustration. I think the rewards of using
Rails ... developer happiness, productivity and ease of getting from idea to
software, make it worth it to put up with some of the warts that it has.
Things will only get better (and already are).

~~~
aaronem
More "fury" than "frustration", really. That may make it easier for you to
understand why your citing "developer happiness" as a reason to use Rails
elicits only a hollow laugh from me.

------
nmcfarl
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.

~~~
bdcravens
If every point release requires 10 hours of work, you need a new consultant.

For a minor version releases, some (less than 10) hours are probably
necessary.

For a major release, 10 hours may be necessary.

Of course, maybe your test suite needs reworking, which can be substantial. I
found that for a small 3.2.x app, upgrading to 4.0 was doable in 2-4 hours,
and I'm for the most part a Rails novice.

~~~
awj
That changes pretty drastically with application size and age. My project at
work is _at least_ eight years old and pretty damn huge. It uses a
considerable set of libraries, some of which are close to abandoned. Others
we've hacked up to the point that we're basically maintaining our own fork.

Version upgrades in that setup are not simple. Mostly because verifying
correctness here scales with the interaction of changed features, which tends
to grow much faster than pure application size.

~~~
bdcravens
Absolutely - I was really thinking about the scope of the application as
suggested by the parent post.

------
dylandrop
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.

~~~
stiff
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.

~~~
zpe
We've upgraded a similarly large project and for us the two following mistakes
caused the majority of headache:

1) Adapting libraries without regards to long term maintenance. I.e. single
person project that he/she does because a current client needs it, without
planning on having to take over stewardship of the library or fork it when the
person eventually abandons it.

2) Adapting libraries that hook into rails internal apis, without writing this
shortcut up as a debt that you might have to pay later when the private api
changes.

------
krisdol
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
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.)

------
decasia
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
>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
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
_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
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
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.

------
rartichoke
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.

