It would be good if we (now that I feel I’m almost part of the Rails community) figured out how to do less shooting ourselves in the foot. Let’s turn gems into more service-like systems, so that a dotenv change can switch my authentication choices from one gem to another without requiring a lot of extra work.

This is the same DRY principle I learned, and implement, in the contract drafting world (yes, I’m a lawyer by education). Poorly drafted contracts have lots of bear traps hidden throughout, like a person’s individual name in Section 6.3, and a random sentence added to Section 5.4(a). These are the legal equivalent of hard coding numbers into your excel formulas or using a fixnum instead of a variable in a method (which I understand well because I understand the excel framework so well).

Gems should be more plug and play in basic methods, so that we’re not writing code, and then rewriting code to implement a new gem’s version of the same features. New code for new features, sure. But when I switch my email provider from one imap provider to another, the experience is awfully seamless.

Of course, gem authors aren’t really participants in a self-organizing system, and there’s no DHH to stake out a position for everyone else to either applaud or complain about. (And for that, this newbie says, “Thanks for being the lightning rod, DHH.” I know it can’t be a lot of fun some days.) But we as developers can think about ways to make our gems function more like services to our apps, so that we can replace and upgrade them without triggering lots of additional changes.

It’s not just DRY within an app, it’s also DRY within your app’s ecosystem and even across apps.

Having seen how a very old profession has continued to screw ourselves by poor architecture/design choices, I can see a path to improving the efficiency/value of dev time.