5. Paradokser indenfor softwareudvikling

At man overhovedet kan tale om systemudvikling i teorien og i virkeligheden, antyder, at der må være et antal paradokser i den nuværende teoridannelse omkring systemudvikling.

5.1 Forholdet mellem praksis og teori

Teoridannelsen omkring systemudvikling er især præget af problemet, hvorvidt udgangspunktet for faget skal være baseret på praksis eller teori.

Hvis man trækker denne modsætning op, kan man sige, at det drejer sig om, hvorvidt systemudvikling som det ene yderpunkt skal opfattes som en naturvidenskabelig disciplin forankret i matematikkens teoretiske verden, eller som det andet yderpunkt skal opfattes som en kreativ eller kunstnerisk disciplin forankret i håndværkets praktiske verden.

At paradokset er reelt, afspejler sig bl.a. i titlerne på nogle af fagets lærebøger, f.eks. "The Science of Programming" eller "The Art of Programming".

Det matematisk/teoretiske yderpunkt bygger på en vision af Dijkstra, som i slutningen af 1960'erne beskrev, hvorledes han drømte om, at det en dag ville være muligt at skrive programmer på en sådan måde, at deres korrekthed ville kunne bevises. [s. 55]

Siden er det formelle programbevis opstået som et datalogisk begreb forankret i den samme matematiske filosofi, som lå bag Russells og Whiteheads drøm om at skabe en bevisførelse for teorier gennem et antal aksiomatiske grundsætninger og logiske relationer mellem disse. [s. 14]

Det kreativt/praktiske yderpunkt kan illustreres med et citat fra bogen "Professionel systemudvikling": "Kendskab til metoder og teorier kan aldrig erstatte erfaring. Men for den erfarne praktiker kan nye metoder tilføre ideer og muligheder, og teorier kan være en hjælp til at forstå og bearbejde egne erfaringer." ["Professionel systemudvikling" s. 42]

"Et er teori og noget andet praksis. I systemudvikling er det praksis, der tæller." ["Professionel systemudvikling" s. 66]

Bjarne Stroustrup siger det lidt anderledes: "Intelligens, erfaring og personligt præg kan ikke erstattes af noget." [s. 73]

5.2 Totalt overblik som forudsætning

Et af målene for den strukturerede analyse er, at man forpligter sig til at skaffe al viden om et system, inden design og programmering påbegyndes, og at man forpligter sig til at dokumentere denne viden. [s. 56]

Man erkender, at denne indsamling og dokumentation af viden tager lang tid. Men i virkeligheden bør man også spørge sig selv, om det overhovedet kan lade sig gøre. Mange systemudviklere giver direkte eller indirekte udtryk for, at de ikke tror på det.

I "Professionel systemudvikling" beskrives et lignende paradoks i relation til systemudvikling. Paradokset består i, at der findes den opfattelse, at der eksisterer fælles, klare mål for et systemudviklingsprojekt.

I virkeligheden starter man projektet uden at have klart definerede mål. Det hænger bl.a. sammen med, at kompleksiteten af problemstillingen kan være af en sådan art, at eksperimenter er nødvendige for at opnå en tilstrækkelig forståelse. [s. 82]

Grady Booch beskriver det samme i forbindelse med omtalen af metoden "Round-trip gestalt design": "De fleste systemer er helt unikke, og systemudviklerens erfaringsgrundlag vil defor ofte være stærkt begrænset. I sådanne situationer kan man ikke gøre andet end at tage en chance med et foreløbigt design, hvorefter man analyserer resultatet." [s. 72]

Bjarne Stroustrup gør opmærksom på, at ved begyndelsen af et større udviklingsprojekt ved man ikke præcist, hvad systemet skal kunne. Detaljerne vedrørende systemet bliver først afklaret i forbindelse med udarbejdelsen af systemet.

Men da man er nødt til at have en eller anden form for rettesnor, for at kunne identificere, hvilke designbeslutninger der er væsentlige, og for at kunne vurdere konsekvenserne af disse beslutninger, må man udføre nogle eksperimenter. [s. 75]

5.3 Muligheden af at bevise ethvert logisk udsagn

Man kan roligt sige, at det kan være en chokerende oplevelse for en systemudvikler og mangeårig underviser i systemudvikling at blive præsenteret for de forskellige filosofiske opfattelser og filosofiske problemer.

Et af disse filosofiske problemer er spørgsmålet, om det er muligt at bevise ethvert logisk udsagn.

Som nævnt tidligere er det formelle programbevis opstået som et datalogisk begreb med udgangspunkt i den matematiske filosofi, som Russell og Whitehead forsøgte at udvikle i begyndelsen af dette århundrede.

Ideen var at skabe grundlaget for en matematisk/logisk bevisførelse for teorier gennem et antal aksiomatiske grundsætninger og logiske relationer mellem disse. [s. 14]

Siden har man ganske vist kunnet vise, at en sådan bevisførelse ikke kan gennemføres; men det forhold har paradoksalt nok tilsyneladende ikke gjort noget større indtryk på mange dataloger, som arbejder videre med realiseringen af drømmen.

Der kan i denne henseende henvises til bogen "The Science of Programming" af David Gries, som er en glimrende eksponent for denne datalogiske retning.

Det var matematikeren Kurt Gödel, der i 1931 ved hjælp af det såkaldte løgnerparadoks viste, at der findes logiske udsagn, som er sande, uden at man kan bevise sandheden af dem.

Konsekvensen af Gödels arbejde er, at man aldrig vil kunne eliminere den menneskelige dømmekraft. Mennesket ved ofte intuitivt, at et udsagn er sandt, selv om det måske ikke kan bevises.

I relation til problemløsning og softwareudvikling betyder det, at man aldrig vil kunne automatisere problemløsning og softwareudvikling. Og Dijkstras drøm om at kunne bevise ethvert program ved hjælp af logiske beviser, lader sig ikke realisere.

Funktionel programmering, som er en disciplin afledt af visionen om programbeviset, lader sig følgelig heller ikke realisere i sin yderste konsekvens.

Visionen om at skabe maskiner med kunstig intelligens lader sig heller ikke realisere, hvilket der i øvrigt er flere grunde til, selv om denne ene kunne være tilstrækkelig.

Man skal dog på den anden side ikke underkende værdien af den forskningsindsats, som disse projekter har ført med sig. Der er gjort vigtige opdagelser, som også har haft en positiv indflydelse på problemløsning og softwareudvikling.

Men titlen "The Science of Programming" på en lærebog i programmering er misvisende, da den er udtryk for en vision, som aldrig vil kunne realiseres.

5.4 Markedsmekanismer

Computerbranchen - og dermed også systemudviklingen - styres af markedskræfter, som gennem massive reklamekampagner forsøger at påvirke os til at være optimistiske.

Gennem reklamens indflydelse gøres det også vanskeligt at skelne imellem en idé og dens praktiske realisering. Det giver sig bl.a. udslag i, at markedsføringen forsøger at skabe et billede af, at implementering af nye maskiner, softwarepakker eller systemudviklingsmetoder er helt problemfri.

Enhver der selv har prøvet at installere hardware eller software ved, at det i virkeligheden meget sjældent er problemfrit. Det skyldes vel især den kompleksitet, som findes i ethvert computersystem.

Den optimistiske stemning, der anslås i markedsføringen, får os dog ofte til at glemme at tage skyldigt hensyn til denne kompleksitet.

Markedsføringen lettes ydermere af, at mange systemudviklere føler presset fra softwarekrisen på sig. Man er i en tilstand, hvor man er i desperat nød for enhver form for hjælp. I denne situation kan man let komme til at glemme de dårlige erfaringer, man har med tidligere produkter, som ikke levede op til det, markedsføringen ellers lovede.

I forbindelse med udbredelse af kendskabet til de strukturerede metoder er markedsføringen blevet lettet ved, at der er en klar positiv ladning i ordet struktureret. Noget, der er struktureret, kan næsten pr. definition ikke være dårligt.

Det er paradoksalt, at det primært er markedskræfter og reklamering, der bestemmer hvilke produkter, der vil blive kendte og vidt udbredte, i stedet for at det er de enkelte produkters kvalitet, der tæller.

Ifølge Paul Lindgreen medfører den konstante interesse for ny teknologi, at den fælles viden om systemudvikling begrænses. "Mange falder for det letkøbte og opdager for sent, at man måske burde have tænkt lidt mere - at det måske nok er en løsning, man får, men ikke nødvendigvis på det mest fremherskende problem." [s. 78]

5.5 Dokumentation som kommunikationsmedie

Tor Nørretranders gør i bogen "Mærk verden" opmærksom på det betydelige informationstab, som opstår i forbindelse med nedskrivning og kommunikation af en oplevelse eller

erkendelse.

Det er paradoksalt, at denne iagttagelse - skønt alle intuitivt erkender rigtigheden af den - ikke har fundet vej til de utallige beskrivelser og vejledninger i de forskellige dokumentationsværktøjer, der findes.

Tværtimod anbefales det ofte, at man er omhyggelig og strengt formalistisk i sin værktøjsanvendelse. Herved tvinger man faktisk systemudvikleren til at se bort fra væsentlige dele af det, han ved om det system, der er under udvikling.

Den, der udarbejder dokumentation i en eller anden formalistisk form, er nødsaget til at foretage en udvælgelse af de detaljer, der medtages. Det, der udelades (eksformationen i Tor Nørretranders' terminologi), kommer aldrig til kendskab for den, der senere læser dokumentationen.

Dilemmaet i forbindelse med enhver udvælgelse er, om det medtagne vil forblive relevant, og om det udeladte vil forblive irrelevant.

Booch udtrykte det meget fint: "Det er umuligt at fastholde alle de finere detaljer i et komplekst softwaresystem ved hjælp af en enkelt type diagram." [s. 71]

Booch gør hermed opmærksom på behovet for mange forskellige typer diagrammer til beskrivelse af et system. Desuden har han meget fint bemærket behovet for både at beskrive systemet i ro (det statiske) og under forandring (det dynamiske).

I mange systemudviklingsmodeller er det udelukkende de statiske aspekter ved systemet, man koncentrerer sig om. Herved gør man det særdeles vanskeligt at få det fulde overblik over et system.

Stroustrup har iagttaget det fænomen, at megen dokumentation skabes, fordi en gruppe mennesker skal dele erfaringer, som måske endda er gjort af personer uden for projektgruppen.

Ifølge Stroustrup kræver en sådan deling af erfaringer, at de involverede personer deler en "kultur", som sætter dem i stand til at kommunikere effektivt. I denne kommunikation er det underforståede meget vigtigere end det, der faktisk siges. [s. 74]

Man kan få lyst til at rejse det kætterske spørgsmål, om ikke formaliseret dokumentation i systemudvikling er til større skade end gavn i betragtning af de store ressourcer, der sættes ind for at opbygge den.

Alle systemudviklere laver meget uformel dokumentation i forbindelse med systemudvikling. Heri gemmer sig ofte ideer til løsninger, som af en eller anden grund ikke lader sig realisere.

På grund af den uformelle karakter af denne dokumentation kasseres den ofte. Alle systemudviklere har nok prøvet at ærgre sig over på denne måde at have kastet en værdifuld idé bort, når det senere har vist sig, at ideen måske kunne bruges i en anden sammenhæng.

Det må betegnes som paradoksalt, at systemudviklere bruger enorme ressourcer på opbygningen af en formel dokumentation, som måske aldrig bliver brugt, samtidig med at dokumentation, som man virkelig kunne have stor glæde af, kasseres, fordi den ikke lever op til de formelle standardiserede krav.

I lyset af problemerne med at skaffe den tilstrækkelige båndbredde i såvel sproglig som diagrammatisk dokumentation, burde man måske overveje, om det ikke ville være bedre at optage møder og interviews på video. Optagelserne kunne gemmes i stedet for den traditionelle dokumentation.

Et andet løsningsforslag stammer fra Stroustrup, som gør opmærksom på det skadelige i den organisationsteoretiske myte, at personer i et projekt er at betragte som enheder, der kan skiftes ud med andre enheder, hvis det bliver nødvendigt. Det er en alvorlig misforståelse at tro, at andre hurtigt kan sætte sig ind i forgængernes efterladte dokumentation.

I stedet burde man efter Stroustrups mening skabe rammer om sit projekt, som gør, at de involverede personer bliver i projektet, indtil det er afsluttet. Herved gør man sig faktisk også uafhængig af dokumentation.

5.6 Manglende kendskab til filosofien

Indenfor systemudvikling beskæftiger man sig meget med oversættelse af specifikationer fra ‚n repræsentation til en anden. Det er derfor paradoksalt, at kommende systemudviklere ikke undervises i de mere filosofiske problemer vedrørende oversættelse.

En ofte overset kendsgerning i forbindelse med oversættelser er behovet for kontrol. Det nytter ikke, at man har en maskine eller et program, der kan oversætte en specifikation fra ‚t sprog til et andet, hvis man ikke kan kontrollere rigtigheden af oversættelsen.

Det gælder ikke mindst, når det drejer sig om naturlige sprog, hvor semantikken tillader uendeligt mange fortolkninger af en given sætning.

Det nytter ikke, at man kan nedbryde en sætning i et naturligt sprog til et antal regler, hvis man ikke ud fra disse regler kan genskabe meningen med den oprindelige sætning.

Et eksempel herpå findes indenfor den datalogiske disciplin funktionel programmering. Essensen af denne disciplin er, at man skal opbygge programmer baseret på matematiske funktioner. Gentagelser, som ellers ofte anvendes i programmering, er bandlyste i funktionel programmering. I stedet anvendes rekursion.

Pointen er, at man kan bevise sandheden af løsninger, som er defineret med rekursion, hvilket man ikke kan, hvis løsningen er baseret på gentagelse. Man kan udføre eksperimenter, som kan sandsynliggøre, at løsningen med gentagelser er korrekt; men man kan ikke bevise det.

Problemet med funktionel programmering er, at det er en næsten uoverkommelig opgave for et menneske at specificere rekursive løsninger for dagligdags problemer, som skal programmeres til en computer.

Men det er kun et spørgsmål om tid, lover tilhængerne af funktionel programmering, for en dag vil der eksistere computerprogrammer, som kan omsætte brugerens specifikation af opgaven til matematiske funktioner.

Mange systemudviklere har nok en intuitiv fornemmelse af, at et sådant oversætterprogram næppe kan realiseres; men med kendskab til Gödels kritik af den logiske matematik ville man have vidst, at oversættelse af brugerens specifikation er en opgave med et uendeligt antal mulige udfald.

Det er ikke uden grund, at Gerald Weinberg i "Rethinking Systems Analysis and Design" s. 15 erklærer, at "enhver systemudvikler må være fortrolig med matematik til et niveau, hvor man ikke intimideres af skyer med matematisk tåge."

Herefter kan man vel drage den konklusion, at verden ikke er så enkel og ligetil, som nogle vil gøre den til. Man kan nok reducere verden til nogle få relativt enkle regler og naturlove, når man skal prøve at forstå den; men man kan ikke genskabe verden ud fra disse regler og naturlove.

Det er åbenlyst, at mange af de mest udbredte systemudviklingsmodeller og problemløsningsstrategier er baseret på temmelig ensidige opfattelser af, hvordan menneskelivet er sammensat.

Det er et moralsk og dermed filosofisk problem, når ydmygheden går tabt. I en formalistisk systemudviklingsmodel anerkender man ikke menneskets rolle i processen; men løsningsmodellen beskriver alene fremgangsmåden: målsætning, opstilling af alternative løsningsforslag, konsekvensvurdering, valg af mest optimale løsning og implementering af denne.

Det, man kan lære af filosofien, er altså først og fremmest at tilføre sit arbejde en ny moralsk dimension, hvor man tillige accepterer, at man må finde en passende balance mellem rationalisme og empiri og mellem idealisme og realitet.

Det andet, man kan lære af filosofien, er, at der er en mangfoldighed af opfattelser af, hvad der er sandheden. Man må derfor kende noget til historien bag de enkelte opfattelser, før man vælger sig sit eget ståsted.

Vi er ikke i tvivl om, at kendskab til filosofiske problemer vil være af langt større betydning for en systemudvikler end kendskab til f.eks. matematik.

5.7 Manglende problemløsningsværktøj

Som nævnt i forbindelse med omtalen af dokumentation som kommunikationsmedie laver alle systemudviklere en mængde uformel dokumentation i forbindelse med systemudvikling. Det er især i den del af systemudviklingen, som er karakteriseret ved megen problemløsning, at der fremstilles store mængder skitser af visioner og ideer, som man ønsker at afprøve.

Afprøvning sker på den indre scene, hvis problemet er nogenlunde overskueligt. Ellers må man, som Stroustrup siger, ty til at udføre eksperimenter. [s. 75]

På grund af den uformelle karakter af denne dokumentation kasseres den ofte, selvom man ofte oplever, at det netop er denne dokumentation, der på langt sigt er relevant.

Det er paradoksalt, at der ikke findes anvisninger til systemudviklere og problemløsere i teknikker til udvikling og fastholdelse af ideer og løsningsforslag. De anvisninger, der findes, foreskriver, at man bruger værktøjer, der må karakteriseres som dokumentationsværktøjer.

Men et dokumentationsværktøj er ikke et problemløsningsværktøj. Det vil alle erfarne systemudviklere nok erkende.

Fra vor egen hverdag som undervisere i bl.a. problemløsning kender vi problemet. Vi føler med de studerende, for det må være en frustrerende oplevelse at skulle lære at løse problemer, når man opdager, at de hjælpeværktøjer, man skal løse problemet med, ikke egner sig for problemløsning.

Den studerende er i denne situation overladt til sig selv og de evner for problemløsning, som vedkommende havde med sig, da undervisningen begyndte. Der er dem, der mener, at disse evner er medfødte; men vi vil påstå, at det kan man ikke vide, før man har prøvet at give reel undervisning i problemløsning i stedet for undervisning i dokumentation.

Undertiden vil læreren prøve at tvinge den studerende til at gøre det "rigtigt". Læreren foreskriver, at der skal fremstilles et moduldiagram eller en algoritmeskabelon, før man laver det tilhørende program.

Men den studerende kan ikke løse problemet ved hjælp af de anviste dokumentationsteknikker, og må derfor ty til den udvej på en eller anden måde at fremstille et program, som løser opgaven. Når programmet virker, fremstiller man så den krævede dokumentation.

Det kunne være interessant at se, om systemudviklere kunne blive bedre problemløsere og dermed bidrage til løsningen af softwarekrisen, hvis de fik undervisning i problemløsningsteknik i stedet for i dokumentationsteknik.

5.8 Intelligensens betydning for systemudvikling

Når man har kendskab til teorien om de 7 intelligensmoduler fra kognitionspsykologien, kan man ikke lade være med at tænke på, hvordan det forholder sig med forskellige menneskers intelligens indenfor de forskellige områder.

Desværre er vort samfund og vor dagligdag stærkt præget af det verbale sprog og det logisk-matematiske. Det er derfor heller ikke overraskende, at man ofte betegner mennesker med en høj intelligens indenfor netop disse felter, for intelligente. Modulteorierne tvinger os dog til at acceptere, at der findes andre former for intelligens.

Det, man kan håbe på, er, at accepten af andre former for intelligent adfærd kan stimulere en udvikling henimod en inddragelse og udnyttelse af andre intelligensformer i flere af menneskelivets situationer.

Mange af de alternative intelligensformer udnyttes allerede i vid udstrækning af mange mennesker; men i mange tilfælde på en helt ubevidst måde.

Det kunne være interessant at se effekten på undervisningen i systemudvikling, hvis man prøvede at stimulere og aktivere de studerendes anvendelse af andre intelligenser end hovedsagelig det verbale sprog og det logisk-matematiske.

Der findes en del af litteratur, hvor man har prøvet at kortlægge kendte menneskers intelligenser. Således antages det, at Niels Bohr udover en høj intelligens for det logisk-matematiske må have haft en høj intelligens for det rumlige. Ellers kunne han ikke have forestillet sig opbygningen af molekyler på sin indre scene.

En dygtig fodboldspiller som f.eks. Brian Laudrup må have en høj intelligens for det kropsligt-kinæstetiske for at kunne udføre spillets tekniske detaljer perfekt; men selve spilopfattelsen og det taktiske element kræver en høj intelligens for det rumlige.

Niels Bohr rummede altså også i sig muligheden for at være en god fodboldspiller. Ikke alle ved, at han faktisk i sine unge dage spillede fodbold på eliteplan i klubben AB.

Vi kender ikke til, at der skulle være gjort forsøg på at kortlægge gode systemudvikleres intelligenser; men noget kunne tyde på, at der kræves temmelig alsidige talenter for at blive en god systemudvikler.

I forbindelse med analyse er indlevelsesevne og evne til at formulere sig skriftligt af stor betydning. Indlevelsesevne kræver høj intelligens for den personlige omverden, men også for det rumlige. Evne til at formulere sig på skrift kræver en høj intelligens for det verbale sprog.

I forbindelse med design er det forestillingsevne og kreativitet, som er af størst betydning. Her må høje intelligenser for det rumlige og det personlige indre være blandt de mest ønskværdige egenskaber.

I forbindelse med realisering er de vigtigste egenskaber præcision og evne til at strukturere. Her er høj intelligens for det matematiske og det rumlige mest relevant.

Vi vil her vove den påstand, at de fleste gode systemudviklere netop er kendetegnet ved, at de er særdeles alsidigt orienterede. Deres intelligens er måske ikke lige høj inden for alle moduler; men deres personligheder er sådan, at de har lyst til at interessere sig for alle emner, der krydser deres vej.

En større bevidsthed hos den enkelte systemudvikler om de muligheder, der kan ligge gemt i de forskellige former for intelligens, kan være afgørende for at fremme de egenskaber, der gør en middelmådig systemudvikler til en god systemudvikler.

Hvis der var flere gode systemudviklere ville det sikkert betyde mere for en afhjælpning af softwarekrisen, end alle de formaliserede systemudviklingsmodeller og metoder, der er blevet udviklet igennem de sidste 25 år.

Mange har gjort den erfaring, at netop den individuelle systemudviklers intelligens og kreativitet er af allerstørste betydning.

En systemudvikler berettede f.eks. om en erfaring, som mange systemudviklere vil have oplevet på tilsvarende måde. Hvis man i en virksomhed er en gruppe systemudviklere, er det mærkeligt nok altid de samme, der kommer med de mest brugbare løsningsforslag.

Efter vor mening er det paradoksalt, at man ikke har forsøgt at løse softwarekrisen ved at finde ud af, hvordan disse få virkeligt gode systemudviklere bærer sig ad.

5.9 Ekspert og generalist

I vore dage findes der mange gange mere nedskreven viden, end det er muligt for et menneske at absorbere i løbet af et helt liv. Men det er ikke mere end 400 år siden, at det faktisk var muligt for en lærd person at sætte sig ind i hovedparten af al den nedskrevne viden i verden.

Med bogtrykkunstens fremkomst blev det muligt at få spredt viden til flere mennesker. Samtidig skete der teknologiske fremskridt, som gjorde det muligt at skaffe mere præcise observationer, som kunne bekræfte eller afkræfte de videnskabelige teorier.

Hermed var der skabt basis for en kraftig forøgelse af den viden, der var tilgængelig i hele verden, og det blev umuligt for en enkelt person at overskue det hele.

Fra den tid stammer opsplitningen af viden i forskellige videnskabelige discipliner. Dette var samtidig begyndelsen til den videnskabelige tradition, som vi kender i dag.

Denne videnskabelige tradition er præget af relativt lange perioder, hvor videnskaben prøver at opstille teorier og forklare disse ud fra det gældende verdensbillede. En af de vigtige videnskabelige discipliner i en sådan rolig periode er at tilbagevise alle forsøg på at rokke ved det bestående verdensbillede.

Først når en række paradoksale forhold i den bestående teoridannelse bliver for overvældende, vil der ske et såkaldt videnskabeligt paradigmeskift, hvor et nyt verdensbillede indsættes i stedet for eller som supplement til det bestående.

Der er stærke kræfter i den videnskabelige tradition, som bevirker, at enhver videnskabelig disciplin bruger mange kræfter på at befæste sin egen status. Loyalitet og trangen til at omgive sig med ligesindede får det for udenforstående til at ligne et broderskab.

Denne trang til at befæste sin egen status og omgive sig med ligesindede er medvirkende til at skabe et paradoksalt modsætningsforhold imellem eksperten på den ene side og generalisten på den anden side.

Man kan karakterisere den normale videnskabelige tradition som den videnskabeligt-fagligt-induktive fremgangsmåde. Denne fremgangsmåde er præget af opdeling i forskellige videnskaber, som igen kan være underopdelt i en række discipliner.

Denne opdeling er fordelagtig, hvis den er begrundet i, at en videnskab er blevet så rig på viden, at den er uoverskuelig for en enkelt person; men det er uheldigt, hvis man forsøger at overføre analyseresultater opnået indenfor et snævert videnskabeligt område til andre områder.

I tilfældet med videnskaben datalogi er det netop, hvad der ofte sker. Analyser udført på meget snævre områder og under laboratorielignende forhold forsøges generaliseret til at skulle gælde alment for systemudvikling.

Det, der er vigtigt for en god systemudvikler, er evnen til at skabe forbindelser mellem specialister indenfor forskellige videnskaber. Systemudvikleren er derfor nødt til at være generalist.

Det værste, der kan ske for en systemudvikler, er, at han bliver snæversynet. Hvis en generalist bliver snæversynet, er han pr. definition ikke længere generalist.

Gode systemudviklere er især kendetegnet ved at være tværfaglige; men hvis det i en given situation kræves, at man er faglig, skal den gode systemudvikler også uden problemer kunne bevæge sig frem og tilbage mellem rollerne som faglig og tværfaglig.

En pudsig men logisk konsekvens heraf er, at det ikke er muligt at blive specialist indenfor systemudvikling. Sådan noget som en systemudviklingsspecialist findes ikke.

Uddannelse af systemudviklere kræver tværfaglighed og kendskab til en stor mangfoldighed af forskellige videnskabelige discipliner. Det er vor opfattelse, at ikke mindst de humanistiske videnskaber trænger til en kraftig rehabilitering i denne henseende.

Det er vor opfattelse, som vi mener at have dokumenteret gennem denne afhandling, at der ligger et betydeligt potentiale gemt i inddragelsen af humanistiske videnskaber på lige fod med de naturvidenskabelige videnskaber.

I denne forbindelse gjorde vi den interessante opdagelse, at denne erkendelse faktisk eksisterede, da metoden Syskon blev publiceret i 1971. [s. 52]

Man kan håbe, at en inddragelse af fag som f.eks. filosofi og antroprologi kan ændre indstillingen blandt systemudviklere. Ydmyghed og respekt for andre mennesker er egenskaber, som er altafgørende for en god systemudvikler.

Ydmyghed og respekt for andre er ikke just, hvad man forventer af en moderne naturvidenskabsmand, som ofte fremstår som den, der hensynsløst udnytter de teknologiske muligheder.

I vor søgen efter filosofiens historie stødte vi på Leibniz, som anses for ophavsmanden til mange af de opfattelser, der har præget især naturvidenskaben lige siden. Men i modsætning til den moderne videnskab var Leibniz ydmyg. Han mente, at den orden, der var til stede i naturen, skyldtes Gud. Hermed mente han ikke blot den kristne Gud, som det er et religiøst spørgsmål, om man tror på. Gud skal snarere opfattes som eksponent for det, der har eksisteret længere end selve Universet.

5.10 Teknologiudvikling som løsning på softwarekrisen

Vi startede denne afhandling med et historisk overblik over en række forskellige forslag til løsning af softwarekrisen. Fælles for disse løsningsforslag er, at de alle er baseret på teknologiudvikling.

Teknologiudviklingen kan f.eks. bestå i udviklingen af hurtigere og billigere maskiner, som kan gøre det muligt at realisere løsningsforslag, som man tidligere har måttet se bort fra, fordi ressourcekravene var for store.

Det er en sådan udvikling, der har ført til lanceringen af fjerde generations værktøjerne og til relanceringen af teknikker som objekt-orienteret systemudvikling og funktionel programmering.

En anden form for teknologiudvikling består i den stadige udvikling og lancering af nye metoder og værktøjer til hjælp i forbindelse med systemudvikling.

Den sidste form for teknologiudvikling, der skal nævnes her, er de såkaldte CASE-værktøjer. CASE betyder Computer Aided Software Engineering, og der er altså tale om software, der kan støtte systemudvikleren under udviklingen af software. Den teknologiske forbedring ligger i, at man har automatiseret anvendelsen af metoder og værktøjer.

Paradokset består i, at den voldsomme og kostbare satsning på de teknologiske løsninger tilsyneladende ikke har kunnet gøre noget mærkbart i retning af en eliminering af softwarekrisen.

En af årsagerne kan være, at der samtidig med lanceringen af de mange teknologiske løsningsforslag er sket en stigning i den kompleksitet, som er indbygget i moderne systemer. Kompleksiteten er endog vokset hurtigere end teknologien har kunnet følge med, så nettoresultatet er en større softwarekrise nu end for 25 år siden.

Faktorer, der uvægerligt vil forøge kompleksiteten, er forsøg på at få computere til at simulere tilsyneladende trivielle funktioner, som mennesket har nemt ved. Disse forsøg er kendt som kunstig intelligens.

At overføre disse funktioner til computere har vist sig at være en ikke-triviel opgave. Man har fejlagtigt troet, at fordi mennesket havde let ved det, ville det også være let for maskinerne. Men man tog fejl.

Blandt andre faktorer, der bidrager til øget kompleksitet, er integration af systemer i større systemerhierakier. Integration vil i mange tilfælde resultere i en mangedobling af kompleksiteten. Resultatet bliver uvægerligt, at man ikke kommer tættere på målet, eliminering af softwarekrisen.

Der synes at være en tendens til, at den effekt, der kunne være i de foreslåede teknologiske løsninger, mere end opsluges af den forøgede kompleksitet.

Selvom de foreslåede teknologiske løsninger ikke har kunnet eliminere softwarekrisen, ville det dog være forkert blot at sige, at de ikke har haft nogen effekt. Enhver metode og ethvert værktøj vil have en eller anden effekt. Men det hjælper blot ikke, når kompleksiteten vokser med en større stigningstakt end værktøjerne kan leve op til.

Softwarekrisen er altså ikke forsvundet; men den ville have været langt værre, hvis der ikke havde været gjort forsøg på at løse krisen ved hjælp af teknologiske fremskridt.

Et af de forhold, der kan være paradoksale i forbindelse med de teknologiske løsningsforslag er, at mange af disse løsninger direkte eller indirekte modarbejder eller udelukker hinanden. Der er altså ikke tale om, at de forskellige teknologier kan supplere hinanden. De erstatter hinanden.

De fleste teknologier er baseret på en modelleret opfattelse af omverdenen. Dette skyldes, at det kan være særdeles praktisk, at arbejde med en begrænset og dermed mindre kompleks model, end med selve virkeligheden.

Der er imidlertid en tendens til, at man overfortolker de modeller, som man udvikler, således at modellerne bliver utroværdige.

I stedet bør man være opmærksom på grænserne for modellens anvendelighed og på muligheden af, at der kan findes et mere generelt princip, som beskriver en større helhed end det specialtilfælde, man i øjeblikket ser på.

Det vil sige, at man skal betragte de kendte teknologier som specialtilfælde. Med disse specialtilfælde som udgangspunkt kan man indlede en søgen efter de generelle principper og teorier, der gemmer sig bag disse.

Når disse generelle principper er dukket op, vil man kunne se de forskellige kendte teknologier som det, de er, nemlig som specialtilfælde, der kan understøtte og supplere hinanden i forskellige sammenhænge.

Det er efter vor mening et paradoks, at vore edb-uddannelser og måske ikke mindst vore holdninger til edb-pædagogik ikke er rettet mod den åbenhed, der er nødvendig, for at kunne iagttage det flerfaglige universelle perspektiv.

5.11 Kunstig intelligens og ægte intelligens

Dette punkt kunne måske også have været et underpunkt til det foregående punkt om teknologiudvikling. Det er nemlig den teknologiske udvikling og den hast, hvormed den forløber, som har inspireret forskere til at profetere, at det kun var et spørgsmål om tid, før der fandtes maskiner med en kunstig intelligens, der var på højde med eller ligefrem bedre end den ægte menneskelige intelligens.

Denne blinde tillid til teknologiens triumf er ikke noget nyt. Teknologiens triumf er nogen gange ved at udvikle sig til dødens triumf. H. C. Andersen beskriver dette særdeles rammende i eventyret "Nattergalen".

Et nutidigt eksempel, kan man finde i avisdebatten i disse dage, hvor det diskuteres, hvem der har skylden for en edb-fejl i omstillingsbordet i lægevagten, som medfører, at man kun kan registrere ventetider på under 10 minutter.

Vi kom til at tænke på det samme i forbindelse med en konference, hvor spørgsmålet om programmers korrekthed blev debatteret. Som argument for at anvende den datalogiske disciplin det formelle programbevis generelt i forbindelse med systemudvikling fremførte en paneldeltager som eksempel, hvor vigtigt det er, at et program til styring af en raket er korrekt. Ellers rammer raketten ikke sit mål.

Vi udviklede i hast det galgenhumoristiske slogan: Brugeren er ham for enden af raketten. Spørgsmålet er bare - hvilken ende?

I forbindelse med kunstig intelligens må man rejse det spørgsmål, om man kan finde ud af hvor man skal hen, hvis man ikke ved, hvor man kommer fra?

Der er ikke ført noget bevis for, at de af forskningen i kunstig intelligens frembragte metoder til at afbilde intelligensfunktioner minder det fjerneste om menneskelig, eller skal vi sige biologisk intelligens. Det er ikke engang sandsynliggjort. Alligevel fremturer man med logikprogrammering og udnævner neurale net som vejen frem.

Det er ikke sandsynliggjort, at den vægtning af ruterne i et neuralt net, som er opnået gennem anvendelse (indlæring!) kan sidestilles med intelligens.

Alligevel lover fortalerne, at der vil ske et gennembrud snart. Man henviser evt. til de kraftigere maskiner eller anvendelse af massiv parallel databehandling - kort sagt: ny teknologi. Således går den fejlslagne argumentation i ring. Og døden får sin triumf.

Indlagt 27. april 1997