I couldn’t finish reading this. Horror film. A screenplay to dystopian dread.
Normalization of Deviance (2015)
181–190 of 228 posts
Re: Normalization of Deviance (2015)
#182This rang so true for me. I’m constantly rediscovering things that I already understood well at my previous job. Once you get acclimatised to the current system, so many previously obvious learnings fall by the wayside.
Re: Normalization of Deviance (2015)
#183“Let's say you notice that your company has a problem that I've heard people at most companies complain about: people get promoted for heroism and putting out fires, not for preventing fires.” My first day at work at big-laser-company. Manufacturing engineer for a laser (then) so complex, it required a PhD to solve problems to get units out the door. The product was a ring laser. What that means is that the laser bea…
One of the key questions in my due diligence practice is whether people are allowed to 'be negative' and to literally stop the line to avoid shipping a defective product. This one question tends to separate out a very large fraction of companies that take unacceptable risks and allows the ones that don't to be justifiably proud of their attitude towards risk. These are not trivial things either, medical devices and s…
I've also learned this as "bring the solution", regardless of whether or not you find the problem.
Re: Normalization of Deviance (2015)
#184Earlier quoted context omitted.
> Like, how does the new hire (or anyone else) know the difference between "learning the complexity of the new system" and "internalizing/normalizing the deviance of this culture"? If a new hire can't checkout, build, and test the software on the first day, then there is likely something either wrong with the hire or the infrastructure. A sufficiently old and arcane software system might take weeks before a new hire…
Along with this "how long to spin up the new hire" issue, one of my first (if not the first) questions when trying to help people improve their processes related to software is: > If the user/client asks you to make a small but not trivial change, how long would it take to update and deploy the program? I have had answers ranging from "A couple hours" to "A year" (yes, they were serious). Most were in the 1-3 month r…
This is true, but there are cases where "months" makes sense. E.g. avionics, industrial, medical.
Re: Normalization of Deviance (2015)
#185“Let's say you notice that your company has a problem that I've heard people at most companies complain about: people get promoted for heroism and putting out fires, not for preventing fires.” My first day at work at big-laser-company. Manufacturing engineer for a laser (then) so complex, it required a PhD to solve problems to get units out the door. The product was a ring laser. What that means is that the laser bea…
One of the key questions in my due diligence practice is whether people are allowed to 'be negative' and to literally stop the line to avoid shipping a defective product. This one question tends to separate out a very large fraction of companies that take unacceptable risks and allows the ones that don't to be justifiably proud of their attitude towards risk. These are not trivial things either, medical devices and s…
The flip side of "quality first" / stop the line is getting killed in market by a worse but faster or cheaper solution. You are locked in game theory with your regulators (if you have any) and your competitors.
It's disappointing (and career limiting) to do the "right" engineering and lose because you didn't correctly gauge the risk tolerance of the market.
I don't think there's any one answer for this.
My observation is that people will pay a premium for demonstrable physical safety features but privacy & security in software do not win markets.
Re: Normalization of Deviance (2015)
#186Earlier quoted context omitted.
Along with this "how long to spin up the new hire" issue, one of my first (if not the first) questions when trying to help people improve their processes related to software is: > If the user/client asks you to make a small but not trivial change, how long would it take to update and deploy the program? I have had answers ranging from "A couple hours" to "A year" (yes, they were serious). Most were in the 1-3 month r…
This is true, but there are cases where "months" makes sense. E.g. avionics, industrial, medical.
That can extend the time, yes. I had a caveat about that but apparently edited it out before submitting. But that only explains or justifies the delays if there is value added. I work in aerospace and these were avionics and related systems. The bad ones did not have quality as a reason, though the good ones did. The bad processes were swamped with manual testing (which was non-comprehensive and error prone) or really tedious CM related activities (which was manual and error prone).
You can do a lot with good test automation, even in avionics. That cuts down a ton of the time and usually improves quality.
I'll also note, don't take my "deployed" too literally. I used that term because so many people here are working on server-based applications where that makes sense. Think "out the door". The exercise can only go as far as the team/org's reach. Deployed for avionics would mean more like, "At the flight test team". After that, it's up to someone else to schedule it and get it returned with issues or fielded.
Going beyond the team's reach without including those people (and thus making them part of the team, after a fashion) is guess work and opens up the blame-game. "It's all flight test's fault it takes a year to get out to the customer." Well, it takes you 9 months to get it to flight test and them 3 months to get done. So why does it take you 9 months? If you have a good reason (complex system, lots to test) then that's valid. If it's a simpler system, 9 months to get it to flight test is probably not justifiable.
Re: Normalization of Deviance (2015)
#187Earlier quoted context omitted.
Jidoka [1] is a key feature of Toyota's manufacturing process that emphasizes detecting defects before they make it out the door and empowering workers to stop the line and get to the root of the problem. It's weird that this isn't a no-brainer for most orgs but I guess there's enough profit incentive in shipping faster at the cost of quality. [1] https://en.wikipedia.org/wiki/Autonomation
Yes, it's worked really well for them: https://en.wikipedia.org/wiki/2009%E2%80%932011_Toyota_vehic... . I worked for a company that swallowed the (so-called) Toyota schtick hook, line, and sinker. About 14 years ago I tolerated some Toyota UK fossil coming in and berating me, in front of my entire team, for being a crap project manager, in spite of I was the most reliable and accurate product manager said (very succ…
Same for their JIT supply management. The attitude I have a hard time mitigating with manufacturing contractors years after the global supply chain have deteriorated.
Re: Normalization of Deviance (2015)
#188Earlier quoted context omitted.
One of the key questions in my due diligence practice is whether people are allowed to 'be negative' and to literally stop the line to avoid shipping a defective product. This one question tends to separate out a very large fraction of companies that take unacceptable risks and allows the ones that don't to be justifiably proud of their attitude towards risk. These are not trivial things either, medical devices and s…
The flip side of "quality first" / stop the line is getting killed in market by a worse but faster or cheaper solution. You are locked in game theory with your regulators (if you have any) and your competitors. It's disappointing (and career limiting) to do the "right" engineering and lose because you didn't correctly gauge the risk tolerance of the market. I don't think there's any one answer for this. My observatio…
This is mostly true but for things like medical devices, aerospace, industrial control and so on any corner cutting should be allowed.
I'm pretty sure that Philips right now has some thoughts on this as does Medtronic. Those two should have never happened and personally I'm all for liability of executives in such cases.
Re: Normalization of Deviance (2015)
#189Earlier quoted context omitted.
Yes, it's worked really well for them: https://en.wikipedia.org/wiki/2009%E2%80%932011_Toyota_vehic... . I worked for a company that swallowed the (so-called) Toyota schtick hook, line, and sinker. About 14 years ago I tolerated some Toyota UK fossil coming in and berating me, in front of my entire team, for being a crap project manager, in spite of I was the most reliable and accurate product manager said (very succ…
Same for their JIT supply management. The attitude I have a hard time mitigating with manufacturing contractors years after the global supply chain have deteriorated.
Those things work well when you're the only one doing them to gain an advantage over your competitors. But as soon as everybody starts doing it that means that the whole chain will adapt and suddenly all that stock that allowed you to do JIT and offload the costs of keeping that stock onto your suppliers evaporates which takes all of the slack out of the system. Now everybody has to perform and that will work right up to the first crisis and then the whole house of cards comes tumbling down.
It is always important to know what the underlying assumptions of your strategic advantages are. Going 'countercurrent' can work, but then if the tide turns you need to be aware that your previous advantage is now a risk.
Re: Normalization of Deviance (2015)
#190Related: Normalization of Deviance (2015) - https://news.ycombinator.com/item?id=22144330 - Jan 2020 (43 comments) Normalization of deviance in software: broken practices become standard (2015) - https://news.ycombinator.com/item?id=15835870 - Dec 2017 (27 comments) How Completely Messed Up Practices Become Normal - https://news.ycombinator.com/item?id=10811822 - Dec 2015 (252 comments) What We Can Learn From Aviatio…
Extrapolating from these related threads, this article should have 2K+ comments the next year.