The Questions That Tell You More About a Codebase Than Reading the Code

Ally Piechowski has a piece on auditing legacy Rails codebases that’s mostly interesting for one thing: the audit questions have almost nothing to do with code.

The developer questions are diagnostic by fear: “What’s the one area you’re afraid to touch?” and “When’s the last time you deployed on a Friday?” Nobody in a healthy codebase is afraid of anything in particular. Nobody with real test coverage avoids Fridays on principle. These aren’t code metrics — they’re behavioral proxies for system health that you can’t fake with a green CI badge.

The CTO/EM questions go a level up: “What feature has been blocked for over a year?” and “What was the last feature that took significantly longer than estimated?” These reveal the organizational scar tissue that accumulates around technical debt — the features nobody will commit to because everyone knows they’ll be a nightmare. The code review won’t show you that. The postmortem queue will.

The business stakeholder questions are the most brutal: “Are there things you’ve stopped promising customers?” That’s the moment technical debt stops being an engineering problem and becomes a product problem — when the organization internalizes the system’s limits and starts routing around them instead of fixing them. Features getting quietly turned off and never coming back is how codebases communicate what nobody will say out loud.

The questions work because they’re social, not technical. You can groom a README, enforce linting, and hit 80% coverage while the system is quietly collapsing. But you can’t fake what you’re afraid to touch.

Key Ideas

• Fear as a diagnostic signal — “what area are you afraid to touch” surfaces real danger zones more accurately than cyclomatic complexity or code coverage numbers
• The Friday deploy test — a behavioral proxy for deployment confidence that requires zero tooling to run; teams with good test coverage and fast rollback don’t fear Fridays
• Organizational scar tissue — features blocked for a year or consistently over-estimated reveal technical debt’s compound interest better than any static analysis tool
• The “quietly turned off” question — when the business starts working around the codebase, debt has metastasized beyond engineering into product strategy
• Multi-stakeholder audit — different roles will tell you different things; developers know what’s scary, CTOs know what’s blocked, stakeholders know what got quietly dropped
• Social truth-telling — people reveal what they’re afraid of in interviews more readily than in documentation or tickets

Links

• Simon Willison quoting Ally Piechowski — the original signal
• How to Audit a Rails Codebase — Ally Piechowski’s full post
• Ally Piechowski — author’s site
• Simon Willison — via his always-good link blog