The Costs of Keeping Your Rails App Up to Date, Or Not(samuelmullen.com)
samuelmullen.com
The Costs of Keeping Your Rails App Up to Date, Or Not
http://www.samuelmullen.com/2014/01/the-costs-of-keeping-your-rails-app-up-to-date-dot-dot-dot-or-not/
8 comments
Deployment of rails used to be pretty awful (around the time Zed linked by aaronem raged in the ghetto), but for the last few years it's been painless, at least if you use passenger. Deploy is now straightforward, and upgrading Apache/Ruby has not been a problem.
I've upgraded a few apps from 1.x to 4.2 without issues, and with minimal changes (2->3 was the big one, changes were for new features like the pipeline, and bundler), and have some still on 3.x because features took priority over upgrades - the experience has mostly been as you describe for me - you upgrade the framework, and everything in your app just works, modulo a few tweaks for upgrading gems that I use like devise.
There have certainly been glitches for some people though, and regressions, and it's probably on the more experimental end of the frameworks spectrum.
I've upgraded a few apps from 1.x to 4.2 without issues, and with minimal changes (2->3 was the big one, changes were for new features like the pipeline, and bundler), and have some still on 3.x because features took priority over upgrades - the experience has mostly been as you describe for me - you upgrade the framework, and everything in your app just works, modulo a few tweaks for upgrading gems that I use like devise.
There have certainly been glitches for some people though, and regressions, and it's probably on the more experimental end of the frameworks spectrum.
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.
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.
It sounds like they've gone for "easy to develop" rather than "easy to maintain" but any app in the real world will spend 10-100x longer in maintenance mode than active development.
Or more cynically, they are optimizing for billable hours, but only once the customer is locked in, having being beguiled by the low costs up front.
Or more cynically, they are optimizing for billable hours, but only once the customer is locked in, having being beguiled by the low costs up front.
Exactly.
The emerging perpetual Rails re-factoring cycle is very Microsoft-esq in some ways -- the second you buy in, you'll keep buying if you keep using the software.
To be fair, this is not a problem just in Rails. I see similar issues in the emerging JS world too, where everyone is re-inventing libraries for JS that have existed already for decades in other languages, only with new authors. Reminds me of F. Scott Fitzgerald's Gatsby quote a little sometimes. :)
The strangest thing is after working in several worlds, I'm slowly finding myself looking to the JVM, and wondering if I'm crazy to be considering the Java world (albeit in the form of the JVM) that I was happy to run from after University. Jython, JRuby, Querus under one roof is a strange experience, I'm sitting on a foundation of some of the most performant, scaling libraries in Java.
The emerging perpetual Rails re-factoring cycle is very Microsoft-esq in some ways -- the second you buy in, you'll keep buying if you keep using the software.
To be fair, this is not a problem just in Rails. I see similar issues in the emerging JS world too, where everyone is re-inventing libraries for JS that have existed already for decades in other languages, only with new authors. Reminds me of F. Scott Fitzgerald's Gatsby quote a little sometimes. :)
The strangest thing is after working in several worlds, I'm slowly finding myself looking to the JVM, and wondering if I'm crazy to be considering the Java world (albeit in the form of the JVM) that I was happy to run from after University. Jython, JRuby, Querus under one roof is a strange experience, I'm sitting on a foundation of some of the most performant, scaling libraries in Java.
What's that Gatsby quote if you don't mind?
"So we beat on, boats against the current, borne back ceaselessly into the past."
http://www.sparknotes.com/lit/gatsby/quotes.html
http://www.sparknotes.com/lit/gatsby/quotes.html
Thanks. Nice.
Java deployment is one of the most fragmented and ghetto-like you will ever experience.
If you can always upgrade your platform without modifying your code, you have written a very narrow application with only basic structures and no libraries.
If you can always upgrade your platform without modifying your code, you have written a very narrow application with only basic structures and no libraries.
Rails is not a language, neither a "black box" application.
Rails is a framework.
Also, Rails isn't trying very hard to be backwards compatible, either (which I never found to be a problem).
Rails is a framework.
Also, Rails isn't trying very hard to be backwards compatible, either (which I never found to be a problem).
Not caring about being backwards compatible is perfectly fine choice.
Not caring about having reliable guides for updating between versions (which include keeping information around for upgrade between outdated versions. These needed be updated, but they should still be possible to find for people that use old versions) is less ok. The situation tend to be decent if one upgrades between current versions, but that information needs to be kept, which isn't the case today. It is fine not to update them, but they still must be possible to find.
Not caring about having reliable guides for updating between versions (which include keeping information around for upgrade between outdated versions. These needed be updated, but they should still be possible to find for people that use old versions) is less ok. The situation tend to be decent if one upgrades between current versions, but that information needs to be kept, which isn't the case today. It is fine not to update them, but they still must be possible to find.
Differentiating Rails as a framework and not a language is helpful when people compare framework to a language and say that language is inadequate. I'm not sure if that's why you're clarifying this?
Frameworks tend to extend languages to the web/internet, because none of them handle the web very well. I only know of a few languages specifically, and written for the web/internet first.
Frameworks tend to extend languages to the web/internet, because none of them handle the web very well. I only know of a few languages specifically, and written for the web/internet first.
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
[2] http://harmful.cat-v.org/software/ruby/rails/is-a-ghetto
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
[2] http://harmful.cat-v.org/software/ruby/rails/is-a-ghetto
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..., 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).
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..., 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).
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.
I always found that a strange rant from Zed, equal parts bluster, spot on observation (consultancy firms) and bullying and bitching about personal little squabbles he's had with various people (that seems to happen to Zed a lot). It's not particularly relevant nowadays about deployment of rails apps - that's pretty straightforward now. It is amusing in retrospect that he is talking up other frameworks like merb - merb is what became Rails 3, which is what you're complaining about migrating to, and the creator now works on Rails as part of the evil™ core team:
The best part about the whole thing is there’s potentially 10 new web frameworks that can take on Rails. Hell, Mongrel spawned or helped 5 of those. My favorite of those frameworks is Merb which is literally “Mongrel plus Erb”
Also, I'm not sure that the best test case for the ease of rails upgrades is embarking on a major migration of an app you don't know well, written in a previous version of a framework you don't know well. I've been put off frameworks by bad apps before too so I know the feeling - is it possible that your experience is related partly to this app, not just to Rails? Many others have not experienced anything like this level of pain with Rails upgrades. I updated a terrible drupal site once - let's just say that I'll never touch drupal again, but that is not necc. justified, it runs a lot of sites without drama and can probably be used to make good apps in the right hands.
Certainly if you are familiar with the app and gems used minor upgrades are exactly as described above - upgrade, test, deploy, sometimes with no changes. That's not to say there are no problems, but I think you're extending your horrible experience unjustifiably to encompass all possible uses of Rails. I find it not bad as frameworks go, better than many others I've seen internally, particularly > v3, and plenty of other people other than Rails developers use and enjoy Rails, without any resulting disasters, why the hyperbole?
The best part about the whole thing is there’s potentially 10 new web frameworks that can take on Rails. Hell, Mongrel spawned or helped 5 of those. My favorite of those frameworks is Merb which is literally “Mongrel plus Erb”
Also, I'm not sure that the best test case for the ease of rails upgrades is embarking on a major migration of an app you don't know well, written in a previous version of a framework you don't know well. I've been put off frameworks by bad apps before too so I know the feeling - is it possible that your experience is related partly to this app, not just to Rails? Many others have not experienced anything like this level of pain with Rails upgrades. I updated a terrible drupal site once - let's just say that I'll never touch drupal again, but that is not necc. justified, it runs a lot of sites without drama and can probably be used to make good apps in the right hands.
Certainly if you are familiar with the app and gems used minor upgrades are exactly as described above - upgrade, test, deploy, sometimes with no changes. That's not to say there are no problems, but I think you're extending your horrible experience unjustifiably to encompass all possible uses of Rails. I find it not bad as frameworks go, better than many others I've seen internally, particularly > v3, and plenty of other people other than Rails developers use and enjoy Rails, without any resulting disasters, why the hyperbole?
"no one in the Rails community has the slightest interest in yesterday"
I think this is pretty disrespectful. The deprecation warnings and online documentation didn't magically appear.
For example this section "upgrading to 3.2" from the official docs: http://guides.rubyonrails.org/3_2_release_notes.html#upgradi...
I'm personally very thankful for all of the hard work the community has done to help us upgrade.
If you have found pieces of the upgrading puzzle that are missing, then please consider contributing back. 2.3 > 3 is the hardest one. It gets a lot easier.
I'm personally very thankful for all of the hard work the community has done to help us upgrade.
If you have found pieces of the upgrading puzzle that are missing, then please consider contributing back. 2.3 > 3 is the hardest one. It gets a lot easier.
That's not much of an example; to say that it barely scratches the surface, in all its seven-paragraph glory, is to be if anything excessively kind. This is unfortunately typical of the Rails community's attitude toward these matters; you may safely assume that, were there anything remotely resembling sufficient documentation available, I would not feel the need to utter complaints such as those above -- if I have anywhere given the erroneous impression that I enjoy hacking my way through this horrible triple-canopy jungle, without so much as a sketch map, please allow me at this juncture to disabuse you of the notion!
I have no knowledge as to what you think of triple canapés, but I do get a strong feeling of entitlement from you. You also seem to disregard a whole bunch of people(like me for example) that didn't experience as much pain as you. As well as the people that have dedicated their time to write deprecation warnings and documentation, recording videos etc..
Worst case, your app is exceptionally hard to upgrade and I feel for your effort.
Worst case, your app is exceptionally hard to upgrade and I feel for your effort.
> 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.
In what way was McAnally's book insufficient?
http://www.railsupgradehandbook.com/
> 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.
PHP is a language and Rails is a framework. Compare upgrading PHP to upgrading Ruby. The latter is painless.
It seems like you should stick with PHP.
In what way was McAnally's book insufficient?
http://www.railsupgradehandbook.com/
> 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.
PHP is a language and Rails is a framework. Compare upgrading PHP to upgrading Ruby. The latter is painless.
It seems like you should stick with PHP.
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.
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.
Welcome to the internet - any public internet-facing service needs to be regularly updated, as all of them (apache, openssh, .net, rails, php, java apps, off the shelf things like wordpress) have multiple exploits discovered regularly, and bots randomly try urls at servers to try to take over the machine. That's not a very pleasant experience and often isn't clear to the client/users, but that's the cost of being on the internet.
No matter which framework or application you are talking about (including Word as it happens, if anyone mails you docs), you're running a risk if you run software which is old. On the desktop you'll mostly get away with this, but when it is exposed to the internet directly, the timeframe before someone tries to exploit you is probably measured in minutes, not years. You can still easily lose data/time/money by using out of date desktop software like XP, Acrobat or Word though.
I agree the article doesn't give a good clear explanation of costs and benefits, and is mixing up two things - regular upgrades to software for security, and upgrades to software for other reasons (like additional features or making the dev's life easier). Often in bigger companies these jobs are split, but in smaller companies you might pay your developer to be sysops, developer, backup specialist and all-round computer person, so they tend to do both (and mix up both in quotes). Whatever tech you choose to use, you'll find you incur similar costs for maintenance (in my experience at least), though perhaps not these costs. It mixes up too many concepts (security, features, maintenance), which is a bit confusing and I could see being frustrating as a business owner who wants to pay for new features, not pay for keeping old ones. Unfortunately running software on the internet comes with a maintenance cost, which should be explained to clients up front as a separate cost from development, because the reasons for doing it (security) are mostly separate, and it's more like maintaining your server than website/app development (it should also include updating your web server software for example).
No matter which framework or application you are talking about (including Word as it happens, if anyone mails you docs), you're running a risk if you run software which is old. On the desktop you'll mostly get away with this, but when it is exposed to the internet directly, the timeframe before someone tries to exploit you is probably measured in minutes, not years. You can still easily lose data/time/money by using out of date desktop software like XP, Acrobat or Word though.
I agree the article doesn't give a good clear explanation of costs and benefits, and is mixing up two things - regular upgrades to software for security, and upgrades to software for other reasons (like additional features or making the dev's life easier). Often in bigger companies these jobs are split, but in smaller companies you might pay your developer to be sysops, developer, backup specialist and all-round computer person, so they tend to do both (and mix up both in quotes). Whatever tech you choose to use, you'll find you incur similar costs for maintenance (in my experience at least), though perhaps not these costs. It mixes up too many concepts (security, features, maintenance), which is a bit confusing and I could see being frustrating as a business owner who wants to pay for new features, not pay for keeping old ones. Unfortunately running software on the internet comes with a maintenance cost, which should be explained to clients up front as a separate cost from development, because the reasons for doing it (security) are mostly separate, and it's more like maintaining your server than website/app development (it should also include updating your web server software for example).
It's one thing to update your infrastructure and libraries.
It's another to have to substantially rewrite everything in the process of doing so.
There are enough problems with existing tools which do emphasize backwards compatibility, but intentionally breaking stuff ... is evil. This builds up technical debt extremely quickly.
It's one thing to write.
It's quite another to maintain, rewrite, and retain compatibility with existing apps and infrastructure.
It's another to have to substantially rewrite everything in the process of doing so.
There are enough problems with existing tools which do emphasize backwards compatibility, but intentionally breaking stuff ... is evil. This builds up technical debt extremely quickly.
It's one thing to write.
It's quite another to maintain, rewrite, and retain compatibility with existing apps and infrastructure.
It's one thing to update your infrastructure and libraries. It's another to have to substantially rewrite everything in the process of doing so.
I wouldn't know about this; I've never had to do it, with Rails sites at least. If that's a description of an upgrade of Rails apps, I think it is overblown frankly, unless it involves new developers coming in blind to an app and trying to update - in that situation, whatever the framework, there is going to be pain - the pain of not knowing the app or dependencies added to any upgrade glitches can lead to a lot of trouble.
I do think the article made a mistake in mixing up security/infrastructure updates with framework and app updates. It comes off as vague, wooly and somewhat deceptive to the client.
It's quite another to maintain, rewrite, and retain compatibility with existing apps and infrastructure.
Done a fair bit of this (though less of the rewriting). Frankly, Rails is much like any other framework in this respect - things mostly change gradually, and they make a good effort at backwards compatibility, but it's not always perfect; it's not much worse than other frameworks, though I'm sure some others do a better job (with other tradeoffs). The move from 2-3 was the biggest, but even that wasn't particularly troubling for me - it could be harder with very large, complex apps, but those apps usually have a team looking after them and money to spend on upgrades/maintenance.
The worst place to be in is coming in to a new app which is broken and out of date, or just badly structured, and trying to fix it - this pain occurs in any language that I'm familiar with, and I suspect that's the reason for a lot of rewriting. I have been guilty of this once or twice myself on other platforms, but sometimes (rarely) it is the right choice.
I wouldn't know about this; I've never had to do it, with Rails sites at least. If that's a description of an upgrade of Rails apps, I think it is overblown frankly, unless it involves new developers coming in blind to an app and trying to update - in that situation, whatever the framework, there is going to be pain - the pain of not knowing the app or dependencies added to any upgrade glitches can lead to a lot of trouble.
I do think the article made a mistake in mixing up security/infrastructure updates with framework and app updates. It comes off as vague, wooly and somewhat deceptive to the client.
It's quite another to maintain, rewrite, and retain compatibility with existing apps and infrastructure.
Done a fair bit of this (though less of the rewriting). Frankly, Rails is much like any other framework in this respect - things mostly change gradually, and they make a good effort at backwards compatibility, but it's not always perfect; it's not much worse than other frameworks, though I'm sure some others do a better job (with other tradeoffs). The move from 2-3 was the biggest, but even that wasn't particularly troubling for me - it could be harder with very large, complex apps, but those apps usually have a team looking after them and money to spend on upgrades/maintenance.
The worst place to be in is coming in to a new app which is broken and out of date, or just badly structured, and trying to fix it - this pain occurs in any language that I'm familiar with, and I suspect that's the reason for a lot of rewriting. I have been guilty of this once or twice myself on other platforms, but sometimes (rarely) it is the right choice.
> My we might be using a four-year-old copy of Photoshop, or Word.
> my Rails consultant tells me that after he builds my 3 user internal accounting app
I feel this is an unfair comparison between desktop software and a web app. Web apps can be quicker & less expensive to deliver, which is probably why you, as a business owner, like the idea of building the app in Rails.
Hiring an Objective-C developer to deliver a full-blown desktop app would cost more initially. (Photoshop and Word have huge development teams.) It would probably also require less maintenance going forward. (Photoshop and Word last for years, as you mentioned.)
> With no improvements at all.
We offer similar on-going maintenance contracts at my Rails consultancy. But we're offering a specific number of days (2/month, usually.) If we're able to upgrade in 3 hours, then we'll spend the rest of the time working through a feature backlog or optimizing performance.
Perhaps your consultant would be open to a similar arrangement?
> Or where I can find a consultant who actually weigh the costs and benefits to me.
If I may, I think you hit the nail on the head with your last sentence. Maybe your frustration isn't so much with Rails as it is with not having the analysis you need to make appropriate business decisions. Unfortunately, in my experience, those communication skills are far more rare than developers are.
> my Rails consultant tells me that after he builds my 3 user internal accounting app
I feel this is an unfair comparison between desktop software and a web app. Web apps can be quicker & less expensive to deliver, which is probably why you, as a business owner, like the idea of building the app in Rails.
Hiring an Objective-C developer to deliver a full-blown desktop app would cost more initially. (Photoshop and Word have huge development teams.) It would probably also require less maintenance going forward. (Photoshop and Word last for years, as you mentioned.)
> With no improvements at all.
We offer similar on-going maintenance contracts at my Rails consultancy. But we're offering a specific number of days (2/month, usually.) If we're able to upgrade in 3 hours, then we'll spend the rest of the time working through a feature backlog or optimizing performance.
Perhaps your consultant would be open to a similar arrangement?
> Or where I can find a consultant who actually weigh the costs and benefits to me.
If I may, I think you hit the nail on the head with your last sentence. Maybe your frustration isn't so much with Rails as it is with not having the analysis you need to make appropriate business decisions. Unfortunately, in my experience, those communication skills are far more rare than developers are.
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?
* 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?
I have an issue with your point #2: how does the app end-users ends up with new features when bumping a minor version of the framework behind the app ?
Aren't the end-users of Rails the developers and not the end users of the app ?
Aren't the end-users of Rails the developers and not the end users of the app ?
Best example I have is that Rails 3.0 -> 3.1 included the asset pipeline, which enabled some pretty nice speed improvements by making better use of the browser's caching system and minimizing the number of file downloads required for css/javascript.
That said, yeah, that is why I was wishy-washy on that suggestion. The payoff in minor version upgrades is keeping on top of upcoming deprecations, which minimizes future upgrade costs.
> Aren't the end-users of Rails the developers and not the end users of the app ?
Developers don't work in a vacuum. Many "developer niceties" of Rails translate into reduced end-user costs due to faster time to execute change requests. This is an important thing, but it's also hard for both sides of the transaction to quantify.
That said, yeah, that is why I was wishy-washy on that suggestion. The payoff in minor version upgrades is keeping on top of upcoming deprecations, which minimizes future upgrade costs.
> Aren't the end-users of Rails the developers and not the end users of the app ?
Developers don't work in a vacuum. Many "developer niceties" of Rails translate into reduced end-user costs due to faster time to execute change requests. This is an important thing, but it's also hard for both sides of the transaction to quantify.
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.
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.
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.
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.
Absolutely - I was really thinking about the scope of the application as suggested by the parent post.
> For a major release, 10 hours may be necessary. [...] I'm for the most part a Rails novice.
It's interesting that a Rails novice can state confidently that upgrading between major releases of Rails requires up to 10 hours of work, regardless of the size of the app.
It's interesting that a Rails novice can state confidently that upgrading between major releases of Rails requires up to 10 hours of work, regardless of the size of the app.
I'm not a web application novice (been building web apps since 1998, writing production code in about a half dozen languages or so), and I've done a few version upgrades in the year or so I've been working with Rails on and off. I don't think my estimate is too far off, but obviously there's an asterisk in there.
I call myself a novice since I feel it's better to err on the side of caution.
Also read my comment in context. I was responding to a specific comment where the app size was pretty well implied.
Also when I said "2-4 was doable" I wasn't being philosophical; I was stating how long it took (I didn't say an app of any size, but a small app) (obviously my choice of words was poor to express meaning, but that's pretty par for the course for my HN posts)
I call myself a novice since I feel it's better to err on the side of caution.
Also read my comment in context. I was responding to a specific comment where the app size was pretty well implied.
Also when I said "2-4 was doable" I wasn't being philosophical; I was stating how long it took (I didn't say an app of any size, but a small app) (obviously my choice of words was poor to express meaning, but that's pretty par for the course for my HN posts)
That's not a logical conclusion, and has no relation to technology choice.
What you're complaining about is the cost of maintaining custom-built software. You'd have costs if you built that app in Java, or Python, or Node.js, or on whatever other platform.
You could look at the relative maintenance costs of each platform, and make a comparison based on that, which might be somewhat more enlightening. But ultimately, if you build bespoke software and want to maintain security, then you'll have to invest in maintenance. Either you do that progressively (quick upgrades on point releases) or you do it as required (most extensive and expensive upgrades when security vulnerabilities are discovered.) But there's no absolute here.
What you're complaining about is the cost of maintaining custom-built software. You'd have costs if you built that app in Java, or Python, or Node.js, or on whatever other platform.
You could look at the relative maintenance costs of each platform, and make a comparison based on that, which might be somewhat more enlightening. But ultimately, if you build bespoke software and want to maintain security, then you'll have to invest in maintenance. Either you do that progressively (quick upgrades on point releases) or you do it as required (most extensive and expensive upgrades when security vulnerabilities are discovered.) But there's no absolute here.
Custom application development has maintenance costs associated with it. You can ignore those but it's at your own peril, nothing is stopping your from having an unsecured public web server running on your systems, it's just a bad idea. Just like nothing prevents you from not updating Windows and having your laptop become part of a bot-net.
If you can't afford that cost it would be ill advised to use custom software application (or take a different approach to it that doesn't involve exposing a web server to the internet). Either way comparing Photoshop/Word updates to updating a custom application running on a *nix server exposed to the world is just absurd.
And yes you're right, custom application development should probably be avoided wherever possible. Especially if you don't expect the ROI to exceed ongoing expenses.
If you can't afford that cost it would be ill advised to use custom software application (or take a different approach to it that doesn't involve exposing a web server to the internet). Either way comparing Photoshop/Word updates to updating a custom application running on a *nix server exposed to the world is just absurd.
And yes you're right, custom application development should probably be avoided wherever possible. Especially if you don't expect the ROI to exceed ongoing expenses.
As a business owner & pre 1.0 Rails adopter, I completely agree.
It's never been the goal of Rails to support programmers who need long, conservative development cycles. Improvements get that much harder that much more quickly.
Having said that the 2.3 series is fully baked now, and there is some commercial support out there. Are there software contractors out there who 1) like Rails, 2) sell their services on a long-term basis based on 2.3? Doesn't seem very likely.
It's never been the goal of Rails to support programmers who need long, conservative development cycles. Improvements get that much harder that much more quickly.
Having said that the 2.3 series is fully baked now, and there is some commercial support out there. Are there software contractors out there who 1) like Rails, 2) sell their services on a long-term basis based on 2.3? Doesn't seem very likely.
>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).
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).
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.
The number of users isn't a good indication, necessarily, of the complexity of the application required, the time to create it, or the time to maintain it once it's deployed. As with all things related to his business, a business owner such as yourself has many factors to consider and weigh against one another.
Were I a consultant bidding for your business, and during our meeting(s) you expressed the above concern, all other things being equal I'd conclude your use-case and budget constraints don't mesh well with a custom software solution. I'd probably politely suggest that you would be better served with an off-the-shelf solution (either a packaged goods/downloadable item or a SaaS firm with a very small menu of fixed-version solutions). Then I would politely decline continuing with the meeting and wish you well.
Were I a consultant bidding for your business, and during our meeting(s) you expressed the above concern, all other things being equal I'd conclude your use-case and budget constraints don't mesh well with a custom software solution. I'd probably politely suggest that you would be better served with an off-the-shelf solution (either a packaged goods/downloadable item or a SaaS firm with a very small menu of fixed-version solutions). Then I would politely decline continuing with the meeting and wish you well.
> I'll go look for technology where every point release doesn't require $1500 worth of work.
This does not exist.
This does not exist.
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.
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.
Painless? ruby 1.8.7/rails 3.0 -> ruby 1.9/rails3.2 took a LOT of time and more than 100 commits.
Not to mention the time spent repacking an infinite amount of dependencies, but that is more of an issue of our packaging model (we put everything in rpms) than of rails.
Not to mention the time spent repacking an infinite amount of dependencies, but that is more of an issue of our packaging model (we put everything in rpms) than of rails.
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.
That being said, upgrading from Rails 2 -> 3 was pretty annoying.
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.
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.
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.
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.
NB, I said: "If you're >= Rails 3, almost all upgrades are painless. "
I was talking about upgrades past Rails 2 -> 3. That was probably the biggest one in Rails history, but even that was a problem you should have only encountered almost 3 years ago by now. 3 -> 4 is not nearly as crazy.
Recently one of the more senior devs at a place I worked at coverted a 50k line codebase from 3 -> 4 in one day. Not bad.
I was talking about upgrades past Rails 2 -> 3. That was probably the biggest one in Rails history, but even that was a problem you should have only encountered almost 3 years ago by now. 3 -> 4 is not nearly as crazy.
Recently one of the more senior devs at a place I worked at coverted a 50k line codebase from 3 -> 4 in one day. Not bad.
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.
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.)
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...
>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.
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.
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.
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.
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.
Most decent developers will want the opportunity to work on the latest version. Certainly keeping reasonably current is much lower risk than not upgrading.
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.
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.
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.
[deleted]
So why is everything in Rails so much work? There are entire books written on "deployment". No other language has this.