3 ms·
Attitudes like this are the reason that we don't have better practice industry wide. Seeing quality control as the enemy of success doesn't create good software
by nostrebored 6y ago
Attitudes like this are the reason that we don't have better practice industry wide. Seeing quality control as the enemy of success doesn't create good software, it creates technical debt and discourages prospective ops engineers.
The teams I've seen be the most comfortable with these knowably bad processes have been the strongest advocates against guardrails. The cost to your reputation and bottom line when something does go wrong is opaque to many engineers, but these kinds of ridiculous errors do lose customers.
Edit: A common saying where I work is that there are no stupid mistakes only bad processes. The first step to rooting them out is admitting that they're process level issues.
- closeparen 6y agoMy problem with process/policy is that it tends to attract a) bureaucrats, and b) the kind of engineer who is not particularly interested in or good at building products but still wants to ladder-climb. These are not the people I want dictating my workflow. That doesn't mean it's the "enemy of success." If we could raise its status to attract people with genuine technical competence and empathy for the realities of building, we could do a lot better. >Edit: A common saying where I work is that there are no stupid mistakes only bad processes. The first step to rooting them out is admitting that they're process level issues. Human stupidity is unbounded; such a process asymptotically approaches "do not change production ever." If you're a monopoly with a money printer, then keeping it running probably is more important than any improvement you could make. If you're under competitive pressure, you need to ship, and shipping necessarily involves risk.