3 ms·

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 th

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

dredmorbius 13y ago
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.
- grey-area 13y ago
  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.

dredmorbius 13y ago

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.

grey-area 13y ago
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.