Slowly we rot: signs of a Rails app’s decay

Rails apps rarely collapse all at once. What starts as a TODO comment quietly becomes code you're afraid to touch: hard to understand, harder to change, and worse with every workaround. You might be eyeing a rewrite but, do you actually know how it got there?

After 13 years consulting on Rails apps, I've seen the same patterns of rot show up again and again. This talk is about those patterns: how they start, why they compound, and what you can actually do about them before they become someone else's problem (or yours, six months from now).

Presented at Rocky Mountain Ruby 2026

Transcript

1. Rocky Mountain Ruby Slowly we rot: signs of a Rails app’s decay
2. Fernando Perales Development Team Lead @ thoughtbot From Guadalajara, Mexico Host RubyMX (on hold for now) Clearance gem maintainer 13 years consulting on Rails apps About Me
3. When was the last time you ran your entire test suite locally? All your test suite
4. When was the last time you ran your entire test suite locally? Do you know how long it takes?
5. When was the last time you ran your entire test suite locally? “We don’t”
6. When was the last time you ran your entire test suite locally? “We don’t” Push → CI runs → work on something else
7. Slow and flaky tests
8. Slow and flaky tests Slow suite
9. Slow and flaky tests Slow suite CI only
10. Slow and flaky tests Slow suite CI only Flaky failure
11. Slow and flaky tests Slow suite CI only Flaky failure Rerun
12. Slow and flaky tests Slow suite CI only Flaky failure Rerun Trust drops
13. Where does the time go? Common accidental costs in Rails test suites
14. Where does the time go? # What user wants: let(:account) { create(:account) } ➡ Factories that recursively create objects you never use # What user gets: FactoryBot.define do factory :account do name { "Acme Inc." } after(:create) do |account| create_list(:user, 5, account: account) end end factory :user do association :account name { "Jane Doe" } after(:create) do |user| create_list(:notification, 10, user: user) end end factory :notification do association :user message { "Something happened" } end end
15. Where does the time go? ➡ Factories that recursively create objects you never use ➡ Using create when build is enough it "formats the user's name" do user = create(:user, first_name: "Jane", last_name: "Doe") expect(user.full_name).to eq("Jane Doe") end # Preferred user = build(:user, first_name: "Jane", last_name: "Doe")
16. Where does the time go? ➡ Factories that recursively create objects you never use ➡ Using create when build is enough ➡ Callbacks! class User < ApplicationRecord after_create :send_welcome_email def send_welcome_email UserMailer.welcome(self).deliver_now end end create(:user)
17. Where does the time go? ➡ Factories that recursively create objects you never use ➡ Using create when build is enough ➡ Callbacks! ➡ let! everywhere describe User do let!(:admin) { create(:admin) } let!(:account) { create(:account) } let!(:project) { create(:project, account:) } it "validates the name" do user = build(:user, name: nil) expect(user).not_to be_valid end end
18. Where does the time go? ➡ Factories that recursively create objects you never use ➡ Using create when build is enough ➡ Callbacks! ➡ let! everywhere ➡ Higher spec level than required # Integration it "shows the user's name" do user = create(:user, name: "Jane Doe") visit user_path(user) expect(page).to have_text("Jane Doe") end
19. Where does the time go? ➡ Factories that recursively create objects you never use ➡ Using create when build is enough ➡ Callbacks! ➡ let! everywhere ➡ Higher spec level than required # Request spec it "shows the user's name" do user = create(:user, name: "Jane Doe") get user_path(user) expect(response.body).to include("Jane Doe") end
20. Where does the time go? ➡ Factories that recursively create objects you never use ➡ Using create when build is enough ➡ Callbacks! ➡ let! everywhere ➡ Higher spec level than required # View spec it "shows the user's name" do assign(:user, build_stubbed(:user, name: "Jane Doe")) render expect(rendered).to include("Jane Doe") end
21. Where does the time go? ➡ Factories that recursively create objects you never use ➡ Using create when build is enough ➡ Callbacks! ➡ let! everywhere ➡ Higher spec level than required # ViewComponent spec it "shows the user's name" do user = build_stubbed(:user, name: "Jane Doe") render_inline(UserCardComponent.new(user:)) expect(page).to have_text("Jane Doe") end
22. Where does the time go? ➡ Factories that recursively create objects you never use ➡ Using create when build is enough ➡ Callbacks! ➡ let! everywhere ➡ Higher spec level than required ➡ File processing user.avatar.attach( io: File.open("spec/fixtures/files/ avatar.jpg"), filename: "avatar.jpg" ) user.avatar.variant(resize_to_limit: [500, 500]).processed
23. Where does the time go? ➡ Factories that recursively create objects you never use ➡ Using create when build is enough ➡ Callbacks! ➡ let! everywhere ➡ Higher spec level than required ➡ File processing ➡ Network-shaped work even when stubbed stub_request(:post, "https:// api.example.com/users") .to_return(status: 200, body: '{"id":123}') 100.times do ApiClient.new.create_user(create(:user)) end
24. Where does the time go? ➡ Factories that recursively create objects you never use ➡ Using create when build is enough ➡ Callbacks! ➡ let! everywhere ➡ Higher spec level than required ➡ File processing ➡ Network-shaped work even when stubbed ➡ Broad shared context shared_context "account setup" do let!(:account) { create(:account) } let!(:admin) { create(:admin, account:) } let!(:subscription) { create(:subscription, account:) } let!(:projects) { create_list(:project, 10, account:) } end describe Project do include_context "account setup" it "requires a title" do expect(build(:project, title: nil)).not_to be_valid end end
25. Where does the time go? The number isn’t the smell: not understanding the number is
26. Codebase deviations
27. Codebase deviations Pattern A This is how we do it here.
28. Codebase deviations Pattern B A better alternative is introduced
29. Codebase deviations The problem? Pattern A stays in the codebase
30. Codebase deviations Time passes
31. Codebase deviations People leave the team
32. Codebase deviations A newcomer joins
33. Codebase deviations A ? Which one is the right pattern? B
34. Codebase deviations Common codebase deviations
35. Common codebase deviations ➡ app/services vs lib with no clear boundary app/services/payments/charge_customer.rb app/services/reports/export_csv.rb lib/billing/retry_payment.rb lib/reports/monthly_report.rb lib/customer_sync.rb — app/services/ # application use cases lib/ # reusable infrastructure / frameworkindependent code
36. Common codebase deviations ➡ app/services vs lib with no clear boundary CreateOrder.call(user, params) ➡ Method signature drift CreateInvoice.new(account: account).call(order) Payments::Charge.call( customer: customer, amount: amount, metadata: {} ) OrderCreator.new(params, user, true, nil).execute
37. Common codebase deviations ➡ app/services vs lib with no clear boundary ➡ Method signature drift ImportUsers.call ImportUsers.perform ImportUsers.execute ImportUsers.run
38. Common codebase deviations ➡ app/services vs lib with no clear boundary ➡ Method signature drift ➡ Object responsibilities drift # A class starts as: class CreateOrder def call Order.create!(...) end end # Then, it grows: class CreateOrder def call validate_inventory calculate_tax create_order charge_card create_invoice send_email notify_slack track_event end end
39. Common codebase deviations ➡ app/services vs lib with no clear boundary ➡ Method signature drift ➡ Object responsibilities drift ➡ Request / integration / controller specs all coexist # These may be testing the same behavior in different ways spec/requests/users_spec.rb spec/controllers/users_controller_spec.rb test/integration/user_flow_test.rb spec/system/user_signup_spec.rb
40. ➡ Request / integration / controller app/services/ create_user.rb format_phone_number.rb calculate_tax.rb send_invoice.rb retry_payment.rb import_csv.rb normalize_address.rb check_permissions.rb specs all coexist # Some of them deserve better names Common codebase deviations ➡ app/services vs lib with no clear boundary ➡ Method signature drift ➡ Object responsibilities drift ➡ “Service objects” become the junk drawer TaxCalculator AddressNormalizer InvoiceMailer CsvImporter PaymentRetryPolicy AuthorizationPolicy
41. Common codebase deviations ➡ app/services vs lib with no clear boundary ➡ Method signature drift ➡ Object responsibilities drift ➡ Request / integration / controller UserCreator CreateUser UserCreationService Users::Create CreateUserService specs all coexist # With namespaces ➡ “Service objects” become the junk Billing::ChargeCustomer Payments::ChargeCustomer Stripe::ChargeCustomer ChargeCustomer drawer ➡ Naming deviations
42. Common codebase deviations ➡ app/services vs lib with no clear # Queries boundary # Some parts ➡ Method signature drift User.active.paid.recent ➡ Object responsibilities drift ➡ Request / integration / controller # Another place specs all coexist UsersQuery.new(active: true).call ➡ “Service objects” become the junk # Elsewhere drawer ➡ Naming deviations ➡ Logic placement User.where(active: true) .joins(:subscription) .where(...)
43. Common codebase deviations ➡ app/services vs lib with no clear boundary ➡ Method signature drift ➡ Object responsibilities drift ➡ Request / integration / controller specs all coexist ➡ “Service objects” become the junk drawer ➡ Naming deviations ➡ Logic placement # Validations class User < ApplicationRecord validates :email, presence: true end # Other places where validations can be found UserForm CreateUser UsersController
44. Common codebase deviations ➡ app/services vs lib with no clear # Business logic boundary after_create :charge_customer after_update :sync_crm after_commit :send_notifications ➡ Method signature drift ➡ Object responsibilities drift ➡ Request / integration / controller specs all coexist ➡ “Service objects” become the junk drawer ➡ Naming deviations ➡ Logic placement # But some business logic has a dedicated place CreateSubscription.call(...)
45. Common codebase deviations ➡ app/services vs lib with no clear boundary ➡ Method signature drift # Authorization ➡ Object responsibilities drift before_action :require_admin ➡ Request / integration / controller specs all coexist authorize @record ➡ “Service objects” become the junk current_user.can_edit?(@record) drawer PermissionService.call(...) ➡ Naming deviations ➡ Logic placement
46. Common codebase deviations ➡ app/services vs lib with no clear boundary ➡ Method signature drift # Serialization ➡ Object responsibilities drift render json: user ➡ Request / integration / controller UserSerializer.new(user) specs all coexist UserBlueprint.render(user) ➡ “Service objects” become the junk drawer ➡ Naming deviations ➡ Logic placement user.as_json(...)
47. Common codebase deviations ➡ app/services vs lib with no clear boundary ➡ Method signature drift # Configuration ➡ Object responsibilities drift ENV["STRIPE_KEY"] ➡ Request / integration / controller Rails.application.credentials.stripe[:key] specs all coexist Settings.stripe.key ➡ “Service objects” become the junk drawer ➡ Naming deviations ➡ Logic placement Rails.configuration.x.stripe_key
48. Common codebase deviations Conventions are only useful when the codebase use them consistently
49. Maintenance becomes migration
50. Maintenance becomes migration Think about that pending maintenance work you haven’t done
51. Maintenance becomes migration “It still works”
52. Maintenance becomes migration That answers today’s question but says nothing about the ability to change later
53. Maintenance becomes migration Webpacker
54. Maintenance becomes migration deprecated ≠ broken
55. Maintenance becomes migration deprecated ≠ broken ..but the longer you stay, the more of the future cost becomes yours to carry.
56. Maintenance becomes migration Migration looks painful
57. Maintenance becomes migration Migration looks painful Postpone
58. Maintenance becomes migration Migration looks painful Postpone Knowledge & versions drift
59. Maintenance becomes migration Migration looks painful Postpone Knowledge & versions drift Migration gets harder
60. Maintenance becomes migration Migration looks painful Postpone Knowledge & versions drift Migration gets harder Postpone again
61. Maintenance becomes migration Maintenance deferred long enough becomes migration work
62. Maintenance becomes migration Healthy teams can defer maintenance because they preserve the ability to act later
63. Complexity you haven’t earned
64. Complexity you haven’t earned Let’s add React!
65. Complexity you haven’t earned PostgreSQL is not enough
66. Complexity you haven’t earned We need Full-text search = We need Elasticsearch
67. Complexity you haven’t earned Microservices
68. Complexity you haven’t earned We optimize for the company we imagine instead of the one we have
69. Complexity you haven’t earned We identify a problem
70. Complexity you haven’t earned We identify a problem Misguided solution
71. Complexity you haven’t earned We identify a problem Misguided solution Complexity increases: it brings new problems
72. Complexity you haven’t earned We identify a problem Misguided solution Complexity increases: it brings new problems Why are we doing this?
73. Complexity you haven’t earned We identify a problem Misguided solution Complexity increases: it brings new problems Why are we doing this? Regret
74. Complexity you haven’t earned Before adding complexity: What are we objectively solving? What trade-offs are we accepting?
75. Complexity you haven’t earned Prefer boring Rails until the problem earns the complexity
76. Complexity you haven’t earned boringtechnology.club
77. Conclusion What do these problems have in common?
78. What do these problems have in common? Different symptoms, same pattern
79. What do these problems have in common? Friction appears
80. What do these problems have in common? Friction appears Workaround
81. What do these problems have in common? Friction appears Workaround Workaround becomes normal
82. What do these problems have in common? Friction appears Workaround Workaround becomes normal Original pain fades
83. What do these problems have in common? Friction appears Workaround Workaround becomes normal Original pain fades Cost compounds
84. Conclusion Key Takeaways • Rot is gradual, not catastrophic
85. Conclusion Key Takeaways • • Rot is gradual, not catastrophic Preserve your ability to change the system
86. Conclusion Key Takeaways • • • Rot is gradual, not catastrophic Preserve your ability to change the system Make trade-offs explicit, and revisit them
87. Conclusion Key Takeaways • • • • Rot is gradual, not catastrophic Preserve your ability to change the system Make trade-offs explicit, and revisit them In high school, we were allowed to ignore friction, but software teams don’t get that luxury
88. Conclusion What is the biggest friction your team is experiencing right now?
89. Thank you! Keep in touch! Contact Information fer@thoughtbot.com linkedin.com/in/ferperales