Peter Naur
Introduktion
Denna diskussion är ett bidrag till förståelsen av vad programmering är. Det föreslår att programmering på rätt sätt bör ses som en aktivitet genom vilken programmerarna formar eller uppnår en viss typ av insikt, en teori, om de aktuella frågorna. Detta förslag står i motsats till vad som förefaller vara en vanligare föreställning, att programmering ska ses som en produktion av ett program och vissa andra texter.
En del av bakgrunden till de åsikter som presenteras här återfinns i vissa observationer av vad som faktiskt händer med program och de team av programmerare som hanterar dem, särskilt i situationer som uppstår från oväntade och kanske felaktiga programkörningar eller reaktioner, och i samband med ändringar av program. Svårigheten att inrymma sådana observationer i en produktionssyn av programmering tyder på att denna syn är missvisande. Teoribyggnadssynen presenteras som ett alternativ.
En mer allmän bakgrund till presentationen är en övertygelse om att det är viktigt att ha en lämplig förståelse för vad programmering är. Om vår förståelse är olämplig kommer vi att missförstå de svårigheter som uppstår i aktiviteten och våra försök att övervinna dem kommer att ge upphov till konflikter och frustrationer.
I denna diskussion kommer först några av de avgörande bakgrundserfarenheterna att beskrivas. Detta följs av en förklaring av en teori om vad programmering är, betecknad ”Theory Building View” (teoribyggnadsvyn ). De efterföljande avsnitten går in på några av konsekvenserna av teoribyggnadssynen.
Programmering och programmerarnas kunskaper
Jag ska använda ordet programmering för att beteckna hela aktiviteten med design och implementering av programmerade lösningar. Det jag är bekymrad över är aktiviteten att matcha någon betydande del och aspekt av en aktivitet i den verkliga världen med den formella symbolmanipulation som kan göras av ett program som körs på en dator. Med en sådan föreställning följer direkt att den programmeringsaktivitet jag talar om måste inkludera den utveckling i tid som motsvarar de förändringar som sker i den verkliga verksamheten som matchas av programexekveringen, med andra ord programmodifieringar.
Ett sätt att uttrycka den huvudsakliga poängen jag vill framhålla är att programmering i denna mening i första hand måste vara programmerarnas uppbyggnad av kunskap av ett visst slag, kunskap som i grund och botten anses vara programmerarnas omedelbara ägo, all dokumentation är en extra, sekundär produkt.
Som bakgrund till det vidare utarbetandet av denna uppfattning som ges i de följande avsnitten kommer resten av detta avsnitt att beskriva några verkliga erfarenheter av att hantera stora program som har förefallit mig mer och mer betydelsefulla när jag har funderat över problemen. I båda fallen är upplevelsen min egen eller har kommunicerats till mig av personer som har förstahandskontakt med aktiviteten i fråga.
Fall 1 gäller en kompilator.
Den har utvecklats av en grupp A för ett språk L och fungerat mycket bra på dator X. Nu har en annan grupp B i uppgift att skriva en kompilator för ett språk L + M, en blygsam förlängning av L, för dator Y. Grupp B beslutar att kompilatorn för L utvecklad av grupp A ska vara en bra utgångspunkt för deras design, och får ett kontrakt med grupp A att de ska få stöd i form av en full dokumentation, inklusive kommenterade programtexter och mycket ytterligare skriftlig designdiskussion, och även personlig rådgivning. Arrangemanget var effektivt och grupp B lyckades utveckla den kompilator de ville ha. I det aktuella sammanhanget är den väsentliga frågan vikten av den personliga rådgivningen från grupp A i de frågor som gällde hur utvidgningarna M till språket ska implementeras. Under projekteringsfasen lämnade grupp B förslag på hur utbyggnaderna skulle inrymmas och lämnade in dem till grupp A för granskning.
I flera större fall visade det sig att de lösningar som föreslogs av grupp B befanns av grupp A för att inte utnyttja de faciliteter som inte bara var inneboende i strukturen för den befintliga kompilatorn utan diskuterades utförligt i dess dokumentation, och baserades i stället på tillägg till den strukturen i form av patchar som effektivt förstörde dess kraft och enkelhet. Medlemmarna i grupp A kunde upptäcka dessa fall omedelbart och kunde föreslå enkla och effektiva lösningar, helt inramade inom den befintliga strukturen. Detta är ett exempel på hur den fullständiga programtexten och ytterligare dokumentation är otillräcklig för att även för den högmotiverade grupp B förmedla den djupare insikten i designen, den teori som omedelbart är närvarande för medlemmarna i grupp A.
Under åren efter dessa händelser togs kompilatorn som utvecklats av grupp B över av andra programmerare i samma organisation, utan vägledning från grupp A. Information erhållen av en medlem i grupp A om kompilatorn som ett resultat av ytterligare modifiering av den efter cirka 10 år gjorde det klart att i det senare skedet var den ursprungliga kraftfulla strukturen fortfarande synlig, men gjordes helt ineffektiv genom amorfa tillägg av många olika slag. Återigen har alltså programtexten och dess dokumentation visat sig otillräcklig som bärare av några av de viktigaste designidéerna.
Fall 2 gäller installation och feldiagnostik av ett stort realtidssystem för övervakning av industriell produktionsverksamhet
Systemet marknadsförs av sin tillverkare, varje leverans av systemet anpassas individuellt till sin specifika miljö av sensorer och displayenheter. Storleken på programmet som levereras i varje installation är i storleksordningen 200 000 rader. Den relevanta erfarenheten från hur denna typ av system hanteras gäller rollen och arbetssättet för gruppen av installations- och felsökningsprogrammerare. Fakta är för det första att dessa programmerare har varit bekymrade över systemet som en heltidssysselsättning under en period av flera år, från det att systemet var under design.
För det andra, när de diagnostiserar ett fel förlitar sig dessa programmerare nästan uteslutande på sin färdiga kunskap om systemet och den kommenterade programtexten, och kan inte komma på någon form av ytterligare dokumentation som skulle vara användbar för dem. För det tredje stöter andra programmerargrupper som ansvarar för driften av särskilda installationer av systemet, och därmed får dokumentation av systemet och fullständig vägledning om dess användning från producentens personal, regelbundet på svårigheter som efter samråd med tillverkarens installation och felsökningsprogrammerare spåras till otillräcklig förståelse av den befintliga dokumentationen, men som lätt kan lösas av programmerare för installation och felsökning.
Slutsatsen verkar oundviklig att åtminstone med vissa typer av stora program, den fortsatta anpassningen, modifieringen och korrigeringen av fel i dem, i huvudsak är beroende av en viss typ av kunskap som en grupp programmerare som är nära och kontinuerligt kopplade till dem besitter.
Ryles teori om teori
Om det medges att programmering måste innebära, som den väsentliga delen, en uppbyggnad av programmerarnas kunskap, är nästa fråga att karakterisera den kunskapen närmare. Det som kommer att övervägas här är förslaget att programmerarnas kunskaper korrekt bör betraktas som en teori, i Ryle [1949] betydelsen. Mycket kortfattat, en person som har eller besitter en teori i denna mening vet hur man gör vissa saker och kan dessutom stödja själva agerandet med förklaringar, motiveringar och svar på frågor om den oroande aktiviteten. Det kan noteras att Ryles teoriuppfattning framstår som ett exempel på vad K. Popper [Popper, och Eccles, 1977] kallar unebodied World 3-objekt och därmed har en försvarbar filosofisk ställning. I detta avsnitt ska vi beskriva Ryles teoriuppfattning mer i detalj.
Ryle [1949] utvecklar sin teoriuppfattning som en del av sin analys av den intellektuella aktivitetens natur, särskilt det sätt på vilket intellektuell aktivitet skiljer sig från och går bortom aktivitet som bara är intelligent. I intelligent beteende visar personen inte någon speciell kunskap om fakta, utan förmågan att göra vissa saker, som att framföra och uppskatta skämt, att prata grammatiskt eller att fiska. Närmare bestämt kännetecknas den intelligenta prestationen delvis av att personen gör dem väl, enligt vissa kriterier, men visar vidare personens förmåga att tillämpa kriterierna för att upptäcka och korrigera brister, för att lära av andras exempel, och så vidare. Det kan noteras att denna uppfattning om intelligens inte förlitar sig på någon föreställning om att det intelligenta beteendet beror på att personen följer regler, recept eller metoder. Tvärtom, själva handlingen att följa regler kan göras mer eller mindre intelligent; om utövandet av intelligens berodde på att följa regler skulle det behöva finnas regler om hur man följer regler, och om hur man följer reglerna om att följa regler etc. i en oändlig regress, vilket är absurt.
Det som kännetecknar intellektuell aktivitet, utöver aktivitet som bara är intelligent, är att personen bygger och har en teori, där teori förstås som den kunskap en person måste ha för att inte bara göra vissa saker intelligent utan också förklara dem, för att svara på frågor om dem, att argumentera om dem och så vidare. En person som har en teori är beredd att ge sig in i sådan verksamhet; medan man bygger teorin försöker personen få till den.
Begreppet teori i den mening som används här gäller inte bara för de genomarbetade konstruktionerna av specialiserade undersökningsområden, utan likaväl för aktiviteter som varje person som har fått utbildning kommer att delta i vid vissa tillfällen. Även ganska oambitiösa aktiviteter i vardagen kan ge upphov till folks teoretiseringar, till exempel när det gäller att planera hur man ska placera möbler eller hur man tar sig till någon plats med hjälp av vissa transportmedel.
Den teori som används här är uttryckligen inte begränsad till vad som kan kallas den mest allmänna eller abstrakta delen av insikten. Till exempel, för att ha Newtons teori om mekanik som den förstås här räcker det inte att förstå de centrala lagarna, som att kraft är lika med massa gånger acceleration. Dessutom, som beskrivs mer i detalj av Kuhn [1970, sid. 187ff] måste den som har teorin ha en förståelse för hur de centrala lagarna gäller för vissa aspekter av verkligheten, för att kunna känna igen och tillämpa teorin på andra liknande aspekter. En person som har Newtons teori om mekanik måste alltså förstå hur den tillämpas på pendlars och planeternas rörelser, och måste kunna känna igen liknande fenomen i världen, för att kunna använda teorins matematiskt uttryckta regler på rätt sätt.
En teoris beroende av ett grepp om vissa slags likheter mellan situationer och händelser i den verkliga världen ger anledningen till att kunskapen hos någon som har teorin i princip inte kan uttryckas i termer av regler. I själva verket är likheterna i fråga inte, och kan inte uttryckas i termer av kriterier, inte mer än att likheterna mellan många andra typer av föremål, såsom mänskliga ansikten, melodier eller smaker av vin, kan uttryckas på så sätt.
Teorin som ska byggas av programmeraren
När det gäller Ryles teoriuppfattning, är det som måste byggas av programmeraren en teori om hur vissa angelägenheter i världen kommer att hanteras av, eller stöds av, ett datorprogram. På teoribyggnadens syn på programmering har teorin som byggts av programmerarna företräde framför sådana andra produkter som programtexter, användardokumentation och ytterligare dokumentation såsom specifikationer.
När man argumenterar för teoribyggnadssynen är den grundläggande frågan att visa hur kunskapen som programmeraren besitter i kraft av att han eller hon har teorin, nödvändigtvis och på ett väsentligt sätt överskrider det som finns registrerat i de dokumenterade produkterna. Svaren på denna fråga är att programmerarens kunskap överskrider den som ges i dokumentationen på minst tre väsentliga områden:
1) Programmeraren som har teorin om programmet kan förklara hur lösningen förhåller sig till de angelägenheter i världen som den hjälper till att hantera. En sådan förklaring måste handla om det sätt på vilket världens angelägenheter, både i sina övergripande egenskaper och deras detaljer, i någon mening kartläggs i programtexten och i eventuell ytterligare dokumentation. Således måste programmeraren kunna förklara, för varje del av programtexten och för var och en av dess övergripande strukturella egenskaper, vilken aspekt eller aktivitet av världen som matchas av den. Omvänt, för varje aspekt eller aktivitet av världen kan programmeraren ange sitt sätt att kartlägga i programtexten. Den överlägset största delen av världsaspekterna och aktiviteterna kommer givetvis att ligga utanför programtextens ram, vara irrelevant i sammanhanget. Beslutet att en del av världen är relevant kan dock bara tas av någon som förstår hela världen. Denna förståelse måste bidras av programmeraren.
2) Programmeraren som har teorin om programmet kan förklara varför varje del av programmet är vad den är, med andra ord kan stödja själva programtexten med en motivering av något slag. Den slutliga grunden för motiveringen är och måste alltid förbli programmerarens direkta, intuitiva kunskap eller uppskattning. Detta gäller även när motiveringen använder sig av resonemang, kanske med tillämpning av designregler, kvantitativa uppskattningar, jämförelser med alternativ och liknande, med poängen att valet av principer och regler, och beslutet att de är relevanta för situationen måste återigen i slutändan förbli en fråga om programmerarens direkta kunskap.
3) Programmeraren som har teorin om programmet kan svara konstruktivt på alla krav på en modifiering av programmet för att stödja världens angelägenheter på ett nytt sätt. Att utforma hur en modifiering bäst införlivas i ett etablerat program beror på uppfattningen om likheten mellan den nya efterfrågan och de operativa faciliteter som redan är inbyggda i programmet. Den typ av likhet som måste uppfattas är en mellan aspekter av världen. Det är bara vettigt för agenten som har kunskap om världen, det vill säga för programmeraren, och kan inte reduceras till någon begränsad uppsättning kriterier eller regler, av skäl liknande de som anges ovan varför motiveringen av programmet inte kan vara så nedsatt.
Medan diskussionen av detta avsnitt presenterar några grundläggande argument för att anta teoribyggnadssynen för programmering, bör en bedömning av synen ta hänsyn till i vilken utsträckning den kan bidra till en sammanhängande förståelse av programmering och dess problem. Sådana frågor kommer att diskuteras i följande avsnitt.
Problem och kostnader för programändringar
Ett framträdande skäl för att föreslå teoribyggnadssynen för programmering är önskan att skapa en insikt i programmering som är lämplig för att stödja en god förståelse av programmodifieringar. Denna fråga kommer därför att vara den första som tas upp för analys.
En sak verkar vara överens av alla, att programvaran kommer att modifieras. Det är undantagslöst så att ett program, när det väl är i drift, kommer att upplevas som bara en del av svaret på problemen. Även själva användningen av själva programmet kommer att inspirera idéer till ytterligare användbara tjänster som programmet borde tillhandahålla. Därav behovet av sätt att hantera ändringar.
Frågan om programändringar är nära knuten till frågan om programkostnader. Inför ett behov av ett förändrat arbetssätt för programmet hoppas man uppnå en kostnadsbesparing genom att göra modifieringar av en befintlig programtext, snarare än genom att skriva ett helt nytt program.
Förväntningen att programändringar till låg kostnad ska vara möjliga är en som kräver en närmare analys. Först bör det noteras att en sådan förväntning inte kan stödjas i analogi med modifieringar av andra komplicerade konstgjorda konstruktioner. Där förändringar då och då genomförs, till exempel när det gäller byggnader, är de välkända för att vara dyra och i själva verket anses en fullständig rivning av den befintliga byggnaden följt av nybyggnation ofta vara att föredra ekonomiskt. För det andra kan förväntningarna på möjligheten till billiga programmodifieringar tänkbart finna stöd i det faktum att ett program är en text som hålls i ett medium som möjliggör enkel redigering. För att detta stöd ska vara giltigt måste det tydligt antas att den dominerande kostnaden är en textmanipulation. Detta skulle stämma överens med en uppfattning om programmering som textproduktion. För teoribyggnadsvyn är hela detta argument falskt. Denna uppfattning ger inget stöd för en förväntning om att programändringar till låg kostnad i allmänhet är möjliga.
En annan närbesläktad fråga är programmets flexibilitet. Genom att inkludera flexibilitet i ett program bygger vi in i programmet vissa operativa faciliteter som inte omedelbart efterfrågas, men som sannolikt kommer att visa sig vara användbara. Således kan ett flexibelt program hantera vissa klasser av förändringar av yttre omständigheter utan att modifieras.
Det sägs ofta att program bör utformas så att de innehåller mycket flexibilitet, så att de lätt kan anpassas till förändrade omständigheter. Sådana råd kan vara rimliga när det gäller flexibilitet som lätt kan uppnås. Flexibilitet kan dock i allmänhet endast uppnås till en betydande kostnad. Varje del av den måste utformas, inklusive vilka omständigheter den måste täcka och med vilken typ av parametrar den ska kontrolleras. Sedan måste det implementeras, testas och beskrivas. Denna kostnad uppstår för att uppnå en programfunktion vars användbarhet helt beror på framtida händelser. Det måste vara uppenbart att inbyggd programflexibilitet inte är något svar på det allmänna kravet på att anpassa programmen till de förändrade omständigheterna i världen.
I en programmodifiering måste en befintlig programmerad lösning ändras för att tillgodose en förändring i den verkliga aktiviteten som den måste matcha. Vad som krävs i en modifiering är först och främst en konfrontation av den befintliga lösningen med de krav som den önskade modifieringen kräver. I denna konfrontation måste graden och typen av likhet mellan förmågan hos den befintliga lösningen och de nya kraven fastställas. Detta behov av en bestämning av likhet lyfter fram fördelen med teoribyggnadssynen. I själva verket blir bristen i varje syn på programmering som ignorerar det centrala kravet på direkt deltagande av personer som besitter den lämpliga insikten uppenbar just vid fastställande av likhet. Poängen är att den typ av likhet som måste erkännas är tillgänglig för de människor som besitter programmets teori, fastän helt utanför räckhåll för vad som kan bestämmas av regler, eftersom inte ens kriterierna för att bedöma det kan formuleras. Från insikten om likheten mellan de nya kraven och de som redan är uppfyllda av programmet, kan programmeraren utforma ändringen av programtexten som behövs för att implementera modifieringen.
I en viss mening kan det inte vara fråga om en teorimodifikation, bara om en programmodifiering. I själva verket måste en person som har teorin redan vara beredd att svara på den typ av frågor och krav som kan ge upphov till programändringar. Denna observation leder till den viktiga slutsatsen att problemen med programmodifiering uppstår genom att man agerar utifrån antagandet att programmering består av programtextproduktion, istället för att erkänna programmering som en aktivitet för teoribyggande.
Med utgångspunkt från teoribyggnaden blir det förståeligt att en programtext förfaller som ett resultat av ändringar gjorda av programmerare utan att ha ett ordentligt grepp om den underliggande teorin. I själva verket, om den ses bara som en förändring av programtexten och av det externa beteendet för exekveringen, kan en given önskad modifiering vanligtvis realiseras på många olika sätt, alla korrekta. Samtidigt, om de ses i relation till programmets teori, kan dessa sätt se väldigt olika ut, vissa av dem kanske överensstämmer med den teorin eller utvidgar den på ett naturligt sätt, medan andra kan vara helt oförenliga med den teorin, kanske karaktären av ointegrerade patchar på huvuddelen av programmet.
Denna karaktärsskillnad för olika förändringar är en som bara kan vara meningsfull för programmeraren som besitter programmets teori. Samtidigt är karaktären hos ändringar som görs i en programtext avgörande för programmets långsiktiga livskraft. För att ett program ska behålla sin kvalitet är det obligatoriskt att varje modifiering är fast förankrad i teorin om den. I själva verket kan själva begreppet kvaliteter som enkelhet och god struktur bara förstås utifrån programmets teori, eftersom de karaktäriserar den faktiska programtexten i förhållande till sådana programtexter som kan ha skrivits för att uppnå samma exekveringsbeteende , men som endast existerar som möjligheter i programmerarens förståelse.
Programs liv, död och väckelse
Ett huvudpåstående från teoribyggnadens syn på programmering är att en väsentlig del av alla program, teorin om det, är något som inte kan tänkas uttryckas, men är oupplösligt bundet till människor. Av detta följer att när man beskriver programmets tillstånd är det viktigt att ange i vilken utsträckning programmerare som har dess teori förblir ansvarig för det. Som ett sätt att betona denna omständighet kan man utvidga begreppet programbyggande med föreställningar om programliv, död och väckelse. Byggandet av programmet är detsamma som uppbyggnaden av teorin om det av och i teamet av programmerare. Under programmets liv förblir ett programmerarteam som har sin teori aktiv kontroll över programmet, och i synnerhet behåller kontrollen över alla modifieringar. Ett programs död inträffar när programmerarteamet som har dess teori upplöses. Ett dött program kan fortsätta att användas för exekvering i en dator och för att ge användbara resultat. Det faktiska dödstillståndet blir synligt när krav på modifieringar av programmet inte kan besvaras intelligent. Återupplivande av ett program är återuppbyggnaden av dess teori av ett nytt programmerarteam.
Den förlängda livslängden för ett program enligt dessa föreställningar beror på att nya generationer av programmerare tar över programmets teori. För att en ny programmerare ska komma att besitta en befintlig teori om ett program räcker det inte med att han eller hon har möjlighet att bekanta sig med programtexten och annan dokumentation. Det som krävs är att den nya programmeraren har möjlighet att arbeta i nära kontakt med de programmerare som redan har teorin, för att kunna bekanta sig med programmets plats i det bredare sammanhanget av relevanta verkliga situationer och för att få kunskap om hur programmet fungerar och hur ovanliga programreaktioner och programändringar hanteras inom programteorin.
Detta problem med utbildning av nya programmerare i en existerande teori om ett program är ganska likt det med utbildningsproblemet för andra aktiviteter där kunskapen om hur man gör vissa saker dominerar över kunskapen om att vissa saker är fallet, som att skriva och spelar ett musikinstrument. Den viktigaste pedagogiska aktiviteten är att studenten gör de relevanta sakerna under lämplig övervakning och vägledning. När det gäller programmering bör aktiviteten inkludera diskussioner om förhållandet mellan programmet och relevanta aspekter och aktiviteter i den verkliga världen, och om gränserna för de verkliga frågor som programmet behandlar.
En mycket viktig konsekvens av teoribyggnadssynen är att programväckelse, det vill säga att återupprätta teorin om ett program enbart från dokumentationen, är strikt omöjligt. För att inte denna konsekvens kan tyckas orimlig kan det noteras att behovet av återupplivande av ett helt dött program förmodligen sällan kommer att uppstå, eftersom det knappast är tänkbart att återupplivandet skulle tilldelas nya programmerare utan åtminstone viss kunskap om teorin som det ursprungliga laget. Trots detta antyder teoribyggnadssynen starkt att programåterupplivning endast bör försökas i exceptionella situationer och med full medvetenhet om att det i bästa fall är kostsamt och kan leda till en återupplivad teori som skiljer sig från den som programförfattarna ursprungligen hade och därför kan innehålla avvikelser med programtexten.
I stället för programåterupplivning, föreslår teoribyggnadsvyn, bör den befintliga programtexten kasseras och det nybildade programmerarteamet bör ges möjlighet att lösa det givna problemet på nytt. En sådan procedur är mer sannolikt att producera ett livskraftigt program än programåterupplivning, och utan till högre, och möjligen lägre, kostnad. Poängen är att att bygga en teori för att passa och stödja en befintlig programtext är en svår, frustrerande och tidskrävande aktivitet. Den nya programmeraren kommer sannolikt att känna sig splittrad mellan lojalitet mot den befintliga programtexten, med vilka oklarheter och svagheter den än kan innehålla, och den nya teorin som han eller hon måste bygga upp och som, på gott och ont, med största sannolikhet kommer att skilja sig åt från den ursprungliga teorin bakom programtexten.
Liknande problem kommer sannolikt att uppstå även när ett program kontinuerligt hålls vid liv av ett utvecklande team av programmerare, som ett resultat av skillnaderna i kompetens och bakgrundserfarenhet hos de individuella programmerarna, särskilt eftersom teamet hålls i drift genom oundvikliga utbyten av enskilda medlemmar.
Metod- och teoribyggnad
De senaste åren har intresset för programmeringsmetoder varit stort. I detta avsnitt kommer några kommentarer att göras om relationen mellan teoribyggnadssynen och föreställningarna bakom programmeringsmetoder.
Till att börja med, vad är en programmeringsmetod? Detta är inte alltid tydligt, inte ens av författare som rekommenderar en viss metod. Här kommer en programmeringsmetod att uppfattas som en uppsättning arbetsregler för programmerare, som talar om vilken typ av saker programmerarna ska göra, i vilken ordning, vilka notationer eller språk som ska användas och vilka typer av dokument som ska produceras i olika skeden.
När man jämför denna uppfattning om metod med teoribyggnadssynen för programmering, är den viktigaste frågan om åtgärder eller operationer och deras ordning. En metod innebär ett påstående om att programutveckling kan och bör fortgå som en sekvens av åtgärder av vissa slag, där varje åtgärd leder till en viss typ av dokumenterat resultat. När man bygger teorin kan det inte finnas någon speciell sekvens av handlingar, av det skälet att en teori som en person innehar har ingen inneboende uppdelning i delar och ingen inneboende ordning. Snarare kommer den som har en teori att kunna producera presentationer av olika slag utifrån den, som svar på frågor eller krav.
När det gäller användningen av speciella typer av notation eller formalisering kan detta återigen bara vara en sekundär fråga eftersom det primära objektet, teorin, inte är och kan inte uttryckas, och därför uppstår ingen fråga om formen för dess uttryck.
Det följer att på teoribyggnadsvyn kan det inte finnas någon rätt metod för programmeringens primära aktivitet.
Denna slutsats kan tyckas strida mot etablerade åsikter, på flera sätt, och kan därför uppfattas som ett argument mot teoribyggnadssynen. Två sådana uppenbara motsägelser ska tas upp här, den första rör betydelsen av metoder i jakten på vetenskap, den andra rör framgången för metoder som faktiskt används i mjukvaruutveckling.
Det första argumentet är att mjukvaruutveckling bör baseras på vetenskapliga sätt, och bör använda procedurer som liknar vetenskapliga metoder. Felet med detta argument är antagandet att det finns något som heter en vetenskaplig metod och att den är till hjälp för forskare. Denna fråga har varit föremål för mycket debatt under de senaste åren, och slutsatsen från sådana författare som Feyerabend [1978], med sina illustrationer från fysikens historia, och Medawar [1982], som hävdar som biolog, är att föreställningen om vetenskaplig metod som en uppsättning riktlinjer för den praktiserande vetenskapsmannen är felaktig.
Denna slutsats motsägs inte av sådant arbete som Polyas [1954, 1957] om problemlösning. Detta arbete hämtar sina illustrationer från matematikområdet och leder till insikter som också är högst relevanta för programmering. Det kan dock inte hävdas att det presenterar en metod för att gå vidare. Det är snarare en samling förslag som syftar till att stimulera problemlösarens mentala aktivitet genom att peka ut olika arbetssätt som kan tillämpas i vilken sekvens som helst.
Det andra argumentet som kan tyckas motsäga avfärdandet av metoden i teoribyggnadssynen är att användningen av särskilda metoder har varit framgångsrik, enligt publicerade rapporter. Till detta argument kan man svara att en metodiskt tillfredsställande studie av programmeringsmetoders effektivitet hittills aldrig verkar ha gjorts. En sådan studie skulle behöva använda den väletablerade tekniken med kontrollerade experiment (jfr [Brooks, 1980] eller [Moher och Schneider, 1982]). Avsaknaden av sådana studier förklaras dels av de höga kostnader som otvivelaktigt skulle uppstå i sådana undersökningar om resultaten skulle bli betydande, dels av problemen att på ett operativt sätt etablera de begrepp som ligger till grund för det som kallas metoder inom programområdet.
De flesta publicerade rapporter om sådana metoder beskriver och rekommenderar bara vissa tekniker och procedurer, utan att fastställa deras användbarhet eller effektivitet på något systematiskt sätt. En genomarbetad studie av fem olika metoder av C. Floyd och flera medarbetare [Floyd, 1984] drar slutsatsen att föreställningen om metoder som regelsystem som i ett godtyckligt sammanhang och mekaniskt leder till bra lösningar är en illusion. Det som återstår är effekten av metoder i utbildningen av programmerare.
Denna slutsats är helt förenlig med teoribyggnadssynen för programmering. I själva verket kommer kvaliteten på teorin som byggts av programmeraren utifrån detta synsätt till stor del att bero på programmerarens förtrogenhet med modelllösningar av typiska problem, med tekniker för beskrivning och verifiering och med principer för att strukturera system som består av många delar i komplicerade interaktioner. Många av metodernas problem är därför relevanta för teoribyggande. Där teoribyggnadssynen avviker från metodologernas är frågan om vilka tekniker som ska användas och i vilken ordning. På teoribyggnadsvyn måste detta förbli en fråga för programmeraren att avgöra, med hänsyn till det faktiska problemet som ska lösas.
Programmerares status och teoribyggnadssynen
De områden där konsekvenserna av teoribyggnadssynen står i kontrast till de mer utbredda nuvarande åsikterna är programmerarnas personliga bidrag till aktiviteten och programmerarnas rätta status.
Kontrasten mellan teoribyggnadssynen och den mer utbredda synen på programmerarnas personliga bidrag är uppenbar i mycket av den vanliga diskussionen om programmering. Som bara ett exempel, betrakta studien av modifierbarhet av stora mjukvarusystem av Oskarsson [1982]. Denna studie ger omfattande information om ett stort antal modifieringar i en version av ett stort kommersiellt system. Beskrivningen täcker bakgrunden, innehållet och genomförandet av varje ändring, med särskild uppmärksamhet på det sätt på vilket programändringarna är begränsade till särskilda programmoduler.
Det finns dock inga som helst antydningar om att implementeringen av ändringarna kan bero på bakgrunden hos de 500 programmerare som är anställda i projektet, såsom hur länge de har arbetat med det, och det finns ingen indikation på hur designbesluten är fördelade på de 500 programmerarna. Ändå erkänns betydelsen av en underliggande teori indirekt i uttalanden som att ”besluten genomfördes i fel block” och i en hänvisning till ”en filosofi om AXE”. Men genom det sätt på vilket studien genomförs kan dessa antagningar endast förbli isolerade indikationer.
Mer allmänt tycks många aktuella diskussioner om programmering anta att programmering liknar industriell produktion, där programmeraren betraktas som en komponent i den produktionen, en komponent som måste styras av procedurregler och som lätt kan ersättas. En annan relaterad syn är att människor presterar bäst om de agerar som maskiner, genom att följa regler, med påföljande betoning på formella uttryckssätt, som gör det möjligt att formulera vissa argument i termer av regler för formell manipulation. Sådana åsikter stämmer väl överens med uppfattningen, till synes vanlig bland personer som arbetar med datorer, att det mänskliga sinnet fungerar som en dator. På nivån för industriell ledning stödjer dessa synpunkter att behandla programmerare som arbetare med ganska lågt ansvar och endast kort utbildning.
I teoribyggnadsvyn är det primära resultatet av programmeringsaktiviteten teorin som innehas av programmerarna. Eftersom denna teori till sin natur är en del av varje programmerares mentala besittning, följer det att föreställningen om programmeraren som en lätt utbytbar komponent i programproduktionsaktiviteten måste överges. Istället måste programmeraren ses som en ansvarig utvecklare och chef för den verksamhet som datorn är en del av. För att tillsätta denna tjänst måste han eller hon ges en fast anställning, med en status som liknar den för andra yrkesverksamma, såsom ingenjörer och advokater, vars aktiva insatser som arbetsgivare för företag vilar på deras intellektuella skicklighet.
Den höjning av programmerares status som föreslås av teoribyggnadsvyn måste stödjas av en motsvarande omorientering av programmerarutbildningen. Även om färdigheter som behärskning av notationer, datarepresentationer och dataprocesser fortfarande är viktiga, måste den primära tonvikten vändas i riktning mot att främja förståelsen och talangen för teoribildning. I vilken utsträckning detta överhuvudtaget går att lära ut måste förbli en öppen fråga. Det mest hoppfulla tillvägagångssättet skulle vara att få eleven att arbeta med konkreta problem under handledning, i en aktiv och konstruktiv miljö.
Slutsatser
Genom att acceptera programmodifieringar som krävs av förändrade yttre omständigheter för att vara en väsentlig del av programmering, hävdas det att det primära syftet med programmering är att få programmerarna att bygga en teori om hur de aktuella frågorna kan stödjas av exekveringen av ett program. En sådan syn leder till en föreställning om programliv som är beroende av programmets fortsatta stöd från programmerare som har dess teori. Vidare, utifrån detta synsätt, är begreppet en programmeringsmetod, tolkad som en uppsättning procedurer som ska följas av programmeraren, baserad på ogiltiga antaganden och måste därför förkastas. Som ytterligare konsekvenser av synen måste programmerare tilldelas status som ansvariga, permanenta utvecklare och chefer för den verksamhet som datorn är en del av, och deras utbildning måste betona utövandet av teoriuppbyggnad, sida vid sida med förvärvet kunskap om databehandling och notationer.
Referenser
Brooks, R. E. Studying programmer behaviour experimentally. Comm. ACM 23(4): 207–213, 1980.
Feyerabend, P. Against Method. London, Verso Editions, 1978; ISBN: 86091–700–2.
Floyd, C. Eine Untersuchung von Software–Entwicklungs–Methoden. Pp. 248–274 in Programmierumgebungen und Compiler, ed H. Morgenbrod and W. Sammer, Tagung I/1984 des German Chapter of the ACM, Stuttgart, Teubner Verlag, 1984; ISBN: 3–519–02437–3.
Kuhn, T.S. The Structure of Scientific Revolutions, Second Edition. Chicago, University of Chicago Press, 1970; ISBN: 0–226–45803–2.
Medawar, P. Pluto’s Republic. Oxford, University Press, 1982: ISBN: 0–19–217726–5.
Moher, T., and Schneider, G. M. Methodology and experimental research in software engineering, Int. J. Man–Mach. Stud. 16: 65–87, 1. Jan. 1982.
Oskarsson, Ö Mechanisms of modifiability in large software systems Linköping Studies in Science and Technology, Dissertations, no. 77, Linköping, 1982; ISBN: 91–7372–527–7.
Polya, G. How To Solve It . New York, Doubleday Anchor Book, 1957.
Polya, G. Mathematics and Plausible Reasoning. New Jersey, Princeton University Press, 1954.
Popper, K. R., and Eccles, J. C. The Self and Its Brain. London, Routledge and Kegan Paul, 1977.
Ryle, G. The Concept of Mind. Harmondsworth, England, Penguin, 1963, first published 1949. Applying ”Theory Building”