Horse hockey. Outside of Middle Earth, there are two upsides to breaking stuff, dependent on how much bad juju said breakage could bring down:
- Minor breakage teaches any number of useful things that the user manual didn't cover.
- Major breakage--specifically the resulting panic--generates the organization's equivalents of urban legends, which become the reasons peeps don't knowingly break things that way ever again.
(For context: Code progresses up the food chain while it's integrated, tested, possibly demo'd to the client, and finally released into the wild. The development stage is the most experimental of those levels. The reason those changes hit the proverbial radar is because monitoring software has been installed at each "level.")
So for the second time in two days, I found myself spending a few minutes to defuse the situation. In today's case, what I said was something like, "I was just sanity-checking something, and I changed it back right away. Don't worry--I'd never presume to actually change anything without dealing with all the downstream ramifications." What I thought was more along the lines of, "Sheesh--keep your hair on! How long have I worked here?!?!?! When it hits the QA servers, then you can freak out!"
Now. In all fairness to, and defense of, The Powers That Be, we have a serious rollout looming. Twitchiness is completely understandable, and--to a certain extent--healthy. You should see how I react to "surprises" in what I fondly consider "my" code: The Powers That Be are actually pretty tame by comparison.
But in the main, freakouts over day-to-day breakage are extremely unhealthy. Personally, the mere fact that someone will now be notified every time I make a change to the database is a bit chilling in a Big-Brother-is-watching-you sort of way. So the upshot is that, in lieu of changing a database object, I've adapted my technique to bring the relevant code over to another editing window, and do my breaking there. Which turns out to be a (comparative) time-waster, because I will normally have to add extra code to mimic the "real world." But in this case, I refuse to feel guilty about the nicks in productivity. Because, in organizational terms: You are what you incentivize (or disincentivize). It's raw Darwinism, period. And if the time and resources you spend on the illusion of command-and-control merely breed more clever rule-benders (and rule-breakers), well...tough on you.