Hardcoded Thresholds Slowed App Updates; A Simple Data Class Fixed It

A developer at a location-tracking platform found that storing 18 behavioural tuning parameters as hardcoded constants made adjustments costly, requiring a full code review, build, and app store rollout — taking up to a week to change a single number. The friction meant thresholds were rarely updated, turning informed guesses into unexamined assumptions defended by inertia. The fix was straightforward: moving all parameters into a serializable data class with defaults identical to the old constants, then injecting it as a constructor parameter into the location processor. This preserved existing behaviour entirely — all tests passed without modification — while enabling debug or server-driven overrides simply by changing where the object is constructed. The author argues that true constants belong only to fixed facts like unit conversions, while heuristic thresholds are hypotheses that must remain cheap to revise.