Programmering er iterasjoner

Utvikling av ikke-trivielle programsystemer, systemløsninger, er en prosess som innebærer handtering av kompleksitet. Det har alltid vært en utvikling og løpende diskusjon om hvordan vi best skal handtere denne kompleksiteten på en metodisk måte som sikrer oss at vi får ut noe som er sikkert og vedlikeholdbart og som produserer det oppdragsgiveren vil ha.

Historisk sett har vi alltid hatt to skoler når det gjelder systemutvikling. Det kan sies mye om dette, men en kortform kan kanskje være slik:

På den ene siden har vi hatt "fossefalls"-metoden som baserer seg på at systemet kan gjennomanalyseres og designes på tegnebrettet, og at programmeringen blir en mer eller mindre mekanisk håndtverksjobb der alle spesifikasjonene er klare. Fordelene med dette er at vi gjøre en komplett analyse og lokaliserer alle de kritiske punktene i en tidlig fase av arbeidet. Ulempene er at verken utviklere eller oppdragsgiver er i stand til å se konsekvensene av krav eller beslutninger.

På den andre siden har vi hatt den iterative skolen som har har som basis at løsningen skal opp og stå fra dag en, og at den raffineres stegvis etter konsultasjon med oppdragsgiver. Fordelene er at vi avdekker designproblemer tidlig og at vi kan tilpasse oss erfaringene. Ulempene er at vi har dårligere kontroll over tidsplan og progresjon.

Det er den siste angrepsvinkelen som ser ut til å dominere programmeringsfagetfaget idag, og det er denne, som slik jeg ser det, er relevant for programmeringsundervisning. Det er de seneste årene utviklet noen tankesett som i aller høyeste grad er relevante.

Når vi sier at en metode er iterativ mener vi at vi definerer delmål og går fram stegvis. En sammenhengende metode som skal ivareta en slik arbeidsform er "Extreme Programming". Til tross for det noe dramatiske navnet er dette en jordnær arbeidsform som bygger på en del lettforståelige og effektive prinsipper. Slik vi ser det er disse prinsippene høyst aktuelle i programmeringsundervisning. De viktigste prinsippene, som vi bør vurdere, er:

• Problemløsning foregår i grupper. Alle i en gruppe har ansvar for løsningen
• Problemløsning foregår i små oversiktlige, veldefinerte steg.
• Testing foregår hyppig og testene er systematiske og planlagt.
• Parprogrammering. Det vil si at det alltid er to personer foran datamaskinen. Den ene skriver og den andre spør, foreslår og kommenterer. Rollene byttes, avhengig av oppgave eller ideer
• De enkelte stegene sjekkes ut mot oppdragsgiver

De momentene som tar opp de sosiale aspektene og de som handler konkret omfeilretting er drøftet for seg. La oss se litt nærmere på iterasjonsperspektivet.

Vi kan se på et enkelt eksempel. Oppdraget er formulert slik:

 Tegn en windmølle

Steg 1

løsning

Tilbakemelding på dette vil typisk være at en windmølle har tre blader, ikke 2

Steg 2

løsning

Tilbakemelding på dette vil kanskje være at møllebladne må jo festes på et hus

Steg 3

løsning

Og så vil vi måtte vurdere om bladene skal ha en annen form og hvordan huset skal utformes. Kanskje vi skal la oss inspirere til å la brukeren bestemme vindstyrken ?

Det er flere ting å merke seg med dette enkle eksempelet.

• Selv et enkelt eksempel som dette demonstrerer at det kan være nødvendig å gå stegvis fram.
• Den som har vært gjennom programmeringsøvelser av denne typen noen ganger vil trolig lære å lage kode som er forberedt for endringer.
• Ambisjonsnivået har en tendens til å øke etterhvert som løsningen utvikler seg. Dette er vel ikke alltid like bra og vi kan fort nærme oss det som er et problem for mange programmerere, et slags perfeksjonistsyndrom. Ting kan alltid bli bedre.
• Presisjonen i oppgaven kunne vært klarere i utgangspuktet, selv om intensjonen trolig var å lansere en enkel øvelse i vinkelberegning.

Hvis vi summerer opp noe av dette så er vi fort over på det som er et kjent problem i iterativ programutvikling, og som på engelsk kalles "the planning game". Essensen i dette er at en slik iteartiv arbeidsform med små steg med egne tidsfrister ofte kommer i konflikt med det som er rimelig eller avtalt som total utviklingstid. Det er åpenbart at dette kan være en vanskelig problemstilling i næringslivet, men det er også verdt å merke seg at denne problemstillingen er relevant også i undervisning.

Det finnes mange metoder innen programmering som er nær beslektet med Extreme Programming, f.eks. Scrum som også har et eksplisitt beskrivelse av kreative faser i arbeidet

Linker

Extreme Programming
Scrum