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

This message was imported from the Ruby/Rails Modularity Slack server. Find more info in the import thread.

Message originally sent by slack user U71V6G2PDJS

At what scale would you consider adopting Big Rails patterns? For context, I’m working with a small team (4 engs) working on a Rails app that feels like it’s gotten too big for comfort. So we’re considering how to get the complexity under control.

Message originally sent by slack user U717GMJTWHJ

I think the tipping point is where managing the current complexity is worse than the overhead of managing packs and dependencies… but maybe you could prepare by add documentation, measuring test coverage, etc. My hunch is that introducing packs will make things more complex in the short term.

Message originally sent by slack user U717GMJTWHJ

I’d maybe start by documenting where the discomfort is coming from - is it finding things, understanding them, troubleshooting, something else?

Message originally sent by slack user U71V6G2PDJS

Understanding the system is definitely an issue. And I would think accidental complexity introduced by what would probably be different packages reaching into the internals of eachother.

Message originally sent by slack user U71V6G2PDJS

It’s hard to quantify, but it just feels too big. Mentally taxing to work with.

Message originally sent by slack user U71V6G2PDJS

Which in turn leads to a slower pace of development.

Message originally sent by slack user U717GMJTWHJ

You’ll have that problem at the beginning anyway - it’s part of the process. 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.

Message originally sent by slack user U71V6G2PDJS

And I guess what Rich Hickey would call complected

Message originally sent by slack user U717GMJTWHJ

Over time, you can figure out the patterns between packs and agree on an API, but that’s also a good bit of overhead for a small team.

Message originally sent by slack user U717GMJTWHJ

The thing I like most about packs is that each one can have their own README, which makes it easier to know what’s in it (not that all of our packs have them, they don’t, but they should).

Message originally sent by slack user U71V6G2PDJS

How big are the packs (# of files / LOC / whatnot) that you’re seeing?

Message originally sent by slack user U717GMJTWHJ

They’re all over the place.

Message originally sent by slack user U71V6G2PDJS

We currently have ~150 files with ~7500LOC in app/models which feels like a lot

Message originally sent by slack user U717GMJTWHJ

That’s a reasonably sized pack at Gusto.

Message originally sent by slack user U717GMJTWHJ

(ok, not all those models, maybe 3 packs)

Message originally sent by slack user U717GMJTWHJ

How many different domains would you say those models represent?

Message originally sent by slack user U71V6G2PDJS

I guess I’m growing old, my tolerance for that much code is growing slim :smile:

Message originally sent by slack user U71V6G2PDJS

I’m not sure. My gut feeling is that there is a lot of domains (10+) in there.

Message originally sent by slack user U71V6G2PDJS

But perhaps it can be distilled to maybe a handful

Message originally sent by slack user U717GMJTWHJ

I’d sketch it out with the team - come up with a whiteboard drawing of your domains and some good guesses on their relative sizes. If the team feels that would make it easier to handle, then go for it. You might find you a single huge pack and a bunch of little “satellites” so it doesn’t actually make sense to break up since you still have to understand the huge on for the satellites to make sense.