5 ms·

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 Rail

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