{
  "id": 10394126,
  "title": "Your thresholds do not belong in constants",
  "url": "https://urgent.news/2026/09/28/your-thresholds-do-not-belong-in-constants",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-28T07:21:01.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/darkpandawarrior/your-thresholds-do-not-belong-in-constants-3loe"
  },
  "original_language": "en",
  "account": "Thirteen years ago, a team made a decision that would significantly impact their software development process. Every time they needed to adjust a tuning parameter, it required a code review, a release, and a week-long store rollout. This made tuning nearly impossible, leading to the stagnation of the location pipeline.\n\nEighteen different numbers were used to determine the behaviour of the pipeline, including speed band boundaries, minimum displacement gates, stationary speed, jitter thresholds, rolling history window size, and hard teleport gates. All of these were marked as constant values, scattered throughout the processor code. They were informed guesses, tested and reasonable, but still merely guesses about how phones behaved in the hands of thousands of drivers.\n\nThe team recognized the importance of revisiting these constants once real data arrived. However, revisiting meant a costly process of editing code, opening a pull request, getting a review, cutting a build, and pushing to the store. At best, this could take a week to adjust a number by just 0.5.\n\nAs a result, discussions around thresholds became polarized, with opinions clashing due to the high cost of revisiting. The numbers became ossified and defended, turning into unexamined truths rather than stable constants. This negatively affected the system's ability to iterate and improve.\n\nThe team introduced a refactor to address the issue. They converted the constants into a Serializable data class called AbnormalDetectionConfig, with a companion object that held the default configuration. This change allowed for a pure move in the code, with no new abstractions or complex systems introduced. The defaults were byte-identical to the old constants, ensuring provable behaviour neutrality.\n\nThe refactor was approved without argument because it was a large change with a minimal cost of change. It allowed for injectable configuration and debug settings that could override the config without requiring a full rollout. Over time, server-driven configuration became a separate change to how the object was constructed, rather than a change to the algorithm itself.\n\nThis refactor was not a feature-flag system, a rules engine, or remote code execution. It was a simple struct of numbers with sane defaults. The goal was to make tuning parameters cheap to revise, turning them from hypotheses into actionable insights. By reducing the cost of changing constants, the team encouraged more measured and data-driven decision-making.",
  "summary": "Every tuning change needed a code review, a release, and a week of store rollout. So we stopped tuning, which is the worst possible outcome. Eighteen guesses in a const val Our location pipeline accumulated roughly eighteen numbers that shaped its behaviour: speed band boundaries (walking, cycling, driving) a minimum displacement gate for each band a stationary speed and jitter threshold a…",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}