4 ms·
I'm reading through Human Error by James Reason [1], on the basis of a HN recommendation. It's been excellent so far. As regards software error, we do so many
by ethbro 8y ago
I'm reading through Human Error by James Reason [1], on the basis of a HN recommendation. It's been excellent so far.
As regards software error, we do so many things (standard style guides, pair programming, code reviews) to limit error, yet give so little thought to where and how errors come to be. And specifically, what methods would best combat them.
This article and the procurement process it documents is a great example of "intentional but mistaken actions". Which is to say the actions taken were intentional, the actions were realized as intended, but the original formulation was flawed.
Reason notes these errors tend to thrive in overly compartmentalized, deep, bureaucratic environments. Everyone is doing their job, but there's no one keeping an eye on the big picture when the train heads off the rails.
The difficulty, according to him, is that higher-cognitive checks needed to short circuit these kinds of errors tend to be less effective (than lower, more primitive ones). IOW, we delude ourselves that everything is fine as often as we recognize the issue.
I expect this is part of the secret effectiveness of pass/fail unit testing. It's hard to rationalize a red indicator into a green one.
[1] https://www.amazon.com/Human-Error-James-Reason/dp/0521314194/ https://www.amazon.com/Human-Error-James-Reason/dp/052131419...
- ehmish 8y agoThis one here is a slightly different case to "intentional but mistaken". It is however one I've seen in software engineering environments: Person A designs something (in this case it's a gun, in software it could be an architectural pattern), Person B then insists on adjusting it, either ignoring or misunderstanding Person A's idea, and the result is something that is quite flawed. The best solution I think for these sorts of problems is for either Person A to be in a position of authority such that Person B _can't_ modify the design, or for Person A to design it exactly how Person B expects it to be designed.
- ethbro 8y agoI think the latter is the only tenable solution. The former presupposes that A is right, which is unknown a priori. It could very well be that A made a mistake, and B caught and corrected it! Or that B had a flash of genius and saw a better way that A missed. Which is how we arrived at, and still use in physical engineering, waterfall design. Its strengths were never meant to be adaptability to customer needs, but rather fully specified and communicated interfaces between components. Which is not nothing.
- ehmish 8y agoThe former has happened a number of times, for example with Kelly Johnston and Lockheed martin's Skunk Works, or many other institutions with charismatic dictatatorial engineers at the helm (Tesla, Linux, Microsoft). I'm definitely not saying that their respective leaders don't make bad decisions, but rather that a suboptimal solution, consistently implemented results in a better outcome than an inconsistent solution "optimised" by individuals along the way.