Re: [SystemSafety] Another unbelievable failure (file system overflow)

From: Matthew Squair < >
Date: Fri, 5 Jun 2015 22:01:53 +1000


OK, the golden rule.

Much honoured in the breach but still it pops up again and again and again in whatever culture or religion you'd care to name. The idea of 'fairness' and 'fair play' that underpins it is of course very useful for a primate that spends most of it's time in small clans or tribes.

On Fri, Jun 5, 2015 at 4:56 PM, Chris Hills <safetyyork_at_xxxxxx

> Well give me one ethic or moral that is fixed and universally applies
> constantly.
>
>
>
> *From:* Les Chambers [mailto:les_at_xxxxxx > *Sent:* 05 June 2015 00:47
> *To:* safetyyork_at_xxxxxx > *Cc:* systemsafety_at_xxxxxx >
> *Subject:* RE: [SystemSafety] Another unbelievable failure (file system
> overflow)
>
>
>
> For instance???
>
>
>
> *From:* systemsafety-bounces_at_xxxxxx > mailto:systemsafety-bounces_at_xxxxxx > <systemsafety-bounces_at_xxxxxx > Hills
> *Sent:* Friday, June 5, 2015 6:21 AM
> *To:* 'Andy Ashworth'; 'Steve Tockey'
> *Cc:* systemsafety_at_xxxxxx > *Subject:* Re: [SystemSafety] Another unbelievable failure (file system
> overflow)
>
>
>
> The problem is that ethics, like morality are not fixed and change over
> time and culture. There are no absolute morals nor ethics.
>
>
>
> Regards
>
> Chris
>
>
>
> Eur Ing Chris Hills BSc CEng MIET MBCS FRGS FRSA
> Phaedrus Systems Ltd Tel: FREEphone 0808 1800 358
> 96 Brambling B77 5PG Vat GB860621831 Co Reg #04120771
> Http://www.phaedsys.com <http://www.phaedsys.com/> chills_at_xxxxxx >
>
>
>
>
> *From:* systemsafety-bounces_at_xxxxxx > mailto:systemsafety-bounces_at_xxxxxx > <systemsafety-bounces_at_xxxxxx > Ashworth
> *Sent:* 02 June 2015 19:11
> *To:* Steve Tockey
> *Cc:* systemsafety_at_xxxxxx > *Subject:* Re: [SystemSafety] Another unbelievable failure (file system
> overflow)
>
>
>
> Here in Canada, in order to be registered as an engineer you must have a
> recognized engineer I degree, appropriate experience and you must also pass
> a Professional Practice Exam consisting of two papers - law and ethics.
>
>
>
> Andy
>
>
> Sent from Andy's iPad
>
>
> On Jun 2, 2015, at 14:05, Steve Tockey <Steve.Tockey_at_xxxxxx >
>
>
> Les,
>
> For what it's worth, Seattle University (a private, Jesuit university)
> requires discussions of ethics in all university degree programs. I got my
> masters degree there (Software Engineering) and I taught later as an
> adjunct professor. While we didn't have ethics in every course, the topic
> was highly encouraged by the university and came up fairly frequently.
>
>
>
>
>
> -- steve
>
>
>
>
>
>
>
>
>
> *From: *Les Chambers <les_at_xxxxxx > *Date: *Saturday, May 30, 2015 9:14 PM
> *To: *Steve Tockey <Steve.Tockey_at_xxxxxx > schaefer_robert_at_xxxxxx > *Cc: *"systemsafety_at_xxxxxx > systemsafety_at_xxxxxx > *Subject: *RE: [SystemSafety] Another unbelievable failure (file system
> overflow)
>
>
>
> Steve
>
> Thanks for referencing the code of ethics. It should be brought up more
> often. Unfortunately, for me, it makes depressing reading. Especially when
> you come upon paragraphs such as:
>
>
>
> 3.12. Work to develop software and related documents that respect the
> privacy of those who will be affected by that software.
>
>
>
> Although he has probably never read it, there is a man, who will probably
> never see his homeland again because he took these sentiments to heart and
> attempted his own corrective action. And what of the thousands of
> scientists, engineers and technologists who contributed to the construction
> of the software, the existence of which, he exposed to the world?
>
>
>
> My point is that non-compliance with this code of ethics is massive and
> almost universal. In fact, any engineer maintaining strict compliance with
> every paragraph of this code would be unemployable in our modern world.
>
>
>
> Reading these paragraphs through the lens of experience I am blown away by
> their flippancy. From personal experience I can tell you that screwing up
> the courage to implement even one of these items can be a massive life
> changing event. This sentence would be lost on a graduate. They're all
> perfectly reasonable statements of how one should behave. Much like, "Thou
> shall not kill, thou shall not commit adultery ...". The issue lies in the
> moral courage to implement.
>
>
>
> There is no quick fix to this problem as we are a decentralised,
> unorganised and generally fragmented lot. We don't have the luxury of the
> medical profession that deals with a single organism. We can't simply state
> and righteously comply with the notion of, "Do no harm." In fact, for us,
> the opposite is true, many of us work in industries where the primary
> purpose is to kill other human beings, and with high efficiency (fewer
> soldiers kill more enemy).
>
>
>
> One thing we can do is deal with the problem at its root:
>
>
>
> We are graduating incomplete human beings from science and engineering
> courses. There is insufficient focus on the moral issues surrounding the
> impact of our machines on humanity. For example, a study of applied
> philosophy, including ethics, should be a nonnegotiable component of all
> engineering courses. Not just a final year subject, but a subject for every
> year with a weekly reflection on the content. Much like the weekly safety
> meetings I was forced to attend in the chemical processing industry.
>
>
>
> I'm sure there will be howls of laughter at this, but, let me tell you
> it's the only thing that caused me to back a senior manager about five
> levels above my pay grade into a corner - he could physically not escape me
> short of punching me out and stepping over my body - and berate him until
> he promised to properly train his operators in the emergency procedures for
> a safety critical system.
>
>
>
> Popping a few paragraphs up on the web would never have done the trick.
>
>
>
> That experience was trivia compared to where we are headed. The massive
> computing power now available means that our software is beginning to take
> higher level decisions away from human beings. Some of these decisions are
> moral ones (refer my previous post on lethal autonomous weapons systems).
> "Shall I kill all humans associated with this structure, or no?"
>
>
>
> At a recent engineering alumni meeting I asked the head of my old
> engineering Department how much philosophy is taught to undergraduate
> engineers. He chuckled. "It is available as an elective but less than one
> percent participate," he said.
>
>
>
> I plan to speak to him again soon.
>
>
>
> Cheers
>
> Les
>
>
>
> *From:* Steve Tockey [mailto:Steve.Tockey_at_xxxxxx > <Steve.Tockey_at_xxxxxx > *Sent:* Sunday, May 31, 2015 5:43 AM
> *To:* Les Chambers; 'Robert Schaefer at 300'
> *Cc:* systemsafety_at_xxxxxx > *Subject:* Re: [SystemSafety] Another unbelievable failure (file system
> overflow)
>
>
>
>
>
> Les (and all),
>
> I think that one thing we all need to be really careful of is that it's
> way too easy for us technical people to push all of the blame onto the
> managers:
>
>
>
> "It's the fault of those idiotic Pointy Haired Bosses because they gave us
> such a ridiculously short schedule, …"
>
>
>
> And it's true to an extent that managers are guilty. But it's not 100%
> their fault. Us technical people need to grow up and be more professional
> in our own behavior. Here's a great quote from Watts Humphries:
>
>
>
> "When people are directed by top management to run a mile in two minutes,
> what should they do? Experienced hardware engineers have learned to first
> test the directive. If it is truly firm, the best ones develop
> a comprehensive comparison of this job with their prior experience to show
> management why this schedule is unrealistic. They also dig in their heels
> and insist that management either change the schedule to one that makes
> sense or relieve them of responsibility for meeting the dates. When better
> engineers do this, managers have little choice, unless they want to do
> the design themselves. Unfortunately, all too many programmers start
> looking for their running shoes."
>
>
>
> The IEEE Computer Society and the Association of Computing Machinery (ACM)
> got together several years ago and agreed on a "Software Engineering Code
> of Ethics and Professional Practice" (see
> https://www.acm.org/about/se-code). Of particular relevance to this
> discussion are items: 1.03, 3.01, 3.02, 3.09 (a personal favorite of mine),
> 5.11, and 6.11. It's a no-brainer that as long as the technical community
> doesn't push back then managers will just continue to push ever harder.
>
>
>
> I often use the term, "highly paid amateur programmer". I firmly believe
> that this an appropriate label that applies to the vast majority of
> software practitioners world wide. Their behavior is wholly unprofessional
> and, in fact, entirely unethical.
>
>
>
> I could (and often do--smile) go off on a rant about how auto mechanics
> behave far, far more professionally than typical programmers.
>
>
>
>
>
> Cheers,
>
>
>
> -- steve
>
>
>
>
>
>
>
> *From: *Les Chambers <les_at_xxxxxx > *Date: *Friday, May 29, 2015 8:23 PM
> *To: *Steve Tockey <Steve.Tockey_at_xxxxxx > schaefer_robert_at_xxxxxx > *Cc: *"systemsafety_at_xxxxxx > systemsafety_at_xxxxxx > *Subject: *RE: [SystemSafety] Another unbelievable failure (file system
> overflow)
>
>
>
> Steve
>
> Clap, clap, clap, clap. At last, a serious metric, guaranteed to make a
> difference because it uses story patterns, the only facility guaranteed to
> change attitudes. George should go underground and embrace the onion
> router. He is clearly a dangerous radical.
>
> However, Dilbert aside, it behoves us to dig deeper and look at causal
> factors. Somewhere further back in this stream the point was made that the
> good programmer/bad manager metaphor gets trotted out too often. This is
> very true, I've been guilty of it myself, having socialist leanings and
> being in the presence of far too many disgustingly poor management
> decisions in my 40 year career. But. We should ask, "How does a programmer
> or a manager become BAD." I put it to the list that this is the exact same
> question as, "How does a person become a criminal?"
>
> Most serial killers are the product of child abuse. Indeed most criminals
> have had damaged childhoods. Incompetent child rearing or no child rearing
> - not brought up, just kicked and told to get up. No role models or the
> wrong role models: Street gangs, drug dealers, thieves and murderers. Bill
> Clinton addressed this once:
>
> "People who grew up in difficult circumstances and yet are successful have
> one thing in common; at a crucial juncture in their adolescence, they had a
> positive relationship with a caring adult." (More at:
> http://www.chambers.com.au/public_resources/mentoring_wp.pdf)
>
>
>
> The FBI specialists who hunt down serial killers have a saying, "The best
> indicator of future behaviour is past behaviour."
>
>
>
> So, any way you want to look at this problem, the only way to break the
> endless cycle of "glitches" is: better child rearing. Anyone responsible
> for the rearing of a software developer or his or her manager should
> reflect on this.
>
>
>
> Cheers
>
> Les
>
>
>
> PS: This "... has become clear" (at least to me), "later on."
>
>
>
> *From:*systemsafety-bounces_at_xxxxxx > mailto:systemsafety-bounces_at_xxxxxx > <systemsafety-bounces_at_xxxxxx > Tockey
> *Sent:* Saturday, May 30, 2015 4:34 AM
> *To:* Robert Schaefer at 300
> *Cc:* systemsafety_at_xxxxxx > *Subject:* Re: [SystemSafety] Another unbelievable failure (file system
> overflow)
>
>
>
>
>
> >From what I remember about Scott Adams, at least in the early days he
> used a "three company rule". The majority of his comics come from ideas
> submitted by readers. His rule was that he had to see the same basic idea
> come from at least three different companies before he had confidence the
> problem was widespread enough to be understood/funny for a majority of
> readers. I don't know if he follows the same rule now, but it would make
> sense.
>
>
>
> I agree, a socio-economic study of insights of Dilbert would be
> fascinating.
>
>
>
> And, by the way, if anyone remembers the Software Engineering institute's
> "Capability Maturity Model" (CMM), here's a proposed update:
>
>
>
> ----- cut here -----
>
>
>
> API Austin - First there were software metrics. With these, software developers
> and their management could finally measure something for the output of
> the software creation process. In the 80's these techniques flourished.
> Funny names for these measurements emerged, like "McCabe complexity" and
> "software volume".
>
>
>
> Soon it was realized that there needed to be a way not only to measure the
> quality of the software output, but also to measure the quality of the
> engineering organization itself. The Capability Maturity Model, CMM, was
> developed in the early 90's. Organizations are audited by professionals
> and rated on a scale of 1 to 5. Low scores mean the software production
> process is chaotic, while 5 means that all aspects of software development
> are fully understood and carefully applied, organizations today weigh in at
> a meager 1, and there's a surprising number of 0's out there.
>
>
>
> Now, a revolutionary new measurement technique has been developed by a small
> startup consulting firm in Austin, Texas. The new system is simply known
> as DCF. The simplicity and elegance of the new measuring system belies its
> power in accurately judging the soundness of a software organization.
>
>
>
> The inventor of DCF and founder of the DiCoFact Foundation, George Kritsonis,
> says the new measurement system is "simple and fool-proof, but
> modifications are being made to make it management-proof as well".
>
>
>
> One Sunday morning George was performing his normal ritual of reading the
> most important parts of the newspaper first, when he came across his
> favorite comic strip, "Dilbert" by Scott Adams. George and his
> work colleagues loved this comic strip and were amazed by how many of
> the silly storylines reminded them of actual incidences at their company.
>
> They even suspected that Scott Adams was working there in disguise, or at
> least that there was a spy in the company feeding Scott daily promised to
> make him millions: The Dilbert Correlation Factor (DCF).
>
>
>
> George's idea was simple: "Take 100 random Dilbert comic strips and present
> them in a survey to all your engineering personnel. Include both engineers
> and management. Each person reads the strips, and puts a check mark on
> each strip that reminds him of how his company operates. Collect all
> surveys and count the check marks. This gives you your Dilbert
> Correllation Factor, which can range of course from 0% to 100%. Average
> out the engineers scores. Throw out the manager's surveys, we just have
> them do the survey to make them feel important; however, if many of them
> scowl during the survey, add up to 5 points to the DCF (in technical terms,
> this is your Management Dissing Fudge Factor, MDFF). Make sure to also
> throw out surveys of engineers that laugh uncontrollably during the whole
> survey (remember their names for subsequent counseling). And that's all
> there is to it! Oh yeah, then walk around the building and count Dilbert
> cartoons on the walls. Don't forget coffee bars, bulletin boards, office
> doors and of course, bathrooms". Add up to 10 points for this
> Dilbert Density Coefficient Adjustment (DDCA).
>
>
>
> Interpreting the results is simple. Let's look at some ranges:
>
>
>
> 0% - 25%: You probably have a quality software organization. However,
> you guy's need to lighten up! Maybe a few surprise random layoff, or
> perhaps initiating a Quality Improvement Program, will do the trick to
> boost your company's DCF to healthier level.
>
>
>
> 26% - 50%: This is also a sign of a good software organization, and is
> nearly ideal. You still manage to get a quality product out, and yet you
> still have some of the fun that only Dilbert lovers can identify with...
> Mandatory membership in social committees, endless e-mail debates about the
> right acronyms to use for the company products, and of course detailed
> weekly status reports where everyone lists "did status report" on
> accomplishments.
>
>
>
> 51% - 75%: This is the most typical DCF level for software houses today.
> Your software products are often in jeopardy due to the Dilbert-like
> environment they are produced in. You have a nice healthy dose of routine
> mismanagement, senseless endless meetings with no conclusions,
> miscommunications at all levels of the organization, and arbitrary
> commitments made to customers which send engineers into cataplexy.
>
>
>
> 76% - 100%: The best advice for this organization is this: Get the hell
> out of the software business. Hire the best cartoonist you can afford,
> have him join your project teams and document what he sees in comic
> strips... get 'em syndicated and you'll make a fortune!
>
>
>
> George has applied for a patent on his unique DCF system. He is anxious to
> become a high-priced consultant, going to lots of companies, doing his
> survey, getting the fee, and getting out before management realizes they've
> been ripped off and have to hire another high-priced consultant to come in
> and set things right. George reports, "I'm thinking about a do-it-yourself
> version for the future, too. I'd put Dilbert cartoons on little cards so
> they can be passed out to the engineers for the survey... I'll probably
> call it 'Deal-a-Dilbert'. I'm also thinking about a simple measurement
> system that lets employees find out their personality type and where they
> best fit into the organization. I call this the 'Dilbert/Dogbert Empathy
> Factor' or 'DDEF' for short.
>
>
>
> ----- end cut here -----
>
>
>
>
>
> Cheers,
>
>
>
> -- steve
>
>
>
>
>
>
>
>
>
> *From: *Robert Schaefer at 300 <schaefer_robert_at_xxxxxx > *Date: *Friday, May 29, 2015 5:11 AM
> *Cc: *"systemsafety_at_xxxxxx > systemsafety_at_xxxxxx > *Subject: *Re: [SystemSafety] Another unbelievable failure (file system
> overflow)
>
>
>
> I would claim that this not always prospect theory sometimes dysfunction
> due to greed.
>
>
>
> By deliberately not testing you can get the customer to:
>
> 1. become your beta tester, i.e. work for you for free
>
> 2. directly or indirectly get the customer pay you again for you
> fixing your own mistakes
>
> 3. You leave no evidence of criminal negligence (when you are indeed
> criminally negligent ->
>
> if you did detect safety issues during testing, those issues would
> be recorded in the testing documentation).
>
>
>
> I would like to see, someday, a serious socio-economic study of the
> insights of the Dilbert comic (dilbert.com).
>
> I have read in interviews with the cartoonist (Scott Adams) that people
> email him what they've experienced,
>
> and he just draws it up. One might claim that what he does is all made up,
> but I have my doubts given what
>
> I've experienced as a programmer in several large corporations over the
> past decades.
>
>
> ------------------------------
>
> *From:*systemsafety-bounces_at_xxxxxx > systemsafety-bounces_at_xxxxxx > Squair <mattsquair_at_xxxxxx > *Sent:* Friday, May 29, 2015 2:13 AM
> *To:* Heath Raftery
> *Cc:* systemsafety_at_xxxxxx > *Subject:* Re: [SystemSafety] Another unbelievable failure (file system
> overflow)
>
>
>
> An example of prospect theory?
>
> Matthew Squair
>
>
>
> MIEAust, CPEng
>
> Mob: +61 488770655
>
> Email; Mattsquair_at_xxxxxx >
> Web: http://criticaluncertainties.com
>
>
> On 29 May 2015, at 7:43 am, Heath Raftery <heath.raftery_at_xxxxxx > wrote:
>
> On 28/05/2015 11:50 PM, Chris Hills wrote:
>
> Static analysis isn't free. Testing isn't free.
>
> Who determines the need for or business case for static analysis and test?
>
> [CAH] normally (every report I have seen) static analysis saves a lot of
>
> time and money.
>
> The same is true of structured testing.
>
>
> Funnily enough, the only experience I've had recommending static analysis
> is as the programmer to the manager. This is indeed the argument I use. A
> strange thing happens in business though (and perhaps my lack of
> comprehension explains why I'm the programmer and not the manager ;-) ) -
> capital costs and investment are worse than running costs. Buying and
> applying static analysis, even if it is cheaper in the long run, is always
> seen as less attractive than paying labour to deal with the consequences
> later.
>
> Heath
> _______________________________________________
> The System Safety Mailing List
> systemsafety_at_xxxxxx >
> _______________________________________________
> The System Safety Mailing List
> systemsafety_at_xxxxxx >
>
> _______________________________________________
> The System Safety Mailing List
> systemsafety_at_xxxxxx >
>

-- 
*Matthew Squair*
MIEAust CPEng

Mob: +61 488770655
Email: MattSquair_at_xxxxxx
Website: www.criticaluncertainties.com <http://criticaluncertainties.com/>



_______________________________________________ The System Safety Mailing List systemsafety_at_xxxxxx
Received on Fri Jun 05 2015 - 14:02:07 CEST

This archive was generated by hypermail 2.3.0 : Fri Apr 26 2019 - 00:17:07 CEST