Part of a comment from Hacker News, which I should probably stop reading:

The biggest issue with ORM [object-relation mappers] isn’t the solution they came up with, half baked and buggy as they are, but the problem they are actually employeed [sic] to “solve”: developers afraid of SQL. Whether they can’t write it, can’t learn it, or just straight hate the string representation in their code, it’s the main reason people sign on for ORM.

In the early CoverMyMeds days, one of our most senior developers was not shy about telling you what they thought of ORMs, or the weak developers who relied on them. He was convinced that using a tool to write SQL queries for him took his control away, and that knowing precisely what queries powered each page was the best way to ensure performance and maintainability.

Thank goodness that person wasn’t able to make tooling decisions for the entire company, or we’d have been hosed.

Actually, the way we made technology decisions at CMM was pretty decent, and completely informal. Each project was allowed to pick the tooling that they wanted, given a few truths:

  1. Our infrastructure/production operations folks could support it. Ruby/Rails had become a safe choice, but folks still talk about how one dev wrote a service requiring MongoDB, which we’d never used. A week before launch they had to frantically re-architect the whole thing; ops had refused to try to support MongoDB with no lead time.
  2. You weren’t the only developer that knew it. We’d had an issue where some Python apps were launched to production, but only one person knew Python. That became problematic quickly when that person didn’t feel like they could take a day off.

Again: these were informal, the way everything was back then. There wasn’t a policy/procedure document that all the developers had to sign or anything, just an understanding amongst everyone. We knew we were all ultimately responsible for the success of our projects. This meant that my ORM-hating colleague was free to choose to hardcode every SQL statement his app wrote into a module somewhere while the rest of us used ActiveRecord.

Which, for the record, won out. Every developer at CoverMyMeds was required to be conversational in SQL, but not needing to write every instance of SELECT TOP 1 column FROM table ORDER BY sort_order ASC allowed us to focus more on what value we were supposed to be providing.

In an early-stage company, the technical decisions matter far less than a 25-year-old software developer wishes they did. You, your team, and your company should all be focused on how to solve a customer problem today. If your technology decisions are making you do more work but it’s not in service of solving a customer problem faster, they’re probably the wrong choices.

Published by Jon Canady

I'm Jon Canady. I was one of the Founding Engineers at a company called CoverMyMeds, and I helped build its technology and teams until our acquisition in 2017. I like helping companies figure out how to scale their engineering teams and practices. If you want to chat about how I can help your company, or you just want to grab lunch sometime, I'd love to hear from you!