Det, der er svært i forbindelse med programudvikling, er at lære at håndtere den enorme abstrakte kompleksitet, som er til stede i den virkelige verdens problemer. Formålet med programudvikling er jo netop at danne computermodeller af systemer fra den virkelige verden.

Hvis man kan få problemet "kogt ned" til en enkelt eller nogle få formler eller matematiske ligninger, har man også løst problemet, fordi man har fået taget kompleksiteten ud af situationen. Desværre er det meget svært at koge den virkelige verdens problemer ned på denne måde.

Traditionelt forsøger man at overskue problemets kompleksitet ved hjælp af forskellige former for abstraktion eller distancering fra problemet. En abstraktion har til formål at fokusere på nogle få centrale aspekter ved en situation, hvorimod man vælger at se bort fra andre.

Hvordan finder man ud af, hvilke aspekter, der er væsentlige i en situation? Og hvilke, der er uvæsentlige?

Svaret er, at denne evne til at skelne imellem væsentligt og uvæsentligt kræver betydelig praktisk erfaring med løsning af konkrete opgaver fra det virkelige liv, hvor den kompleksitet, man skal lære at beherske, netop er til stede. Herved vil man efterhånden blive i stand til ubevidst at skelne det væsentlige fra det uvæsentlige.

Det vigtigste råd man kan give, er aldrig at koble den sunde fornuft fra, når man arbejder med programudvikling. Man får brug for den sunde fornuft, når man skal lave en rationel og kritisk vurdering af de ideer til løsningsforslag, som med erfaringen kommer til én mere eller mindre intuitivt.

Intuition og kreativitet spiller altså en vis rolle; men uden den sunde fornuft bliver man ikke en seriøs professionel udøver af programudvikling.

Den sunde fornuft skal også hjælpe systemudvikleren til at modstå det veritable bombardement, som han konstant er udsat for, og som har til formål at hverve ham som discipel til den ene eller den anden mere eller mindre formalistiske systemudviklingsmodel.

Der har i en årrække været en dyb tillid til, at teoretikerne i den sidste ende nok skulle redde os ud af det morads, som vi står til halsen i indenfor softwareudvikling. I virkeligheden har teoretikerne dog ikke kunnet bidrage med noget, som har haft nogen nævneværdig betydning for systemudviklerens evne til at fremstille softwareløsninger.

Fælles for alle de mange systemkonstruktionsværktøjer, der er blevet foreslået, er, at de netop ikke kan bruges til konstruktion. Konstruktionen laver man altid på en anden måde; men værktøjerne har en vis betydning i forbindelse med dokumentation af løsningen.

Formålet med de følgende anvisninger er at komme ind til kernen af, hvad problemløsning i virkeligheden er for noget, og hvordan vi mennesker kan lære at håndtere de afsindigt komplekse problemstillinger, som vi bliver stillet overfor i professionel programudvikling.

Når man skal lave et teaterstykke eller en spillefilm, udarbejder man en drejebog, som i detaljer beskriver forløbet af hver enkelt scene. Det gør man af flere grunde.

For det første har instruktøren behov for at kunne leve sig ind i situationen i en scene allerede på det tidspunkt, hvor man planlægger scenen. Indlevelsesevne er en uhyre vigtig evne for en systemudvikler, og en evne man får brug for, når man skal prøve at forstå, hvad programspecifikationen eller opgaveformuleringen går ud på.

I den virkelige verden er det normalt programmøren selv, der fremstiller specifikationen; men det fritager ham ikke for behovet for indlevelsesevnen - det vanskelige arbejde med at forstå, hvad der er meningen med opgaven bliver bare flyttet fra programkonstruktion til systemanalysen.

For det andet er der flere mennesker involveret i projektet, og det er vigtigt, at man er i stand til at beskrive sine ideer, så man kan vise dem til andre, når man vil bede dem om deres accept eller kritik.

For det tredie har man også som ophavsmand til ideer det problem, at man ikke kan huske alt. Derfor er det vigtigt, at man får dokumenteret sine ideer, mens man kan huske dem.

Når man skal lave film eller teaterstykker, laver man modeller af kulisser og kostumer. Årsagen hertil er, at det dels kan være meget kostbart at lave en kulisse i fuld skala, og dels, at det giver bedre mulighed for at leve sig ind i scenen, når man ser modellen for sig samtidig med at man hører beskrivelsen.

De følgende punkter er en række anvisninger på nogle ting, man kan gøre, for at få gang i sin kreativitet og indlevelsesevne. På længere sigt er det dog vigtigt, at man finder sin egen stil, så disse punkter må kun opfattes som en foreløbig anvisning. Med øvelsen bliver man i stand til at opstille drejebog og modeller ubevidst og uden anvisninger på, hvordan det skal gøres.

• Beskrivelse af dialogen mellem bruger og program
• Beskrivelse af dialogen mellem program og datastrukturer (herunder især filer)
• Indsæt rigtige data (testdata) i dialogen
• Eventuelle beregningsformler noteres
• Afklaring af, om man har forstået opgaven - der skal måske indhentes viden (ofte i form af formler) fra andre kilder.
• Lav modeller eller prototyper af de dele, som skønnes særligt vigtige for forståelsen, eller som man blot har lyst til at lave, fordi de er så lette at overskue.

En eksamenssituation minder på mange måder om arbejdet som systemudvikler i det virkelige liv. Kravene til produktivitet og kvalitet er høje, og det synes for mange (især begyndere) umuligt at forene kravet om høj produktivitet (tempo) med kravet om kvalitet (korrekthed). Tempo og korrekthed er nogle ord, som mange erhvervsledere anvender som synonymer for produktivitet og kvalitet.

Efterhånden som erfaringen vokser, opdager man imidlertid, at ens produktivitet kan forøges gradvist uden at det påvirker kvaliteten af ens arbejde. Hemmeligheden er, at man lærer at genbruge nogle relativt få løsningsmodeller eller algoritmeskabeloner i et utal af variationer. Algoritmeskabeloner er kendte løsninger på større eller mindre problemer, som man genanvender, fordi man tidligere har anvendt dem med succes.

• Hvis du kender løsningen på problemet, så prøv ikke at forbedre løsningen før det er nødvendigt
• Søg ikke efter den optimale løsning (algoritme) - det tager for lang tid
• Søg efter delproblemer, som med fordel kan løses i generelle procedurer og funktioner. Beregningsformler kan f.eks. ofte omsættes til funktioner. Herved opbygges nye algoritmeskabeloner.

• Ofte vil man ud fra drejebogen kunne genkende et mønster eller en algoritmeskabelon fra en opgave, som man har løst tidligere. En algoritmeskabelon kan defineres som en kendt løsning på et problem.
• Hvis et mønster ikke umiddelbart kan genkendes, må man prøve med at stille spørgsmål ud fra drejebogen: Er der gentagelser, hvor ofte udføres gentagelsen osv.