[bumby]

>I'm just going to cheat to save time and effort.

I totally understand the pressure, and the idea that these choices are a means to an end. And this isn't meant to sound condescending so please don't take it that way, but please PLEASE do not take this attitude into industry. Especially into a safety-critical industry. Believe it or not, it's more prevalent than you may think and humans are always good at rationalizing taking the easy way out.

I know the knee-jerk reaction will be "yeah, I won't do it when it matters" but these types of choices tend to become habits, and as the saying goes, habits become one's character and character becomes one's fate.

[Sirened]

This might be a dumb question, but what does this even look like in industry? I'm honestly not sure how I could "cheat" my way through my job. I have to design features, argue why they're good/worthwhile tradeoffs, and then implement them. Sure, I can steal features from competitors but I can't lie about their impact or fake implementing them because people will surely notice when the feature ships and simply doesn't work. Like, you can't cheat at design verification of a chip. If the chip ships and doesn't work, your ass is getting canned so fast.

[bumby]

There are all kinds of ways to cheat verification and validation. In my personal experience, it usually comes down to "cheating" to avoid missing a schedule milestone. It usually comes down to misrepresenting a system. One example that comes to mind was a programmer who created an artificial flag to avoid static analysis tools reporting some errors; passing static analysis was a requirement for their system to be cleared for use. When confronted, the team's reply said they did so because if the report identified issues, they'd be forced to fix them and they needed to meet schedule. I have lots of other examples, some more egregious, some less. Sometimes they border on being silly, such as when a team said they didn't need to validate their software because, since the system operation required a human to turn it on, it wasn't considered "software" in their definition of the word.

For context, these were a safety-critical systems. A lot of times when something went wrong on a research effort, people can cover their tracks by calling it an "anomaly" and avoid further digging to press forward. But a lot of the "anomalies" can be traced back to avoiding requirements or equivalently lying about test outcomes, most of the time due to schedule pressure or just a simple lack of expertise. And because many safety issues are low probability events, people can get lulled into complacency where this behavior becomes normal since it's still rare for something bad to happen.

Another example further down in the discussion was VW's cheating of emission tests by changing their vehicles operation when it was connected to a test stand.