The Config File That Outlived the Project
A YAML file I wrote for a weekend experiment in 2019 is now load-bearing in three unrelated systems, and nobody including me remembers what half the keys do.
It began as home.yaml, forty lines, written on a Sunday to avoid hardcoding a
few sensor thresholds.
It is now three hundred lines and imported by things that have nothing to do with the house.
How this happens
Not through any single bad decision. Through a long sequence of entirely reasonable ones:
# 2019 — the original intent
thresholds:
soil_moisture: 0.35
temperature_high: 32
# 2023 — still defensible
notifications:
quiet_hours: ['22:00', '07:00']
# 2025 — what is this doing here
export:
legacy_csv_columns: [ts, val, src, flag2]Each addition was the path of least resistance at the time. flag2 in
particular has no documentation, no reference in any code I can find by
grepping, and removing it breaks a nightly job.
What I should have done
Split it the first time something outside the house imported it. That was the moment the file stopped being configuration for one project and became a shared interface — and shared interfaces need owners, versions, and someone willing to say no.
I did not notice the moment when it happened. I suspect nobody ever does.
What I did instead
Added a comment at the top saying see git blame. Which is honest, at least.
Tags
- maintenance
- yaml