3 ms·

It can go both ways. At work, I periodically get in contact with an extremely large codebase that is actively worked on by multiple teams. One complaint I heard

by lhorie 5y ago

It can go both ways. At work, I periodically get in contact with an extremely large codebase that is actively worked on by multiple teams. One complaint I heard was that people doing willy-nilly things cause setbacks to efforts to make project-wide improvements. One example was that build times were very slow and there was an effort to implement incremental builds along some interface boundaries, but then teams would disrespect agreements to not violate constraints for that boundary (because immediate deadlines trump long term large efforts) A more accurate way of thinking about it, IMHO, is to look at how homogeneous the project is. A project can be very very large, but be entirely CRUD forms, and Rails could fit like a glove. But on the other hand, a project could have predominantly "curveball" features (maybe it simultaneously has a real time chat component, twilio integration, newsletter emails, periodic 3rd party data imports, print-to-pdf, etc).

mastazi 5y ago
> A more accurate way of thinking about it, IMHO, is to look at how homogeneous the project is. This is a very good point. I tend to take as a given the a highly homogeneous project is always a smaller/simpler one, and that a heterogenous one is always a large project with a large team... but thinking about it, this is not true at all, in fact I can think about some very large projects that don't do many different things, and I can think about some smaller projects I've worked on that are a bit of a Swiss Army knife.
midrus 5y ago
> real time chat component, twilio integration, newsletter emails, periodic 3rd party data imports, print-to-pdf, etc). All of these things are pretty easy to do with Rails and Laravel. I don't see how Flask or express or the home made framework on top of those could make anything of this easier. Other than writing the code yourself and not needing to read documentation (which will be a problem for future maintainers) I don't see any advantage for anyone except the one writing it for the fun of it.

by lhorie 5y ago

mastazi 5y ago

> A more accurate way of thinking about it, IMHO, is to look at how homogeneous the project is. This is a very good point. I tend to take as a given the a highly homogeneous project is always a smaller/simpler one, and that a heterogenous one is always a large project with a large team... but thinking about it, this is not true at all, in fact I can think about some very large projects that don't do many different things, and I can think about some smaller projects I've worked on that are a bit of a Swiss Army knife.

midrus 5y ago

> real time chat component, twilio integration, newsletter emails, periodic 3rd party data imports, print-to-pdf, etc). All of these things are pretty easy to do with Rails and Laravel. I don't see how Flask or express or the home made framework on top of those could make anything of this easier. Other than writing the code yourself and not needing to read documentation (which will be a problem for future maintainers) I don't see any advantage for anyone except the one writing it for the fun of it.