Softwareudvikling - er det en kunstform? En kreativ proces? Noget smudsigt?

Der har for nylig på Version2 verseret adskillige spændende debatter, der sætter spørgsmålstegn ved den måde, softwareudvikling ofte er organiseret i danske virksomheder. Det har bl.a. været diskuteret, om vi universitetsuddannede udviklere spildte vores tid og evner med "bare" at programmere, når vi nu måske burde bruge al vores tid på at udtænke snedige algoritmer og tegne fine kasser og lave specifikationer. Og disse nydelige dokumenter kunne vi så give videre til en hær af kortere uddannede programmører, som (med et citat fra debatten på Fagforening: Mangel på it-arbejdskraft) vil "være rutinerede i, at klaske mange kodelinier ned på nul tid".
 
Super. Masser af kodelinjer på nul tid, det er da lige det, Danmark mangler for at blive konkurrencedygtige på det globale arbejdsmarked. Det er formodentlig også den metrik, der får mange virksomheder til at se så begejstret på outsourcing af udviklingsopgaver: Flest mulige kodelinjer for pengene. Hvis der sidder nogen derude, som har brug for konsulentbistand på området, så kan jeg hurtigt skrue et program sammen, der kan producere flere kodelinjer i timen end en hvilkensomhelst udvikler.
 
Jeg har et par teser på det her område:

  • *Det er en myte, at der eksisterer store mængder af kode, der "bare" skal skrives. *Måske hvis det skulle kodes i Assembler, meeen...
  • *Der kommer ikke nogen produktivitetsgevinst ud af at uddelegere selve programmeringen* til andre mennesker end dem, der tænker tankerne om, hvad brugerne har af behov, hvordan det hænger sammen med den overordnede arkitektur osv. Enten skal man specificere ud i så ekstreme detaljer, at man kunne have nået at programmere det på den samme tid, eller også er man nødt til at overføre store dele af den viden til programmøren med dertil hørende overhead.
  • *Softwareudvikling er ikke en envejs-proces fra tanke til kode*. Der kommer rent faktisk værdifuldt feedback fra den del af udviklingsprocessen (uanset metodik) hvor man implementerer. For grafiske komponenter selvfølgelig en fornemmelse af, om det fungerer i praksis, og nye ideer til, hvordan man kan skabe en bedre brugeroplevelse, men også for ikke-grafiske komponenter synes jeg ofte, at jeg får nogle indsigter undervejs i selve programmeringsfasen.

 
Det er mit indtryk, at der nogle steder i f.eks. universitetsmiljøet er en ide om, at programmering ikke er "fint". Man får snavsede hænder. Ofte laves analogien til byggeriet, hvor arkitekten jo heller ikke er ude at mure, men overlader det til faglærte håndværkere. Jeg synes bare, at det er en lidt tilfældig analogi. Man kunne også have valgt kunstmaleren som eksempel - han har sjældent en ung assistent til at lave selve malerarbejdet, mens han har skrevet en fin specifikation om, at der skal lidt rødt i højre side og noget blå foroven. På visse måder minder softwareudvikling om kunst. En kreativ proces. Og kreativitet og overblik kommer ofte af at have hænderne ned i "skidtet".

Kommentarer (13)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Mikkel Høgh

Jeg tror nemt at man kommer ud i noget meta-meta-programmering hvis man skal skrive kravsspecifikationer detaljerede nok til at man bare kan sætte de "uvaskede" til at lave koden.

Jeg oplever også tit at der hvor jeg får de bedste idéer er mens jeg sidder med fingrene nede i koden - man kigger på det man har lavet, og pludselig går det op for en, at det kan jo gøres langt bedre...

  • 0
  • 0
#2 Henrik Knopper

Også enig. Det er sjovt som antallet af kodelinier bliver betragtet som et mål i sig selv.

Det er ligesom med amerikanske fagbøger hvor forfatteren aflønnes pr side. Det giver mange sider uden substans.

En af mine lærere på edb-skolen fortalte med stothed om hvordan han havde været med til at lave en multi-threaded OS-kerne med messagning struktur på ca. 16.000 liniers kode. Han var klart nok ikke imponeret over de moderne systemer med flere millioner linier til bare de mest basale ting.

Skal vi andre være det?

  • 0
  • 0
#3 Lasse Nielsen

Softwareudvikling sammenlignes ofte med mere "modne" brancher, som fx byggeri. Derfra slutter nogen af hvis bare en arkitekt har tegnet et flot blåtryk (designdokument), så er resten bare "produktion".

Produktion er faktisk nemt og automatiseret ... det er det compileren laver. At skrive programmet er en specifikationsopgave, og den kræver at man kender både programmeringsdomænet og problemdomænet for at kunne lave de valg der nødvendigvis må komme, og for at kunne genkende og bruge det feedback der er nødvendigt for at successfuldt resultat. Altså, når success er at brugeren er tilfreds, ikke bare at specifikationen er overholdt.

/L

  • 0
  • 0
#4 Thomas Hansen

For at hænge fast i den haltende sammenligning med arkitektur, så viser talrige sager om byggesjusk at selv det at bygge huse kræver 'håndværk'..

Det samme gør sig gældende for IT. Medmindre vi har den facistiske pseudo-programmerede specifikation, så skal en koder udvise noget kreativitet, eller 'håndværk' i at tage nogen beslutninger om implementationen af nogen del komponenter. Nogen beslutninger vedkommende er bedre udrustet til at tage hvis vedkommende kender det store billede, og ikke bare bliver opfattet som en kodeabe.

  • 0
  • 0
#5 Torben Mogensen Blogger

Hvis man synes, at der er et stort nok arbejde i at komme fra specifikation til implementering til, at man vil outsource det, så bruger man enten t forkert sprog til implementering eller til specifikation.

Det første læner sig lidt op af Lasses analogi om, at produktionen er det compileren laver. Men det samme gælder i nogen grad, hvis man insisterer på at implementeringen skal laves i et lavniveausprog som C eller C++, hvor programmøren skal specificere selv de mindste implementeringsdetaljer.

Så brug dog hellere et sprog, hvor implementeringen ligger tæt på specifikationen. Det kan være et domænespecifikt sprog (eller flere på en gang) eller et højniveau deklarativt sprog.

Det andet punkt (forkert specifikationssprog) er brug af modelsprog, der modellerer implementeringsstruktur men ikke semantik. UML er ret slem til dette: Det specificerer objektstruktur i detaljer, men siger ikke så meget om, hvad den overordnede funktionalitet er. Man har altså overspecificeret nogle dele og underspecificeret andre. Man tror måske, at man gør programmørerne en tjeneste ved at give dem en objektmodel, men det sker ofte, at den specificerede model ikke er den bedste til at løse problemet, og så vil man enten tvinge programmøren til at arbejde med en suboptimal model eller til at skrotte modellen og starte forfra, hvilket i bedste fald er spildt arbejde.

  • 0
  • 0
#6 Poul-Henning Kamp Blogger

Jeg synes i blander begreberne sammen på uheldig vis:

"Programmering" er at få en computer til at udføre nogle handlinger man på forhånd har bestemt sig for at den skal gøre.

"Softwareudvikling" handler om at komme helskindet fra ide til kode der kører i drift.

Det ene kræver en kodekarl, det andet en erfaren projektleder og arkitekt.

Poul-Henning

  • 0
  • 0
#7 Torben Mogensen Blogger

Jeg tror Anne-Sofies pointe er, at de to funktioner ikke er så skarpt adskilte, som nogle tror. Dermed er der behov for enten en tæt kommunikation mellem projektledere og "kodekarle" eller en sammensmeltning af de to funktioner.

Endvidere er det lidt nedsættende at kalde programmører for "kodekarle". Deres arbejde er (for de flestes vedkommende) ikke tankeløs oversættelse af specifikation til implementering (hvis det var det, kunne man bruge en compiler), men kræver en del indsigt i problemet såvel som i programmeringsmetoder og -sprog.

  • 0
  • 0
#8 Poul-Henning Kamp Blogger

Det er smukt som du overser det sidste ord i mit indlæg.

Projektleder er gode til GANTT kort og mødereferater og kodekarle (ikke noget nedsættende udtryk) er gode til at fodre compilere, men imellem dem sidder arkitekten og binder enderne sammen.

En god arkitekt har erfaring fra begge sider og tør sige til brugerene "den feature bliver for dyr, det er billigere at gøre det i hånden" og til kodekarlene at "Nej de skal ikke opfinde en 3.ordens bresenhamalgoritme for hyperspace, det er fint med en simpel hash-tabel".

På den vis bliver det til softwareudvikling.

Hvis arkitekten mangler bliver det bare softwareindvikling.

Det er klart at små projekter kan kollapse arkitektfunktionen til en eller muligvis endda begge sider, men så små projekter er jo trivielle at få til at virke.

På store projekter derimod, har hverken koderne eller projektlederne tid til at holde det store tekniske overblik i hovedet, derfor skal man have en arkitekt.

Poul-Henning

  • 0
  • 0
#9 Martin Falck-Hansen

Lidt i stil med et tidligere indlæg der erklærede at den klassiske it-nørd for død (http://www.version2.dk/artikel/3802?rss), så tror jeg at de programmører som udelukkende er i stand til at producere store mængder kode i et rasende tempo er ved at forsvinde til fordel for udviklere som har forretningsforståelse, er kvalitetsbevidste og forstår at deres arbejde er en del af et større hele.

For eksempel er det jo efterhånden anerkendt at jo senere i et udviklingsforløb en fejl findes, jo dyrere er den at rette - en læresætning som mange firmaer har måtte sande på den dyre måde. Af denne grund tror jeg at det bedre kan betale sig at ansætte folk som ikke bare sprøjter hobe af kode ud, men derimod kan levere kvalitetsarbejde.

  • 0
  • 0
#10 Kim Schulz

Min erfaring er at dem som har forretningsforståelse og marketingssans, totalt mangler evnen til at udvikle noget som helst. Kvalitet er en by i rusland og hvis det kan kompilere, så har vi de et produkt. De sælger produktet før det er klart og med specs som enhver kan se er totalt urealistiske.

Udviklerne skal derimod være analytiske og sans for at tilpasse et produkt til deres evner. Rækker evnerne ikke, ja så må der nyere og bedre medarbejdere til (eller et mindre ambisiøst produkt på planen).

  • 0
  • 0
#11 Jens Katz-Kolberg

Jeg er meget enig med PHK, men jeg tror kun man kan blive en god arkitekt ved at have programmeret meget selv.

Et godt citat i den anledning: "To me, you understand something only if you can program it. (You, not someone else!) Otherwise you don’t really understand it, you only think you understand it." - Gregory Chaitin: "META MATH! The Quest for Omega"

  • 0
  • 0
#12 Martin Falck-Hansen

hej igen

jeg tror det er meget afhængigt af den kultur der er i organisationen. Hvis ledelsen er villige til at betale for at udviklerene kan tilegne sig en vis forståelse for hvad der foregår i resten af organisationen, tror jeg at de får bedre udviklere end hvis de blot insisterer på at de skal producere kode. Jeg tror faktisk at det er en nødvendig forudsætning for at være en god programmør at man forstår hvad der foregår i resten af virksomheden - det er trods alt dem som i langt de fleste tilfælde tjener pengene .. udviklerne er som regel blot en nødvendig udgift for virksomheden.

  • 0
  • 0
#13 Michael Møller

Jeg er enig med dig, Software udvikling er en kreativ proces, men de udvikingsmetoder og modeler vi bruger ligger så langt fra den erkendelse, også scrum..Google synes at prøve at gøre noget ved det med deres 20% idé, Thomas blachman er sjovt nok i sync med hans idé om en ugentlig fridag til obligatorisk undervisning. Men jeg tror vi skal videre fra de 20%, og finde på en ny model for software udvikling der siger 100%.

  • 0
  • 0
Log ind eller Opret konto for at kommentere