Adopting Big Rails Patterns: What Scale is Appropriate for a Small Team of 4 Engineers?

Message originally sent by slack user U71V6G2PDJS

I’m planning on doing just that. I’m pretty certain that it’s not a huge core and small satellites, but more evenly distributed. But we’ll see. Thanks for taking the time, much appreciated!

Message originally sent by slack user U717GMJTWHJ

If it’s more evenly distributed then I think it’ll probably end up being worth it.

Message originally sent by slack user U71V6G2PDJS

I will conclude that I’m not necessarily way off target investigating going down this route even if we are just a small app relatively.

Message originally sent by slack user U717GMJTWHJ

You’ll get a lot of data about dependencies and what actually relies on each other just by splitting them up and using the tools.

Message originally sent by slack user U71SC9J1VG6

I really like this as the rule of thumb:

If you have pretty clear dividing lines in the app between concerns, then breaking it up into packs could work with a small team if each engineer “owns” their domain and pretty much only works on that. Then you can each work not-in-isolation-but-at-least-one-directory.

I’ve seen this work well in teams with bigger teams with a huge Rails monolith. Their domains were “finance”, “recruiting”, “checkout”, etc… And they assigned one team per component/pack.

We’re still a small team, but we’re replacing an existing monolith that has grown into a big ball of mud, in our opinion, b/c of the lack of boundaries imposed by a modular monolith.

So, we’ve adopted this architectural style to prevent what we think is most likely going to happen in 6-12 mos of development on this new platform.

4 people x 12 mos can still write A LOT of code… and without subsystem boundaries, it can really turn into a mess. We’re not intending having each dev own a subsystem or any such thing anytime soon. We’re just trying to manage the inherent complexity in a system that 4 people can generate in 1 year.

Rails by itself falls far short of providing guidance / constraints, and even promotes anti-patterns!

We’re using modular monoliths to keep our system design intact.

4 months in… I love it.

Message originally sent by slack user U71V6G2PDJS

Thanks Gary, that’s really helpful. I’m not too concerned about ownership either. I’m more interested in providing guardrails to help guide developers when working in a certain area. I would prefer the whole team to have shared ownership of the entire codebase. But if we can make it easier to grasp individual parts of the application as well as reduce the coupling across that would be a big win.

Message excluded from import.

Message originally sent by slack user U71V6G2PDJS

While all that you say is true it has also been my experience from all my years of Rails work that I’ve never seen good modularity in a Rails application. I’ve seen various patterns such as service layers, but those don’t achieve modularity. Personally, I’ve been struggling with achieving or maintaining a good level of maintainability on all the apps I’ve been working on throughout my career and I’ve found very little that would help me in the resources coming out of the Rails community. It has also been a common occurrence that the teams I’ve been working on have not considered things to be as unmaintainable as I’ve found them. A lot of people are totally happy spending 3 months implementing something that could’ve been done in 3 weeks if it wasn’t for all of the self inflicted complexity of the applications they’re working in. At least that’s the impression I’ve gotten.

Message originally sent by slack user U71V6G2PDJS

I’m wondering if Rails (or the way it’s commonly used) leads you away from modularity. The Rails Way seems to be that every ActiveRecord should be associated with every other ActiveRecord model through some chain of intermediaries.

Message excluded from import.

Message originally sent by slack user U71V6G2PDJS

<@U78EF4XFY8W> Thank you so much for your insights. It’s immensely valuable to me.

Message excluded from import.

Message originally sent by slack user U71V6G2PDJS

Thanks, Scott. I’m lucky to have good management support currently, so I’m pretty encouraged at the moment. If it was an invitation I’d love to join the call if nothing else just to hear what problems others are experiencing.

Message excluded from import.

Message excluded from import.