Hacker News new | ask | show | jobs
by horsawlarway 667 days ago
I mean... This is basically exactly what Microsoft tried.

Template out your app, create the pieces through wizards, reduce developer need to interact with the underlying tech and make complicated choices in favor of best practice defaults.

It was... mostly horrible (and I think this pain is where RoR is right now). The problem is that templates go stale awfully fast, tech changes, best practices change, good defaults change.

Keeping a coherent codebase where the developers don't have an understanding of the choices that have been made is recipe for disaster. It always ends up mattering, because often best practices depend on top level objectives and aren't objectively correct, but rather trade-offs.

RoR does what the author needs - it quickly bootstraps a tech company. The trade-off is that it sucks so hard in year 5.

You get an easy start and a miserable middle. That's probably a trade most startups should make, but as a person who has to inherit that junk... Wow is it painful.

1 comments

I have worked with 3 companies that had more than 5 years of Rails and I never had the pain people say it here. It continues to be easy to add features, grow the codebase and understand what is happening.

I wonder how people don't understand the codebases they inherit to be honest.

If the team stays small - rails stays ok.

I've twice now worked for companies that have experienced very dramatic growth. In both of those cases, rails became a huge liability.

Case 1 - I was hire 7, we grew to ~350 engineers in 5 years.

Case 2 - I was hire 50, we grew to ~700 engineers in 5 years.

I'm not saying you can't also mess up that growth without Rails (trust, me - it's very challenging to grow at that speed and retain your sanity) but Rails makes it basically impossible.

And as a counter - if you're small and stay small, basically any tech stack will work just fine, Rails is fine and so are most of the rest.

Essentially - Rails heavily prioritizes single developer productivity at the expense of multi-team productivity.