The Function
It's 847 lines long. It was written by someone who left the company three years ago. It does authentication, logging, data transformation, email sending, and — for reasons nobody can explain — it also updates a cache that was deprecated in 2022 but still runs because nobody is sure what breaks if it stops.
Everyone on the team knows this function is a problem. Nobody wants to touch it.
Why Nobody Wants to Touch It
The honest answer is risk. The function works. It has worked, continuously, for four years. It has survived three major refactors of the surrounding codebase, two database migrations, and a complete rewrite of the authentication system that somehow left this function intact. It is load-bearing in ways that are not documented and possibly not fully understood.
The person who would benefit most from fixing it is the person who would be blamed if fixing it broke something. That's a bad incentive structure. It means the function will continue to exist until it breaks on its own, at which point the person who has to fix it under pressure will have even less context than the person who could have fixed it carefully.
This is a known failure mode in software organizations. The openedterminal blog has touched on it before in the context of technical debt, but the function problem is slightly different from technical debt. Technical debt is usually about shortcuts taken under time pressure. This function is about knowledge that was never written down and is now locked inside 847 lines of code that nobody wants to read.
The Meeting
We had a meeting about it. Forty-five minutes. The outcome was a ticket in the backlog labeled "refactor processUserData function" with a priority of "medium" and no assignee. The ticket has been in the backlog for seven months. It will probably be there for seven more.
The meeting was not useless — we at least acknowledged the problem exists and agreed it should eventually be fixed. But "eventually" in a backlog is a synonym for "never unless something forces our hand." The forcing event will be a production incident. The production incident will be worse than the refactor would have been.
I've seen this pattern enough times to recognize it. The developer community talks about it in terms of "if it ain't broke don't fix it," which is reasonable advice for individual decisions but terrible policy for codebases. Codebases that are never fixed accumulate risk until the risk becomes a crisis.
What Actually Fixes It
Not a meeting. Not a ticket. A person who decides to understand the function, documents what they learn, and then — slowly, carefully, with tests — starts extracting pieces of it into smaller functions with single responsibilities.
The key word is slowly. You don't refactor 847 lines in a sprint. You refactor 50 lines, ship it, watch it for a week, refactor 50 more. You build confidence incrementally. You write tests before you change anything so you know what "working" looks like. You treat the function like a patient rather than a problem.
This takes longer than a big-bang rewrite. It's also much less likely to cause a production incident. The big-bang rewrite is tempting because it feels decisive. It's usually a mistake. More on incremental refactoring at resources for developers working on legacy code and in writing about sustainable engineering practices.
The Actual Problem
The function is a symptom. The disease is that the team doesn't have a culture of continuous improvement — of making things slightly better every time you touch them. If that culture existed, the function would have been incrementally improved over four years and would be half as long and twice as understandable by now.
Building that culture is harder than fixing the function. But it's the only fix that lasts.