[SystemSafety] Putting Agile into a longer perspective

[Steve Tockey]

Chris,

“I will leave the faith connotations to others but . . .”

Likewise, but I hear there’s been a fair amount of debate over ‘Thou shalt
not kill’ vs. 'Thou shalt not murder’. Same basic issue.


“Therefore for any process or method to be used "religiously" is a danger.
Also you should not assume (ass + U & me )   what "everyone knows"   but
check.  That so many do not check and do fill in the gaps is a MAJOR
problem.”

One of the drivers behind the 'Formalism Set A’ that I referred to earlier
is to leave as little room as possible for people to need to make
assumptions. The semantic modeling language forces a very fine-grained
level of detail before a model can be considered complete. Remember the
example, 'A whole number not less than zero, and not more than 1234’. For
certain kinds of data requirements, the specifier is obliged to explicitly
declare any policy-mandated lower bound, upper bound, precision, and units
of measurement. Even whether the stated lower- and upper- bounds are open
intervals vs. closed intervals also needs to be explicit.


“ . . . then who do you blame?   The person who, unknowingly,  had gaps in
their specifications or the people who "fixed" them without checking with
the person doing the requirements?”

I would blame the specification language for not a) exposing the need to
be precise to that level of detail, and b) giving a concise way to declare
things at this level of precision.


“BTW it is far more cost effective to do the requirements stress testing
on paper before writing a line of code or building any hardware. To start
work that you have to rebuild or repeat is  expensive and not a good use
of time.”

You and I both believe that. And many others may say they agree. But I am
constantly amazed by the number of people who―through their actions rather
than their words―clearly demonstrate that they do not believe.



Cheers,

― steve





-----Original Message-----
From: Chris Hills <safetyyork at phaedsys.com>
Organization: Phaedrus Systems
Reply-To: "safetyyork at phaedsys.com" <safetyyork at phaedsys.com>
Date: Saturday, October 26, 2019 at 6:44 AM
To: "systemsafety at lists.techfak.uni-bielefeld.de"
<systemsafety at lists.techfak.uni-bielefeld.de>
Cc: 'Olwen Morgan' <olwen at phaedsys.com>, Steve Tockey
<Steve.Tockey at construx.com>
Subject: RE: [SystemSafety] Putting Agile into a longer perspective

Hi  Steve and Olwen

> From: systemsafety
>[mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de] On Behalf Of
>Steve Tockey
> To: Olwen Morgan; systemsafety at lists.techfak.uni-bielefeld.de
>
> Olwen,
> "I do occasionally do professional translations (FR-EN and DE-EN).
>Translation is the most difficult thing in the humanities."
> Having studied French in school, and then self-studied both Korean and
>Chinese (none of which I would remotely consider myself fluent in, BTW),
>I would suggest that one part of this
> translation problem is the built-in ambiguity and verbose-ness that I
>just mentioned in my last reply. Another problem is that words in one
>language have definitions that don't overlap with
> nearly-equivalent words in the other language. For example, the Chinese
>word 家 (pronounced "jia" in Mandarin) can mean either house, family, or a
>combination of the two (among other
>  things). So that when someone tries to translate 家 into English,
>sometimes house is the right translation, sometimes family is the right
>translation, but sometimes there isn't an equivalent
>  English term to get across the originally intent. This is fairly easy
>to illustrate with translate.google.com. Translate a sentence in one
>language to another, then translate the translation back
>  to the source language. It can be entertaining how much really does get
>"lost in translation" because of non-equivalence of the words in either
>language.

My father, who started computing in 1952 when the jobs of "systems
analyst" and "programmer" were separate,  used to say one of the problems
is when people "know" the answer before they start.   That is when
translating requirements or languages  they [think they] know the intent
and translate to that intent filling in the blanks and reconciling
inconsistencies themselves, from their experiences,  to meet that intent.
 What they should do is query the intent  where more than one option is
possible.  And certainly getting the blanks or gaps addressed by the
originator and not second guessing yourself.  He gave me a couple of
technical examples which I can't fully remember (probably TSR2 or the
Flying Bedstead) and one intriguing linguistic one

The linguistic one was on translating some of the Dead Sea Scrolls.
Anyone who was at all religious already had the "definitive" answer in the
Talmud/Bible/Koran. So some religious translators used their religious
text as a guide to aid "correct" translation.   It threw up some
interesting problems.  For example in the historical/cultural context of
the documents  Mary was a "virtuous" women not a "virgin". In any other
document of the time, in the context used,  the world would be translated
as "virtuous." However as you could read the word as virgin on its own or
in a different context the more religious translators, using their
religious texts as guidance,  wanted to translate as "virgin".   The two
words had different connotations at the time and place, as they do now.
It was  hardly a major point unless it was pivotal in some ones faith or a
requirement in a critical system, but it was argued over.

I will leave the faith connotations to others but linguistically a
virtuous woman need not be a virgin, nor a virgin be virtuous. Even if in
some places, informally, the two are used interchangeably. So in a
critical system, filling in the blanks, or not clarifying,  a meaning: you
may not be meeting the requirements whilst feeling virtuous  that you
have. (try interchanging "virgin" into the last sentence :-)

Therefore for any process or method to be used "religiously" is a danger.
Also you should not assume (ass + U & me )   what "everyone knows"   but
check.  That so many do not check and do fill in the gaps is a MAJOR
problem.   

Sometimes the gaps being filled in give the illusion of a working system.
The original specifier may have absolutely no idea there was a gap in the
requirements and that it has been incorrectly filled  until it is the 2nd
Tuesday after Lent and it is raining.... then who do you blame?   The
person who, unknowingly,  had gaps in their specifications or the people
who "fixed" them without checking with the person doing the requirements?

BTW it is far more cost effective to do the requirements stress testing
on paper before writing a line of code or building any hardware. To start
work that you have to rebuild or repeat is  expensive and not a good use
of time. 



This email has been scanned by BullGuard antivirus protection.
For more info visit www.bullguard.com