The Intuitive Machines lander issue was that no one disarmed the safety switch on the laser guidance system. (No, really!) Luckily NASA had a backup system installed that ended up working better anyway.
At my first job after university, we did releases every Friday evening. From 3-5pm, all you would see in the Slack channel was a flurry of everyone committing straight to master (with a bunch of merge conflict commits between). Oh and then we'd release. Fun times.
A free for all, late Friday deployment is baffling… We’ve got a strict window of Tuesday-Thursday for releases (unless it’s a critical issue), and a 2-3 day merge freeze to help mitigate unexpected changes.
We’ve got a relatively small team with LOTS of moving parts, so minimizing deployment issues is always top of mind.
I literally know multi billion dollar B2C startups doing the same. It's got so toxic that the management regularly fires people and to fill their spots, they offer obscene amounts of money just for starter positions.
That's no longer a technical process issue but more of a teamcoach/HR kind of issue then. You should be able to assume good intentions from colleagues, imho.
We use a CI pipeline check which prevents merges to master if the code contains a TODO. A precommit hook only works if the developer has the hooks configured.
Golang won't even compile with dead code. Unfortunately that's too strict, you just end up commenting out the whole block instead. At least the commented out code is obvious in review, and some automated checks catch it if you have them.
At my workplace, we have a lint rule that reports an error if @nocommit is anywhere in the file, plus a commit hook that blocks all commits with @nocommit anywhere in them. It works well and has saved me a few times.
Works pretty well, except the lint rule and its associated tests have to do something like "@no"+"commit" to avoid triggering it,
In a lot of modern work flows this is incompatible with the development pattern.
For example, at my job we have to roll a test release through CI that we then have to deploy to a test kubernetes cluster. You can't even do that if the build is failing because of linting issues.
The test release shouldn't have anything marked with @nocommit though... The idea is that you use it to mark code that is only temporary local debugging code that should never be committed.
On the one hand: kind of sad since this isn't too far removed from some workplaces. The hardware and furniture could be sourced from any number of places.
On the other: hot damn. We can get the same kit NASA uses at home. Welcome to the future.