[SystemSafety] Putting Agile into a longer perspective

Chris Hills safetyyork at phaedsys.com
Sat Oct 26 15:44:23 CEST 2019


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




More information about the systemsafety mailing list