Thomas Kuhn argumenterer i sin bok, «The structure of scientific revolutions», at paradigme-skifter kun skjer mellom generasjoner. Dette har tydeligvis gått hus forbi oss programmerere. Her florerer paradigmene, til tross for bransjens unge alder.
Nøkkelen til kunnskap, forståelse, og utvikling, er å kunne endre perspektiv. Å kunne se på problemet fra ulike ståsteder. For å forstå litt av galskapen der ute, la oss derfor se på noen av de ulike måtene man kan programmere på.
Data-drevet utvikling: Når alt starter med data-strukturene. Substantivene om man vil. Når man først kartlegger data-grunnlaget, deretter ser på interaksjonene.
Hendelses-drevet utvikling: Når alt starter med prosessene. Verbene om man vil. Når man først finner hendelsene som skjer, deretter legger på nødvendige data-elementer som følger disse. Jepp, rake motsetning til første metode.
Påvirket utvikling: Når du trenger alkohol, eller kanskje en mikro-dose LSD, for å kunne drive frem den nødvendige kreativiteten som kreves for systemet ditt. Det er en kjennsak at all genial software laget på 70-tallet er skrevet av syre-pionerer.
Domene-drevet utvikling: Når den tekniske siden av programmering er fullstendig neglisjert, og kun lagt til på sist mulige uansvarlige tidspunkt. Når du ganske så stolt, har en støvete kopi av Eric Evans tørre og kjedelige DDD-bibel i bokhylla, og som alle andre bare har lest de tre første kapitlene.
Mønster-drevet utvikling: Når du streber etter å benytte samtlige patterns i boka. Når du har lider av søvnmangel fordi det mangler et pattern i koden. Når du krangler om forskjellen på Idioms og Patterns, og når the Gang of Four ikke lengre er et punk band fra England.
Prosjekt-drevet utvikling: Når du mener livssyklusen til systemet er identisk med livssyklusen til prosjektet. Når prosjektet avsluttes, burde systemet gjøre det også. Bortsett fra at det ikke gjør det. Med unntak av bevilgningene. Når man har en formell seremoni ved overtagelse til drift og forvaltning. Når overtagelse strengt tatt bare er en signatur på et ark, og alle ressursene (les: mennesker) forsvinner, løser nye verdensproblemer andre steder. Når kunstige tidsfrister er synlige i store deler av koden. Når man jobber overtid over overtiden for å rekke en ubetydelig, kunstig, tilfeldig, tidlig prosjekt-planlagt tidsfrist. Det er jo den eneste måten.
Test-drevet utvikling: Når du ender opp med interne grensesnitt for ingen andre formål enn testingen selv. Når du bruker mesteparten av tiden på tester som ikke gir forretningsverdi. Når du må endre flerfoldige tester for hver eneste lille kode-endring, og større feil allikevel fortsetter å komme. Når du begynner å teste testene dine.
Google-drevet utvikling: Når programmerings-syklusen består av stegene problem-beskrivelse, google, finne, copy&paste, ferdigstillelse. Når stackoverflow er din venn.
Objekt-orientert utvikling: Når du elsker taxonomies, og mener Carl von Linnè´s system er uangripelig. Når du ender opp med å la editoren din selv generere mesteparten av koden, for slik er reglene.
Funksjonell-drevet utvikling: Når en monad bare er en monoid i kategorien av endofunctors.
Deklarativ-drevet utvikling: Når du foretrekker hva fremfor hvordan.
Feil-drevet utvikling: Når alt du gjør er å fikse feil ved å innføre stadig nye feil.
FUD-drevet utvikling: Når du er for redd til å spørre de riktige spørsmålene, for svak til å forsvare prinsippene dine, og for dum til å fikse rot-problemene der de egentlig hører hjemme. Hvorvidt disse er i forretningsprosessene, it-systemene, politikken, eller hvor-som-helst annet sted enn ved hjelp av forferdelige if-setninger lappet på langt utenfor det funksjonelle området de adresserer.
Zen-drevet utvikling: Når ord er utelatt, og tomhet og eleganse er førende for en sjelløs kode laget kun for de opplyste.
Strukturert programmering: Når Dijkstra er din eneste venn. Bortsett fra at han ikke er det.
Aspekt-orientert programmering: Når du etter beste evne prøver å skjule hva som faktisk skjer i systemet, og når du etterhvert mistenker at verden gjør akkurat det samme.
Visuell-drevet utvikling: Når du ender opp med å bruke mesteparten av tiden på å flytte en mus, når du utvikler i verktøy laget for en yrkesgruppe som ikke eksisterer, når du lettere ser begge ender av spagettien i spagetti-skålen din enn begge ender av programmet ditt, og når du ender opp med å programmere 95% av systemet i unntaksform.
Jeg har hatt den tvilsomme glede av å jobbe med samtlige av disse paradigmene opp gjennom årene. Ofte benytter team en kombinasjon, med varierende styrkegrad. Er det rart det blir komplisert?
Kunsten å programmere? Det er å forstå menneskets vesen.