Derailing Our Application: How and Why We Are Decoupling Our Code from Rails

Cisco is probably the largest Rails shop you’ve never heard of. Our 4 million line Ruby codebase has been under continuous development since 2007. As with any large codebase, ours is not without challenges. In “Derailing Our Application,” we share how our architecture has evolved to decouple 800,000 lines of Ruby code from Rails constructs in order to enable us to scale our team to 1,000 engineers and beyond without losing the benefits of Rails. Join us on the track less traveled! All aboard!

A Brewer's Guide to Filtering out Complexity and Churn

Mechanical coffee machines are amazing! You drop in a coin, listen for the clink, make a selection, and the machine springs to life, hissing, clicking, and whirring. Then the complex mechanical ballet ends, splashing that glorious, aromatic liquid into the cup. Ah! C’est magnifique! There’s just one problem. Our customers also want soup! And, our machine is not extensible. So, we have a choice: we can add to the complexity of our machine by jamming in a new dispenser with each new request; or, we can pause to make our machine more extensible before development slows to a halt.

Video: https://www.rubyevents.org/talks/a-brewer-s-guide-to-filtering-out-complexity-and-churn-rocky-mountain-ruby-2024

The Secret Ingredient: How To Understand and Resolve Just About Any Flaky Test

Flaky tests are an inscrutable bane. Hard to understand. Annoying. And, so frustrating! My personal nemesis is Daylight Saving Time. I can’t tell you how many times I’ve tripped over it. Let’s just say I was well into the “shame on me” part of that relationship, until I discovered the secret ingredient that nearly all flaky tests have in common. Turns out they only seem inscrutable. It really is possible to understand and resolve just about any flaky test.

Video: https://www.rubyevents.org/talks/the-secret-ingredient-how-to-understand-and-resolve-just-about-any-flaky-test

Indispensable: What Human Programmers Can Learn from Human Computers

Code used to be something we cultivated by hand. Now machines write it for us, and a quarter of a million tech workers have been laid off in less than a year. If you've been quietly grieving your relationship with code, you're not alone. And you're not the first.

In 1958, NASA began replacing its human computers with IBM mainframes. Three women from the segregated West Area Computing Unit — Dorothy Vaughan, Mary Jackson, and Katherine Johnson — made themselves indispensable to the mission anyway. Each chose a different strategy: retool, transform, or specify.

Now it's our turn as Rubyists. The mission is still here. The role is not. This talk borrows their strategies, with gratitude, for the transition we're living through now — and shows how to stay indispensable.

# Description

This talk draws on the story of NASA's human computers — the mathematicians who derived the algorithms and performed the calculations that sent humans to space — and the lessons they left behind when digital computers threatened to replace them.

Some were laid off. Some saw it coming and took action. They embraced the new way of running calculations and leveraged their domain knowledge in writing and validating the software.

Ruby developers are living through a similar transition. AI writes code faster than any of us. But that was never the job. The job has always been about figuring out what to build and how. Specifications are the what. Code quality standards are the how. That's where our value lies: in our domain and system design expertise.

Many Rubyists chose the language for its beautiful expressiveness. Some are grieving as companies mandate “100% agentic” coding. That's real.

This talk is for them. It delivers a concrete framework — Embrace, Specify, Verify — grounded in the stories of the NASA mathematicians who navigated the same transition. It focuses on the parts only humans can own.

Attendees will walk away with a new perspective on their role and a concrete plan for remaining in the driver's seat.

# Key takeaways

* Embrace: Rethink your purpose. Learn the tools. Don't wait for permission.
* Specify: Write the book on your system before the agent does.
* Verify: Set the bar. Hold the agent to it. Review what passes.

# Outline

This talk uses a standard three‑act structure.

## **Act 1: The Setup** (3 min)

Sets the scene at NASA Langley, introduces the human computers and the IBM mainframe, and poses the central question: who remains indispensable when automation threatens to take over human roles?

## **Act 2: The Confrontation** (21 min)

Tells the character stories of Dorothy, Katherine, and John, grounding Embrace, Specify, and Verify in history.

* Embrace: Dorothy Vaughan, the human computer who learned to program
* Specify: Katherine Johnson, the human computer and researcher who wrote the book on orbital mechanics
* Verify: John Glenn, the astronaut who refused to fly until a human computer verified the machine's math.

## **Act 3: The Resolution** (6 min)

Connects their choices to ours as Rubyists. The closing message: find a mission you care about deeply; embrace the tools, specify the work, verify the results; make yourself indispensable to the mission, not the mechanics.