The gym membership principle: why defining fitness functions isn’t the same as using them

The specific ways fitness functions fail go beyond neglect, and some of them look like diligence

Every January, gyms make most of their annual revenue. Not from people working out, but from people signing up. The economics of the fitness industry rest on a single, reliable human behaviour: the belief that registering for something is meaningfully close to doing it. The membership card feels like progress. The resolution feels like change. The gap between those two things is the business model.

Software teams have developed a remarkably similar relationship with fitness functions.

What they are and why they decay

Fitness functions are automated checks that continuously verify whether a system still satisfies its architectural properties. Response time below a threshold. No direct dependencies between certain modules. Service coupling within an acceptable range. The concept works like a building code rather than a blueprint. A blueprint captures intent at a moment in time. A building code keeps enforcing it as the system changes.

Why they decay when left without active stewardship is well-covered ground. Resilience decays the moment you stop practicing it, and fitness functions are no different. The more specific and interesting question is how they fail. Some failure modes are visible. Others actively disguise themselves as health.

The routine failures

A few patterns show up consistently.

• The check that measures the wrong environment. A function ensures no service exceeds a response time threshold, measured against a synthetic request in staging under light load. Production runs with different payload sizes, real concurrency, and integration latency that staging never approximates. The function passes reliably. The architecture is not fit in the way the team assumed. It is the same failure that makes health checks verifying a process responds categorically different from health checks verifying it can serve requests.
• The check that outlives the architecture it was written for. A team extracts a service from a monolith. The coupling check that once caught real violations now passes trivially, because the module it was watching no longer exists in the same form. The opposite happens too: a check that predates a structural change starts failing for reasons unrelated to architectural intent, generating enough noise that the team adds it to the list of things to investigate later and never does. Either way, a function that runs on every build and tells you nothing.
• The threshold set to pass rather than to reveal. A coupling metric stays below its ceiling. What nobody asked is whether that ceiling was derived from real architectural analysis or simply set to a value the system comfortably satisfies. A function that never tests anything demanding is measuring comfort, not capability.

Each of these is recognizable. A neglected function looks like a neglected function. The harder failure mode looks like diligence.

When the bar gets moved instead of the athlete

The most insidious failure produces a team that looks engaged with its fitness functions while systematically draining them of meaning.

It works like this. A coupling threshold gets set at a value that reflects genuine architectural intent. Over time, as delivery pressure builds, the architecture drifts. The check starts flagging. The team faces a decision: address the drift or adjust the threshold. Addressing the drift is slow and requires coordination. Adjusting the threshold takes minutes and makes the pipeline green again. Under pressure, the minutes win.

The function still runs on every build. Someone is clearly looking at the results, because they responded when it flagged. The badge is green. From any external view, this looks like active stewardship. The decay is entirely invisible.

This is what makes the pattern so persistent. The lazy failure modes, not running functions, not reading results, are at least identifiable. You can point to a neglected check. The gaming failure mode produces teams who are genuinely interacting with their fitness functions and getting worse architecture as a result.

The detection is in the history. Thresholds that drift consistently in one direction over time are a signal. A ceiling that started at ten cross-domain dependencies and now sits at twenty-five, without any corresponding architectural deliberation, is not a team keeping up with a growing system. It is a team that learned to move the bar. The question to ask is not “does this threshold pass?” but “where did this threshold come from, and when did someone last derive it from first principles rather than from the previous value?”

Treating threshold changes with the same review discipline as code changes, requiring justification and visibility, closes most of this gap. A threshold adjustment that cannot be explained in terms of architectural intent is not an adjustment. It is a concession.

The ownership gap

Behind most of these failure modes, including the gaming pattern, sits a structural problem: fitness functions rarely have owners who are accountable for what they mean, not just whether they pass.

This plays out differently depending on what a function is measuring. Functions that verify a property of a specific service have a natural owner: the team responsible for that service. If a coupling check covers two services owned by the same team, the accountability is clear.

Functions that verify system-wide architectural properties are different. A check that measures overall modularity across the system, or that cross-domain dependencies have not been introduced, belongs to no obvious team. It requires someone with system-level visibility to define it, maintain it, and act on what it finds. This is the category that matters most architecturally, because these are the checks protecting the properties no single team can protect alone. And it is precisely the category with the weakest natural ownership.

The consequence is a systematic gap. Teams write atomic functions readily, because the ownership is self-evident. Holistic functions either never get defined, because no one has the mandate to define them, or get defined once and immediately begin decaying, because no one’s job it is to maintain them. The architecture’s most important properties end up with the least reliable verification.

Individual discipline as a governance mechanism depletes under normal operating conditions. Fitness functions that rely on whoever notices to take action will follow the same curve. The structural fix is naming ownership explicitly, especially for holistic functions, and giving that owner the mandate not just to watch the checks run but to evolve what they measure.

More memberships, same result

The discovery of this gap has a common response: define more fitness functions. The reasoning is intuitive. If existing checks are insufficient, broader coverage should help.

It does not fix the underlying problem. Forty functions with no clear owners and no practice of reading their output produce the same outcome as four in the same condition. The pipeline takes longer to run and the noise-to-signal ratio worsens. Engineers learn to treat amber states as infrastructure overhead rather than architectural information. The checks become wallpaper.

There is also a second-order effect worth naming. A proliferation of fitness functions without clear ownership creates its own form of false security. The organization can point to an extensive suite of architectural checks. The coverage looks comprehensive. Nobody has examined what most of them are actually measuring, whether their thresholds are still relevant, or who would act if they flagged something real.

More checks is not the same as better fitness. Progressive overload in a gym adds weight after demonstrating mastery of the current load. The equivalent discipline here is making existing functions meaningful before adding new ones.

What the actual workout looks like

Functions worth trusting start with derivation. The question is not “what would be good to measure in principle” but “what would we need to know to feel confident about this release?” That connects directly to architecture principles, because the properties worth measuring should come from the properties the organization has decided to protect. A function that cannot be traced back to a named architectural concern is probably measuring something technically real and strategically arbitrary.

Results need to be read, not just run. Trends tell a story that threshold breaches never surface. A coupling metric that is technically within bounds but rising month over month is informative. Treating the output as a source of architectural intelligence rather than a binary pass condition changes what you get from it.

Thresholds need to be challenged periodically, not just monitored. If a function has not flagged a meaningful issue in a long time, two explanations are possible: the architecture is genuinely healthy, or the check is no longer demanding enough to reveal anything. The only way to distinguish between them is to probe deliberately.

And threshold changes should be treated with the same seriousness as the architectural decisions they govern. A change that cannot be justified in terms of intent is worth examining before it merges.

Fitness as an outcome, not a credential

The organizations that get this right talk about fitness functions in the present tense. Not “we have checks defined”, but “our dependency boundary check is currently showing unexpected coupling and we are deciding what to do about it”. The functions are informing decisions rather than decorating a pipeline.

Architecture drifts because software development generates constant pressure toward local convenience over global coherence. Fitness functions push back against that drift, but only if they are owned explicitly, derived from real intent, read with genuine attention, and maintained with enough discipline that adjusting a threshold requires more than a delivery deadline.

The membership card is not the workout. And a trainer who moves the weights lower every time the session gets hard is not helping you get fit.