What I Learned Reading a Decade of Other People's Tracking Implementations

Consulting means constantly inheriting other people's tracking setups, usually with no documentation and no one left on the client side who remembers the original decisions. Over enough of these, patterns emerge that have nothing to do with the skill of whoever wrote the original code and everything to do with the conditions they were working under.

The single most common pattern: tags that duplicate an existing one 'just in case' instead of modifying or removing the original. Almost every time, this traces back to someone who was afraid to touch a production tag they didn't fully understand, so they added a new one alongside it rather than risk breaking something they couldn't confidently fix if it went wrong. Reasonable individual decision. Catastrophic after being repeated by four different people over four years.

The other recurring patterns

• Hardcoded values where a variable should be, almost always added under deadline pressure with every intention of 'fixing it properly later'
• Comments explaining what a tag does, written by someone clearly uncertain themselves, functioning as a note to a future debugger rather than documentation of intent
• Dead triggers left in place because nobody was confident enough to confirm they were actually unused
• A naming convention that's internally consistent for the first six months and then fractures the moment a second person touches the container without reading the first person's conventions

Almost nothing I've found in an inherited tracking setup was caused by incompetence. Almost everything was caused by fear of breaking something nobody had time to fully understand.

What this changed about how I write my own tags

I now assume whoever inherits a container from me will be operating under the same fear and time pressure I've seen produce every one of these patterns, and I write documentation specifically aimed at reducing that fear — not generic documentation, but documentation that answers 'is it safe to change this' directly. The goal isn't a perfect container. It's a container the next person feels safe enough to actually touch, instead of duplicating around.