Perhaps you're doing what I'm about to recommend already, but I can't be sure based on what you wrote. It's in regard to "2. Team says, "Need to ship; we'll acc

Perhaps you're doing what I'm about to recommend already, but I can't be sure based on what you wrote. It's in regard to "2. Team says, "Need to ship; we'll accept the risk". If the Business Unit, for whom the software is being written, has a representative on your team, then make sure you explain the risk in purely business terms, not technical ones. A BU rep's ears are going to perk up with statements like "invalid posts may get written to the general ledger" or "1 in every 20 orders may get dropped" rather than "universally scoped variables are being overwritten by invalid data in some cases" or "uncommitted nested transactions may cause a core dump." If your team doesn't include a BU rep, then you could always get friendly with one and explain the potential risks over coffee or lunch. Perhaps even suggest some questions the rep should ask the team before the mod goes live. In my situation, a BU rep is always part of the team and I rarely have other developers on the team. The reps and I have lunch together regularly anyway, so they get my opinions and recommendations that way.