Dan North har skrevet dette blog-indlæg hvor han argumenterer for at softwareudvikling ikke er et håndværk. Robert Martin, som bl.a. har skrevet bogen ”Clean Code: A Handbook of Agile Software Craftmanship” er tilhænger af den modsatte opfattelse, nemlig at softwareudvikling er et håndværk. Men hvem af dem har egentlig ret? Og kan det tænkes at de faktisk er enige i mange punkter omkring agil softwareudvikling, når der kommer til stykket?
Jeg vil starte med at pointere at ”SOLID”-principperne fra Clean Code-bogen er meget nyttige og man skal ikke glemme den store viden om best practices og mange års erfaring inden for agil softwareudvikling som Robert Martin har.
Sådan som jeg læser Dan Norths blog-indlæg er at han og Robert Martin faktisk er enige om mange ting. For eksempel at koden skal være simpel og den skal virke efter hensigten. Kunderne skal være glade for softwaren og det skal være noget de rent faktisk bruger! De vil gerne have softwaren til tiden. Og der vil altid være skjulte fejl i softwaren, som man ikke finder inden den første release.
Under et softwareudviklingsprojekt bliver der hele tiden overvejet om en klump af koden skal refaktoreres eller ej. Om den nye feature blot skal programmeres hurtigt (a la vertikal softwareudvikling), eller om der skal laves en mere generisk løsning og gennemtænkte designovervejelser, således at det bliver nemmere at udvide featuren engang i fremtiden (hvis der bliver behov for det). Hvad er nemmest, hurtigst, billigst? Det er hele tiden en opvejning af forskellige metrikker, og i sidste ende må der tages en beslutning alt afhængig af opgavetypen – og slut-kunden, ikke mindst. Næste gang der kommer et nyt kundekrav eller et ønske om kodeforbedring fra udviklernes side, en bug eller en ny feature, så bliver de samme overvejelser taget op og diskuteret indtil der tages (måske en ny) beslutning. Processen behøver ikke at involvere samtlige sw-udviklere og projektledere hver gang. Det afhænger af størrelsen og vigtigheden af ændringen. Nogle gange kan denne diskussion blot foregå inden i hovedet på den enkelte sw-udvikler, og andre gange kan et kvarters brainstorm med de nærmeste kollegaer og eventuelt projektlederen være nok til at få et overblik over opgaven.
Test Driven Development er et must ifølge Robert Martin for bedre at kunne refaktorere koden senere hen. Koden skal være pæn og flot og nem at vedligeholde. Derfor bør man også tænke over levetiden for det softwareprojekt eller produkt, der arbejdes på. Stil jer selv følgende spørgsmål: Skal der udvikles og vedligeholdes på produktet i de næste 10 år. Hvor mange kunder vil der eventuelt komme til hen ad vejen? Eller er der kun én kunde, der køber produktet, og som kun vil bruge det i max 1 år? Hvis det er det første, som er tilfældet, så er det meget vigtigt at koden er nem at tilgå og forstå for nye sw-udviklere. Overskuelig og nem at udvide. Her kommer SOLID principperne ind i billedet. Hvis det er det sidste, som er tilfældet, så er kunden nok mest interesseret i at få produktet så hurtigt som muligt (og så billigt som muligt), og så er store, forkromede og æstetiske programmeringsløsninger nok ikke løsningen.
Jeg tror at både Robert Martin og Dan North er enige i at et softwareprodukt blot flytter information rundt (som er ét af argumenterne Dan North bruger i sit blog-indlæg). Softwaren skal virke og det skal bruges af kunden. Ellers er det ikke et godt produkt. Men man kan også udvikle software som en mellemting mellem blot at flytte data rundt og lave software der er flot konstrueret, så man opnår noget mere. Ellers kunne vi alle jo bare kode i et lavniveau script-sprog og ikke tænke på hvordan koden er bygget op.
Hvad er din holdning til softwareudvikling som et håndværk? Og er der nogen der har erfaring med at regne på hvor meget det koster at skulle vedligeholde uoverskuelig kode i forhold til at bruge tid på refaktorering?
Softwareudvikling er I mit hovede sammenlignligt med mange andre fag – både de mere kreative som design, arkitektur og ingeniør, såvel som de mere praktiske som snedker, konditor, kok og smed.
Softwareudvikling kræver faglighed, struktur og metode såvel som erfaring, værktøj og håndelag.
At vælge den bedste metode, løsning og struktur blandt de utallige mulige kræver ikke blot erfaring og fagligt kendskab foruden evnen til at forstå opgaven, kravene og begrænsningerne. Man skal også kunne forestille sig fremtidige krav til udvidelser og tage højde for indbyggede fejl med henblik på efterfølgende vedligeholdelse.
Alt dette kan ikke umiddelbart reduceres til en formel eller et sæt metoder. Der skal også noget intuition, tæft og ja, håndværk til.
IMHO Jens Krabbe
For et stykke tid siden var der en debat på V2 om hvorvidt programmering er en kunst. Synes det er ret spændende, at der er så forskellige holdninger, selvom de fleste jo grundlæggende er enige.Tror det bunder meget i folks selvopfattelse.
Der er mange rockstars, kunstnere, specialister, håndværkere, brugerorienterede, selvcentrerede, kreative, kedelige, sprudlende og alt muligt andet. Lige som der i øvrigt er i alle andre fag. Men hvor alle er enige om, at godt håndværk kan ses og føles meget direkte, er der ikke den samme enighed om hvad eksempelvis kunst er. Kunst er for mange også noget med at føle og opleve. Måske er det derfor folk ikke kan blive enige.
Jeg tror at kode kan være kunst, men at det i de fleste tilfælde/projekter er godt solidt håndværk, der er brug for.
Mon ikke der kunne komme et helt antropologisk feltstudie ud af forskellene internt i softwarebranchen?
/Thomas
Jeg synes bestemt også at softwareudvikling er et meget kreativt fag. Men der er også et brug for erfaring og gode værktøjer for at udvikle det bedste produkt. (Med andre ord: brugen af Best Practices). Dét som Dan North skriver om i sit blog-indlæg er at et software-produkt blot flytter data i sidste ende. Og kunderne oplever at produktet virker efter hensigten (forhåbentlig). Så er alle glade.
Så derfor er der ikke altid behov for at snedkerere flotte gargoyler (fx smuk kode, der følger SOLID principperne) til den store katedral (som er selve software-produktet). Det handler i sidste ende om at producere business value!
Som softwareudvikler føler jeg det direkte utilfredsstillende, hvis jeg ikke får lov til at lave et fornuftigt design, jeg kan være bekendt. Der er således både ære, estetik og stolthed indblandet i det, jeg laver. Den nøgne business value er således langt fra den primære pejlestang i mit virke. Det er for mig vigtigere, at slutbrugerne får et veldesignet og brugervenligt værktøj, end at firmaet bliver rige på det.
Når vi taler om kunsthåndværk er det tæt relateret til brugskunst: ting der både er smukke og udtryksfulde samtidigt med at være anvendelige til deres tilsigtede formål. Derimod er kravet til kunst “blot” at være udtryksfuld. En kunstnerisk udformet stol kan være beklædt med lange pigge og behøver således hverken at være smuk eller anvendelig i dens oprindelige funktion. Jeg har derfor svært ved at komme på software, der udelukkende hører til kategorien kunst. Derimod er det meste software udviklet netop til at have en funktion, at fungere som et værktøj, og hvis det også er smukt eller udtryksfuld udformet, kan vi også begynde at betragte det som brugskunst, samt vurdere processen, der frembragte det, som kunsthåndværk.
Jeg tænker også meget over at koden skal være nem at læse for andre, at koden er struktureret på den bedst tænkelige måde alt afhængig af kontekst, og der er brugt tid på automatiserede tests. Jeg synes også det er vigtigt at have et sæt coding guidelines, og at få klarlagt hvilke coding values, der er vigtigst (således at hvert punkt i en guideline kan pege op på en eller flere værdier). Følgende citat fra Robert Martin rammer ret godt:
“It is not enough for code to work.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship
Men på den anden side er jeg også enig i nogle af Dan Norths pointer i hans blog-indlæg, som jeg har linket til, i og med han mener at software blot flytter rundt på information, og at det eneste der betyder noget for en kunde er om softwaren virker efter hensigten (og at det er det rigtige produkt) – og at det gerne skulle være færdigt i går. Dan North skriver med humor og et glimt i øjet. Han er super dygtig, har benene nede på jorden og har masser af praktisk erfaring – og er samtidig ydmyg. Så derfor kan jeg ikke lade være med at være enig i at vi softwareudviklere bør overveje om der virkelig er brug for flotte og smukke løsninger (hver gang)?