4 ms·

Indeed, but this is a big "you should have gotten that in QA" kind of mistake. With the aggravating factor the the company markets security as one of iOS tentpo

Indeed, but this is a big "you should have gotten that in QA" kind of mistake. With the aggravating factor the the company markets security as one of iOS tentpoles... Accountability is a bitch, I guess, but in this case this was really in plain sight. I mean, it's not necessarily the dev's ass that's going to be kicked. There's a nice story about accountability at Apple once recalled in a profile by Adam Lashinski. It's from the Steve Jobs' era, but I guess this kind of policy is still enforced in Cupertino: One such lesson could be called the “Difference Between the Janitor and the Vice President,” and it’s a sermon Jobs delivers every time an executive reaches the VP level. Jobs imagines his garbage regularly not being emptied in his office, and when he asks the janitor why, he gets an excuse: The locks have been changed, and the janitor doesn’t have a key. This is an acceptable excuse coming from someone who empties trash bins for a living. The janitor gets to explain why something went wrong. Senior people do not. “When you’re the janitor,” Jobs has repeatedly told incoming VPs, “reasons matter.” He continues: “Somewhere between the janitor and the CEO, reasons stop mattering.” That “Rubicon,” he has said, “is crossed when you become a VP.”

btilly 10y ago
Indeed, but this is a big "you should have gotten that in QA" kind of mistake. It depends what kind of infrastructure you have. Ideally there should be NO MANUAL STEPS between dev and production. This should not be any need for a person to remember that this data should be inserted for dev and removed before prod. Instead there should be something like a documented way to insert the data or not based on a configuration file that is different for dev and production. Of course reaching that keeping that ideal requires discipline. And when you slip, it becomes easy to say, "That's QA's job." Over time QA's job will get harder and harder, and that is a guarantee of periodic slip-ups. Authority for fixing this situation really is the job of someone VP or above. They need to decide whether to fix the process and change what a lot of people do, or accept the inevitable screw-ups as the right choice to maintain the current rate of development.

btilly 10y ago

Indeed, but this is a big "you should have gotten that in QA" kind of mistake. It depends what kind of infrastructure you have. Ideally there should be NO MANUAL STEPS between dev and production. This should not be any need for a person to remember that this data should be inserted for dev and removed before prod. Instead there should be something like a documented way to insert the data or not based on a configuration file that is different for dev and production. Of course reaching that keeping that ideal requires discipline. And when you slip, it becomes easy to say, "That's QA's job." Over time QA's job will get harder and harder, and that is a guarantee of periodic slip-ups. Authority for fixing this situation really is the job of someone VP or above. They need to decide whether to fix the process and change what a lot of people do, or accept the inevitable screw-ups as the right choice to maintain the current rate of development.