Alt bliver software - f.eks. i vore telefoner

Jeg havde en af de der Nokia-telefoner, der bare virkede i mange år og
havde så meget afstand mellem tasterne, at jeg faktisk kunne taste en
slags blindskrift på den, og mine 45-årige tommelfingre blev ikke bøjet
udover hvad naturen kunne håndtere.

Den holdt ikke evigt, og det var tid til at få en ny. Den nye har
farveskærm (så den skal oplades hele tiden, men skidt), og den kan alt
muligt med Internettet og andre helt utrolige ting med lyd, billeder,
dokumenter og film.

Det er godt. Så kan jeg f.eks. altid finde det billede frem, som mine
venner tog, da jeg kørte ud fra en benzinstation i Jylland uden at tage
benzinslangen ud af det dersens hul i siden af min bil.

Men det tager præcist 45 sekunder at sende en SMS.

Det gjorde det vist ikke, da jeg købte telefonen. Jeg synes at kunne
huske, at den bare sendte SMS-beskeder med det samme dengang. Det eneste jeg kan komme i tanke om har ændret sig er, at jeg har stoppet noget mere memory i den, dvs. et miniSD-kort, eller hvad de nu hedder.

45 sekunder. Den står bare og sender (eller viser et frossent billede)
og først derefter kan jeg lave andet på telefonen. Så jeg skriver mine
svar til folk og trykker på send-knappen og lægger telefonen fra mig og
går ud og køber ind eller hører en udsendelse i P1 eller lignende. Det
føles ihvertfald som lang tid.

Men jeg kan ikke finde ud af, om det er en kendt fejl, hvad man kan gøre ved det, eller i det hele taget komme til bunds i sagen (dvs finde den eftertragtede Root Cause).

Jeg kan trykke *#0000# som er en tastekombination, der på de fleste
Nokia-telefoner vil vise versionen af dens software, og så kan jeg gå
hen på http://europe.nokia.com/A4176111 og se, om der er en nyere
version jeg kan opgradere min telefon med.

Men det er jo bare rent gætværk. Bare fordi software ikke er det sidste
nye skrig behøver jo ikke betyde, at det er blevet dårligt. Bits bliver
ikke trætte over tid.

På den anden side kan det jo godt være, at min problem forsvinder hvis jeg opgraderer. Jeg ved det ikke.

Jeg kan ikke spørge Nokia, om de kender noget til det. De har
tilsyneladende ingen mekanisme til at tage imod spørgsmål fra deres
kunder. De henviser til "operatøren". Min "operatør" er Sonofon, men jeg tror helt ærligt ikke det nytter specielt meget at gå ned til de -
iøvrigt meget søde mennesker - i Sonofon-butikken og spørge, om det her er en kendt bug i softwaren.

Thi de har ikke adgang til nogensomhelst bug-database. Så det er en
blindgyde, desværre. Jeg ved, at Nokia har en intern bug-database, men så skal jeg kende nogen der kender nogen, og den vej er ikke lykkedes for mig endnu.

Så den nødvendige viden om dette findes måske indeni Nokia et sted, men den viden kan jeg ikke få fat på.

Jeg har arbejdet med bugs i software i mine 10 år i Oracle Support, og
opgraderinger kan jo nogle gange fixe bugs og så sandelig også
introducere nye. Det er der ikke noget at gøre ved når vi taler
software. Det laves af mennesker.

Men jeg ville jo egentlig også gerne vide, om der er kendte bugs, der
bliver introduceret med den nyeste version af softwaren til min
Nokia-telefon - andre må jo have brugt den i et stykke tid.

Så det er rent Gæt & Grimasser, og jeg har desværre for lang tid siden
mistet min barnetro omkring tekniske fix og nyere versioner af software.

Men hvad gør I andre egentlig? Det er jo ikke kun telefoner, der mere og mere bliver software. Vore biler, elevatorer, TV-sæt, iPod'er,
vaskemaskiner, køleskabe, kaffemaskiner, mikrobølgeovne og mange andre ting omkring os.... de har nu software i dem.

Jeg ved, at det amerikanske highway sikkerheds-organ (hvad det nu ellers hedder) har en database, hvor almindelige borgere kan rapportere om problemer de har haft med deres bil - og når et bestemt problem er blevet rapporteret tilstrækkeligt mange gange bliver leverandøren (bilproducenten) bedt om at kigge på det.

Måske findes der tilsvarende mekanismer på andre områder, men jeg kender ikke til det.

Så hvad gør I andre? Er der nogle steder, hvor folk diskuterer f.eks.
bugs i deres telefoner?

Og ville I anbefale mig bare at opgradere?

Kommentarer (11)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Casper Thomsen

Jeg oplever generelt, at mobilproducenter skubber nye telefoner så hurtigt ud, at der er mange dumme fejl, som burde være fjernet først. Men det er nok bare et udtryk for konkurrencesituationen, hvor mange entusiaster hellere vil acceptere fejl end at vente på de nyeste modeller.

Senest har jeg fået ny mobiltelefon i form af Sony Ericcsons M600i. Bortset fra lidt sløve svartider har jeg været ganske tilfreds med telefonen, men i løbet af de seneste uger har jeg også oplevet, at den fryser og genstarter uden forklaring. I sidste uge begyndte den så at melde om fejl i SIM-kortet, og nu er den på vej til reparation.

Problemer af samme slags har jeg nu hørt fra mindst fire andre brugere af samme telefon. To af dem har droppet dem og en enkelt overvejer det.

Sandsynligvis vil en opdatering også hjælpe her, men hvor meget kan man kræve af os brugere? Én ting er, at det i forvejen kræver rigelige mængder af koncentration og tid at sætte telefonerne korrekt op til at modtage mails (også via push) og gå på nettet.

Det grundlæggende problem (eller udfordring, som mobilproducenterne nok vil kalde det) er vel, at mobiltelefonerne - og dermed softwaren - bliver langt mere kompliceret på meget kort tid? Lad os håbe, at producenterne fortsat vil have fokus på kvalitet og test, selvom det gælder om at komme først på markedet med den nyeste og mest hippe (og mindste) mobil MP3afspiller-kamera-websurfer-spillemaskine-osv. Jeg vil nødigt have, at min mobiltelefon bliver lige så ustabil som min pc.

Poul-Henning Kamp Blogger

Open Source projekter sidder ikke og gemmer på deres "hemmeligheder" som kommercielle leverandører er nødt til for at undgå at blive sagsøgt for bevidst at levere defekte produkter.

Men du mener jo closed source per definition er bedre, så du må vel være glad for at du ikke blive belemret med den slags unødvendig og ligegyldig information.

Poul-Henning

Mogens Nørgaard

Hej Poul-Henning,

Jeg mener nu ikke, at jeg har brugt betegnelsen "per definition" eller noget, der antyder dette. Jeg har derimod prøvet at sige, at der så sandelig også er priser at betale (ulemper) ved open source-modellen. Det kan du formentlig ikke være uenig i. Med mindre du er religiøs omkring det, og så er det jo svært at diskutere.

Flaming/personlige angreb på og af alt og alle, der vover at kritisere open source er iøvrigt temmelig udbredt ifølge folk inde i "bevægelsen" jeg har talt med. Ordet "open" burde egentlig også være betegnende for bevægelsens holdning til de, der ikke er 100% enige med dem, eller stiller spørgsmål ved modellen, ikke?

Iøvrigt synes jeg ikke, at dit indlæg bidrager til debatten om dette emne. Det har snarere karakter af et personligt angreb på mig, og det er du velkommen til - men spørgsmålet er, om det interesserer så forfærdeligt mange andre end dig (og tildels mig)?

Så jeg vil foreslå at du skrev sådan noget direkte til mig på mno@MiracleAS.dk og så kom med nogle indlæg her, som andre kunne have fornøjelse af (og måske blive lidt klogere af).

Men det kan godt være, at du har en pointe: At der enten er færre fejl i consumer-produkter med open source-software i dem - eller at brugerne er mere tilfredse med disse, fordi de nemmere kan finde ud af, om de er ramt af en kendt bug eller ej, osv.

Hvis det altså var din pointe?

Jeg ved ikke, om Symbion (som er i min telefon) er open source eller ej - hvis det er, så skulle det jo være muligt at finde ud af noget. Ved nogen det?

Jeg tror dog ikke det er særligt nemt for min tante Grethe i Fredericia at slå op i open source-arkiver for at finde ud af, om hun kan gøre noget ved hendes Skype-telefon, eller hvad hun end måtte have problemer med.

Closed source firmaer (med deres lukkede, men omfattende databaser) eller open source (med deres åbne, men omfattende databaser) løser ikke nødvendigvis problemet med at kunne identificere og reparere et problem i et consumer product.

Nørretranders talte i en af sine bøger om 'gate keepers', der kunne hjælpe folk med at finde og filtrere information, mv. Hvis behovet er stort nok, så findes der vel også en ny service, der kan opfindes her.

Jeg har ikke selv kunnet finde en hjemmeside, hvor man kunne få hjælp med sine consumer produkters software, men måske en skønne dag?

Poul-Henning Kamp Blogger

Mogens,

Min pointe var kort og godt at du lød meget hjælpeløs i den klagesang over lukkede leverandører.

Taget i betragtning hvor store armbevægelser du startede med i din blog, antog jeg at det ikke var nødvendigt med en smiley for at du selv kunne se ironien ?

Jeg er ikke militant med open source mere end jeg godt kan leve med closed source, hvis blot leverandøren lever op til hvad man så naturligt må forvente af fejlrettelser, produktansvar, etisk opførsel, langtids support mv.

Den oplevelse du har nu med din mobiltelefon har jeg gentagne gange haft med computere i de sidste 25 år og derfor mener jeg at man bør bruge open source, for hvis Software industrien efter 25 år stadig ikke har lært at behandle kunderne anstændigt, så fortjener den ikke fremme.

Men hvis ikke kan finde en Open Source løsning, så må man som et minimum kræve ordentlig behandling fra closed source leverandøren.

"Vi lover intet, fortæller intet, holder dine data som gidsel og giver ingen garanti, men du betaler til gengæld overpris så vi har råd til at tryne alle der kommer os ivejen" bør ikke være en acceptabel forretningsmodel i et civiliseret samfund.

Poul-Henning

Jens Madsen

Open/closes software betyder intet. Det som betyder noget, er hvordan programmet bliver til. Du skal altid dokumentere enhver rutine, med såvel ram forbrug, som forsinkelse (evt kun store O funktion). Og, det gælder helt ud i den sidste ende, så du kan opskrive maksimum forsinkelse og forbrug af ram, for en given operation, såsom at tømme postkassen eller sende post, overfor brugeren. Rutiner, skal også have oprindelse, såsom navn på frembringeren ol. så en dårlig programmør (der har lavet rutiner med for stort ram forbrug, og for stor store O funktion) undgås.

Der kan udvikles programmeringssprog, der kan hjælpe til med sådan dokumentation omkring forsinkelser og forbrug.

Helge Svendsen

Hejsa,

Jeg er ikke helt sikker på jeg forstår det første afsnit.

"Der kan udvikles programmeringssprog, der kan hjælpe til med sådan dokumentation omkring forsinkelser og forbrug."

Alle moderne sprog har da en profiler, der kan dokumentere, hvor i koden, der bruges mest tid?

mvh

Nikolaj Hansen

Jens Madsen

"Alle moderne sprog har da en profiler, der kan dokumentere, hvor i koden, der bruges mest tid?"

Der hvor jeg er, bruges C++ og Java. Trods, det er muligt at se hvor i koden der bruges mest tid, fås de mest åndsvage svar fra programmørerne. F.eks. at det er udskrivning af debug indformation, som tager tid - når debug indformation er slået fra. Joh, enten er softwaren lavet tåbelig, eller også fås ikke brugbar indformation.

Jeg tror ikke, at vi rigtigt får løst problemet, før leverandørerne skal opgive datablade for softwaren, hvor timingen dokumenteres. Det har vi altid gjort for hardware, og her har vi "værktøjerne" til analyse. Med andre ord, er ikke nok med et værktøj, der fortæller hvor flaskehalsen er placeret. Vi skal have værktøjer, der kan hjælpe til dokumentation af maksimum forsinkelse, fra et input forekommer, til et output opstår. Og dette, skal dokumenteres i tekniske datablade for programmet. Her er det maksimum og worst case forsinkelsen som gælder. Og at den "typisk" klarer det på et halvt sekund, er til kloaken. Der findes ikke typisk. Der findes kun worst case.

Før programmørerne skal levere sådanne data, og som softwaren virkelig skal opfylde, så opnår vi ikke ordentligt programmel.

Helge Svendsen

"Der hvor jeg er, bruges C++ og Java. Trods, det er muligt at se hvor i koden der bruges mest tid, fås de mest åndsvage svar fra programmørerne. F.eks. at det er udskrivning af debug indformation, som tager tid - når debug indformation er slået fra. Joh, enten er softwaren lavet tåbelig, eller også fås ikke brugbar indformation."

Ja, eller også forstår du ikke de svar, der gives. At debug output tager tid selv om det er slået fra er da helt indlysende. Hver gang du kommer forbi et debug statement skal du jo stadig evaluere, om der skal debugges eller ej. Det tager tid.

"Jeg tror ikke, at vi rigtigt får løst problemet, før leverandørerne skal opgive datablade for softwaren"

Det hedder dokumentation, eks. javadoc for java. Det er rigeligt til at dokumentere en implementering.

"Vi skal have værktøjer, der kan hjælpe til dokumentation af maksimum forsinkelse, fra et input forekommer, til et output opstår."

Hvis du kan forklare mig hvordan en udvikler skulle kunne gøre det i eks. java, hvor man ikke ved hvilken fysisk maskine koden kommer til at køre på, så må du godt nok have noget af en krystal kugle.

Der kan være en million faktorer, der afgør hvor lang tid der går imellem input og output. Det eneste sted man seriøst kan arbejde med den slags er i real time systemer, og jeg har en mistanke om, at det er den verden du kommer fra.

Man kan lave en SLA som målsætning for en metode. Der vil altid være enkelte kald, der tager meget længere tid, og nogle, der måske aldrig bliver færdige.

"Her er det maksimum og worst case forsinkelsen som gælder. Og at den "typisk" klarer det på et halvt sekund, er til kloaken. Der findes ikke typisk. Der findes kun worst case."

Worst case er aldrig .. Det kan du ikke måle med. Undtagen i real time udvikling. Forestil dig. eks. et web service kald, hvor du er afhængig af noget funktionalitet på en server, du ikke har magt over. Et kald til en sådan kan fejle både pga nedbrud på netværk og på remote server.

Derfor er det vigtigt at tage højde for den slags i koden.

"Før programmørerne skal levere sådanne data, og som softwaren virkelig skal opfylde, så opnår vi ikke ordentligt programmel."

Vrøvl, det du siger er, at vi ikke opnår ordenlig software efter dine kvalitetskrav.

Andre steder vil man være i situationer, hvor eksekverings tid ikke betyder en hatfis. Bare tingene kører igennem med success på et eller andet tidspunkt.

Det er blandt andet det, der ligger bag JMS begrebet i JEE verdenen

Jens Madsen

"At debug output tager tid selv om det er slået fra er da helt indlysende. Hver gang du kommer forbi et debug statement skal du jo stadig evaluere, om der skal debugges eller ej. Det tager tid." Indlysende eller ej - det vidner om en dårlig compiler. For det første, er det simpelt at tjekke på en bit, og det bør ikke tage tid. For det andet, vil en fortolker, nemt kunne "oversætte" det pågældende bid af programmet (kompilerende fortolker), og antager at den pågældende variabel er konstant da den ikke modificeres i det oversatte stykke kode. Eller - sagt på anden måde - så er vi måske på vej retur til comal.

"Hvis du kan forklare mig hvordan en udvikler skulle kunne gøre det i eks. java, hvor man ikke ved hvilken fysisk maskine koden kommer til at køre på, så må du godt nok have noget af en krystal kugle."

Som nævnt, skrev jeg tid - ofte store O funktionen. For Java, er intet problem, at angive store O funktionen, og hvilke parametre den afhænger af. Når du har disse faktorer, kan du forholdsvis hurtigt kalibrere din funktions forsinkelse.

"Man kan lave en SLA som målsætning for en metode. Der vil altid være enkelte kald, der tager meget længere tid, og nogle, der måske aldrig bliver færdige."

Specielt det sidste, har jeg set ofte. Og netop det, ønskede jeg at forhindre. Der må ikke være rutiner eller kald, der ikke bliver færdig. Hvis vi venter på et fysisk input (f.eks. tast), er det ikke et problem, for udregning af forsinkelsen fra input til output.

"Worst case er aldrig .. Det kan du ikke måle med. Undtagen i real time udvikling. Forestil dig. eks. et web service kald, hvor du er afhængig af noget funktionalitet på en server, du ikke har magt over. Et kald til en sådan kan fejle både pga nedbrud på netværk og på remote server."

Du har altid magt over andres programmer, for de opfylder nogen specifikationer. Og du anvender disse specifikationer, i dine udregninger. Ingen program, har specifikation som "jeg ved da ikke, om jeg gider at svare"... Et sådan program, må ganske simpelt ikke bruges og ingen vil, eller kan bruge den.

I tilfælde, hvor det er komplet umuligt, at få data for andres software, eller det som der kommunikeres med, så har du ikke et problem. Du kan godt opskrive store O funktioner, og hvilke størrelser dit programs forsinkelser afhænger af, uden kendskab til de andres forsinkelse. Denne indgår, i dine udregninger som ukendte størrelser (f.eks. X). I de fleste tilfælde, kan du betragte dit eget program, som en stykke kode, med inputs og outputs, og du kan opskrive datablade for forsinkelse, i dit software. Hvis det er software som Java, ol. må du angive det med store O funktioner. I princippet kan du "tælle" indstruktioner i Java, og angive dette. Det, at der er en faktor i fejl, betyder ikke alverden for det samlede resultat. Det vigtige er eksponenter. Og om den total gror fast.

"Vrøvl, det du siger er, at vi ikke opnår ordenlig software efter dine kvalitetskrav."

Jeg mener, at alle brugere, har et kvalitetskrav om, der kommer et resultat indenfor en given tid. Vi kan ikke vente for evigt, eller affinde sig med, at "worst case is never output", som du angiver det altid er.

En anden ting er, at jeg ikke mener at Java er et egnet programmeringssprog - og hellerikke C++. Som eksempel, mener jeg, at Java (efter hvad jeg har fået forklaret, jeg er ikke selv ekspert i dette), ikke er et deterministisk sprog. Ikke deterministiske sprog, skyldes typisk anvendelsen af paralleliteter. Som sådan, kan det være fordele i, at et programmeringssprog har ikke deterministiske konstruktioner. Men, det må ikke være noget, en programmør kan indbygge, uden det tydeligt ses, at dette er en ikke deterministisk tilfældighedsgenerator. Når noget, er tilfældigt, skal det ses tydeligt. Og det bedste, er at kunne "forbyde" tilfældigt opførsel, på overordnet niveau, for en undergruppe af software.

Et ordentligt sprog, er efter min opfattelse, i stand til at kunne tage et program, der angives i rækkefølge, og selv omdanne det til parallelisme. Derved, skal du ikke spekulere på hardwarens indbyggede parallelisme, eller tvinges til, at tænke parallelt. Det skal være i stand til, at når du kommer med en input/output specifikation, så at automatisk kunne udføre dele der kan udføres i tilfældig rækkefølge, på den mest optimale måde. Input/output specifikationen er den, som afgør, hvordan input og output hænger fysisk sammen, og om de er koordineret, eller om de må være uafhængige. F.eks. må to diske være uafhængige - meddens to porte, på samme disk, er afhængige, fordi rækkefølgen indstruktionerne sendes i på de to diske, betyder noget. Når dette er specificeret, kan programmeringssproget selv omdanne koden, til optimal udførsel, uanset antal processorer. Det, at tilbyde parallelitet, er ikke nødvendigt. For det vil altid være der. Du kan ikke forestille dig sekventiel kode, hvor to dele der ikke kommunikerer gennem variable, ikke altid per automatik udføres i tilfældig rækkefølge, og eventuelt parallelt, afhængig af hvad der er mest hensigtsmæssigt. Der findes ingen argumentatin for, at kunne angive parallelisme i noget sprog. Det viser kun, at sproget er designet til, at være for dumt, til at kunne sikre parallelsime ordentligt. Men, selvom det ikke er grund til, at kunne specificere parallelisme, er det nødvendigt at kunne bruge de strukturer som findes indenfor den parallele verden, f.eks. køer/fifoer mellem de parallele dele. På overordnete niveau, kan man tillade flere programmer at bruge samme filer, efter de normale låseprincipper, og dette giver i princippet mulighed for at se, i hvilken rækkefølge softwaren arbejder (det er altså tilfældigt, eller ikke deterministisk). Derfor, er det kun lovligt, hvis det er deffineret at der tillades det pågældende på top niveauet. Det kan f.eks. være lovligt, at to computere skal have adgang til samme fil, og i princippet kan softwaren her udføre noget tilfældigt, men det er deffieret som funktionen. Hvis der ikke kræves fleres adgang til delte filer, kan man sagtens undgå tilfældigheder.

Et rigtigt sprog, som fungerer efter ovenstående principper, kan også bruges til ikke realtids opgaver, med stor gevindst. Du kan prioritere f.eks. outputs, og automatisk vil den udregne hvilke dele af koden, der skal opprioriteres. Dette kan ske dynamisk, under udførsel. Som eksempel, vil du aldrig se en musemarkør der hænger. Det har også mulighed for, at automatisk nedprioritere uendelige løkker. Hvis en løkke har været gennemløbet oftere end andre, er den mere "kedelig", og andre løkker, vil få større prioritet. Så længe, der er noget at lave, som er sjovere, gør den dette. Derfor hænger den ikke i em uendelighed. Den bruger særdeles lidt CPU tid, hvis der er andet at gøre.

Forestil dig Linux kodet i ovenstående sprog. Du deffinerer input og output for harddisk, tastatur, og mus. Hvordan vil opstarten ske, trods programmet "først" opstarter ethernet adapter, herefter opstarter musen, osv. osv. Jo, alt vil blive udført parallelt, og den vil ikke vente i en løkke. Trods programmet skrives i rækkefølge, vil compileren selv abstrahere fra rækkefølgen, fordi den ved, at de pågældende input og outputs er uafhængige. Den vil også kunne se ud fra prioritet, at brugeren gerne vil have et resultat ud på skærmen, ved at skærm som output opprioriteres. Dermed, vil alt, som fører til output, udføres først. Men, tænk, hvis programmet kører nede fra og op, så skærmen slettes først. Så ved den, at alt før dette er ligegyldigt mht. udskrift. Og dermed ikke behøver at blive udført..

Trods du skriver din software i rækkefølge, kan du gøre det på en anden måde, og det bliver langt sjovere.

Helge Svendsen

Hej igen,

Mange gode ideer til et sprog, som ingen endnu har kunnet skrive åbenbart. Jeg synes du burde gå i gang.

I mellemtiden er vi andre nødt til at forholde os til de værktøjer, der er tilgængelige.

Og at kode til et operativ system og forretnings relateret udvikling (eks. i java) er så to forskellige størrelser at jeg nægter at tro du kan løse det i samme sprog.

I hvert fald uhyre in effektivt.

"Specielt det sidste, har jeg set ofte. Og netop det, ønskede jeg at forhindre. Der må ikke være rutiner eller kald, der ikke bliver færdig. Hvis vi venter på et fysisk input (f.eks. tast), er det ikke et problem, for udregning af forsinkelsen fra input til output."

Men de findes af mange årsager og du beskriver utopia. Det er man nødt til at forholde sig til.

"Du har altid magt over andres programmer, for de opfylder nogen specifikationer. Og du anvender disse specifikationer, i dine udregninger. Ingen program, har specifikation som "jeg ved da ikke, om jeg gider at svare"... Et sådan program, må ganske simpelt ikke bruges og ingen vil, eller kan bruge den."

Ikke i denne (rigtige) verden. Måske i teorien og på papiret.

Jeg er ked af at ødelægge dine illusioner :-D

Jens Madsen

"Mange gode ideer til et sprog, som ingen endnu har kunnet skrive åbenbart. Jeg synes du burde gå i gang."

Problemet er, at jeg holdes i stupid arbejde, så jeg ikke har tid. Og jeg kan ikke undvære løn.

"Og at kode til et operativ system og forretnings relateret udvikling (eks. i java) er så to forskellige størrelser at jeg nægter at tro du kan løse det i samme sprog."

Nu er Java ikke sproget. Java er simpelt sagt, forbudt.

"Ikke i denne (rigtige) verden. Måske i teorien og på papiret.

Jeg er ked af at ødelægge dine illusioner :-D "

Nogen har samme indvending mod ISO 9001. Men, princippet er det samme. Du må sikre dig bagud kompatibilitet til det eksisterende, men sikre (C++, Java, osv), men sikre at du ikke kan gå modsat vej. Samtidigt, skal du søge at lokke, ved at gøre resultatet bedre, mere optimalt, og sikre. Herefter har du et "ISO 9001 princip", som forpligter - og tvinger. Alle, som leverer til dig, må opfylde de pågældende krav.

Folk går ikke frivilligt. Dem må man slæbe. Og i nogen tilfælde også lokke. Bagefter, må man have systemer, som kollektivt får dem til at presse hinanden til at opfylde systemet.

Log ind eller Opret konto for at kommentere