3 ms·
> you have to make a bet on what engineers will want to use in three years. That’s more important than what framework lets you be most productive right now. I
by jph 11y ago
> you have to make a bet on what engineers will want to use in three years. That’s more important than what framework lets you be most productive right now.
I advocate the exact opposite view: use what enables your team to be most productive right now. The popularity of frameworks may change three years down the line, and good engineers will be fine with that.
- kbar13 11y agoagreed. why optimize for the future when that optimization may directly block/slow your trajectory?
- LoSboccacc 11y agoBecause you have to maintain the app against known vulnerabilities. And in even a single year previous version of out app had multiple gems with vulnerabilities having to do a major version upgrade and I had to scrap the whole thing because older gems with fixes where unavailable or didn't build on modern rail/os The whole ecosystem is frankly a mess, you need to stay bleeding edge all the time to have a chance to long term maintenance and suffer any capricious api update each of your dependency might have because staying on old release and relying on backports is not worth it. I'm not paid to clean other people libraries. If the idea of open source is that, then no thanks. Core business is not maintenance and costs like those do kill startups.
- scott_karana 11y agoIf all your old gems had vulnerabilities, what makes you think bleeding edge ones didn't? Spoiler: the difference is, the new ones' bugs just aren't widely known yet.
- mszyndel 11y ago> you need to stay bleeding edge all the time to have a chance to long term maintenance yeah, github is a perfect example or that, right? </irony>
- deedubaya 11y agoThose aren't rails specific issues. If you want to run on old software that you don't have to upgrade or maintain, you are going to pay for someone else to do it. If you want your cake and to eat it too, you're unrealistic.
- LastZactionHero 11y agoYeah, I'm not sure what kind of new company is willing so sacrifice productivity up front on a bet that future developers might not be excited about their codebase. "Yeah, we're going to be another 2 months to launch because we're betting developers in 2018 prefer Go." I'll be pretty surprised if you're still in business in three years.
- zazpowered 11y agoI was about to say this. It makes no sense to worry about things that far down the line