Service Objects Are Totally Fine Actually
The Ruby community used to have this fairly strong idiom back in the day: Keep Ruby Weird. Nowadays it seems more like just a conference that happens every so often.
We had folks like “Why The Lucky Stiff”, who’d write these incredibly baroque programs that’d interesting things, really leaning into the intricacies and strange features the Ruby language provided, and sometimes really bending what was possible.
It was extremely cool. It felt fresh. It felt vibrant. People were trying things. Anything was possible.
Now, in 2025, to me it feels like what passes the ‘Ruby community’ has become this puritanical, finger wagging, 37Signals sycophantic clique.
For five years or so now, there’s a regular drumbeat of people wagging their fingers and writing blog posts and tweets about how ‘Service Objects’ are bad, m’kay? I’m not even going to address the merit of these arguments, because they are silly and specious.
Anyone can construct a strawman of something that people don’t actually do, and say “Well look, this is obviously bad.” It does nothing for the community. Worse I think it’s puritanical and patriarchal - and I’m choosing those terms very carefully because I think they speak to what I think the root cause of this mindset is.
It shouldn’t belong in the Ruby community, but I think we’re well past that now.
But let me paint at least some kind of rebuttal to the ‘Service Objects Bad’ stance.
I was first introduced to the idea by an article that my friend james Golick wrote in 2010 - Crazy, Heretical and Awesome: The Way I Write Rails Apps - you should read it.
Notice he said: “The way I write apps.” Not “You should write your Rails app this way”. We used to be a community that was happy to share knowledge, not finger wag and tut tut.
In the article he strongly details his personal philosophical driver is separation of concerns and testability, particularly because back in those days, Rails testing Rails controllers was slow as shit.
Also note, he is not just hiding a variable in a class that could have been a method, as the ‘No service objects’ rabble would have you believe this is the only use for this pattern. Again, read the article.
You can dice this argument up any way you want. It really doesn’t matter. It shouldn’t matter. It’s baffling to me why these ‘No Service Objects’ guys give a single flying shit about how someone else is writing their code? Maybe someone can explain it to me?
In my case I use this pattern because it gives me clean, testable, and re-usable units of logic I take with me to many new projects. Maybe that’s one of the differences, the ‘No Service Object’ guys only ever work on one codebase? And are happy with the total spaghetti shit show that comes with Callbacks.
To close, if you’re reading this and thinking “I need to write an article about how this guy is wrong and shouldn’t use service objects”, I’m asking you to just not do that. No one is going to read your thing and think you’re now a thought-leader bro.
Just let people write their code the way they want to and stop trying to impose some religious doctrine on how everyone else should program.
Ruby might not be weird at all anymore, but maybe it’s not too late to push against this tired, pointless bullshit.