You have 1 article left to read this month before you need to register a free LeadDev.com account.
‘All technologies suck. They just suck differently.’ – Me.
We all have biases about the technologies we use and many engineers acknowledge them. Every language and tool is developed to solve a particular problem and some subsets of people are attracted to that solution. Communities form and, inevitably, comparisons are made to other technologies that overlap in purpose. Soon, Verzuz-like battles occur in blog posts, conference presentations, and Twitter threads.
When I worked as a software engineer, I certainly had my share of biases. Many were informed by my computer science background and I tended to favor tools that felt more rigorous. I appreciated languages like Pascal, C, and C++, and turned my nose up to Perl and PHP. During my C++ years, I extolled the virtues of Borland’s Object Windows Library (OWL) over the thin wrapper approach of the Microsoft Foundation Classes (MFC). With time and experience, my self-described computer science bigotry softened and I became more curious about unfamiliar tools. I eventually saw things to appreciate in PHP. While I never did come to appreciate Perl, I did become fascinated with its more readable cousin Ruby.
It’s complicated
Harvest is a mature Ruby on Rails application. When I say ‘mature’, I mean a pre-Rails 1.0 O.G. application. Many of the engineers I lead have a strong affinity for Ruby and Rails. So, when I started internal discussions about people’s thoughts on alternatives to Ruby and Rails for parts of the application, not a wholesale re-implementation, I was not surprised by some of the reactions after the discussions concluded. ‘Why do you hate Ruby and Rails?’
Ruby is many things but a language that I hate is not one of them. In fact, it’s one of the languages I enjoyed coding in. It’s the language we used to build the first API in Adobe’s Creative Cloud. It was through Ruby that I found Merb and then Sinatra which deepened my appreciation for the language. Ruby even made implementing OAuth tolerable for me. What’s not to love?
Performance. Ruby may be a beautiful language to read and write but its performance lagged behind other runtimes. Performance may not be the only thing that matters when choosing an ecosystem but when it matters it matters a lot. The same goes for concurrency. We eventually migrated the Creative Cloud API to Node.js for those two reasons and then later to Go. Even now with the announcement of Ruby 3, performance remains an issue. Ruby 3 promised to be three times faster than the 8-year old Ruby 2.0 version. However, it wasn’t three times faster than the subsequent 2.x minor releases. Still, if Ruby 3 was three times faster than the last 2.x release how does that compare to code written in Node.js, Go, or Rust? How much tweaking does one have to do to approximate the default performance of other language ecosystems?
Being completely honest, my appreciation for Ruby far exceeds my appreciation for Ruby on Rails, but that does not mean I hate it. Ruby on Rails changed the game for Web development and is still one of the best choices for building many types of Web applications. Convention over configuration was an amazing insight embodied by a powerful framework. Over time, Rails grew as the jobs to be done increased. Web development became more complex and, by necessity, so did Rails. The Rails community needed solutions to the problems they faced and the Rails Core team provided its opinionated responses.
Opinionated. That is a key word in the Rails ecosystem. Rails eschews the approach of providing lots of options and configuration. They believe that you should have a strong opinion about the solution to a given problem. That’s a principled stance and I have no objection to it. However, over time these opinions are often interpreted as universal truths. That is where my objection lies.
Diversity of tech
More and more, the trend has moved from using best-of-breed solutions to all-encompassing ones. This, in turn, has led to a form of digital tribalism. People look increasingly inwards to the communities they align with and venture outside those boundaries, less. As opinions calcify, technology turns into ideology. When people start speaking as if their chosen technology platform is ‘the one true way’, we have a problem.
This is not to single out Ruby. Any tool that achieves success is subject to this. I’ve witnessed this in almost every community I’ve been in: Windows, Java, Ruby, JavaScript / Node.js, Go. It’s starting to occur in Rust now. It feels like we’re rejecting several aspects of the Unix philosophy particularly using small, purpose-built tools and combining them together in favor of monolithic all-encompassing solutions.
While the large tools and frameworks cannot possibly solve every problem well, they are often good enough. The real issue is when people stop challenging their own assumptions. What made a tool the best choice for you five years ago may not still be true today. Unicorn is still a solid application server for Ruby, but it still hungrily consumes memory. Maybe we should switch to Puma, or consider a completely different stack? Rails can be used to provide an API service but do we need all the baggage it brings? Roda has a lot of the elements that make Sinatra compelling with a few additional niceties.
Final thoughts
Choosing to explore alternatives to your current technology choices does not have to be a sign that you’re throwing away hard-earned knowledge and stability. Often, by understanding how other ecosystems approach problems you can discover ways to bring those benefits back to your preferred environment. You may then see more clearly the limitations in your current tool and make better decisions as to how to use it (or not). Venturing outside your comfort zone and learning new things, even if you don’t end up using them, contributes to your growth as an engineer and reduces the likelihood of treating technology as ideology. Our goal should be to choose the tools that best solve the problems we’ve been hired to solve within the constraints we’ve been given. The tools you favor may accomplish this today but the problems will change over time. Why shouldn’t your tools?
