Yrkesetik inom mjukvaruutveckling: Vad utmärker en professionell

Uppdaterad den 15 april 2008, se längst ned.

Tidigare i veckan höll jag en presentation med titeln "Yrkesetik inom mjukvaruutveckling: Vad utmärker en professionell utvecklare?" på Developer Summit i Stockholm inför ca 60-70 personer. Eftersom jag av flera personer fått frågan vad presentationen handlade om och eftersom en kort artikel i Computer Sweden dessutom har väckt en del debatt tänkte jag här kort summera vad jag egentligen pratade om på konferensen.

Årets upplaga av Developer Summit hade "värdeskapande applikationsutveckling" som tema; hur bygger vi "värdeskapande system, system som stöttar kundens affärer och organisation" (från konferensens webbplats). Det gör vi utvecklare framför allt genom att skriva kod som skapar funktionalitet som uppfyller någon sorts önskemål eller specifikation från kunden. Lyckas vi med det skapar vi värde för kunden.

Problemet är att vi inte alltid lyckas med det. Ganska ofta beter sig mjukvara inte som kunden önskat. Då säger vi att den har defekter. Vi bör inte tala om "buggar" eftersom det lätt för tankarna till föreställningar om oförklarlig eller mystisk uppkomst när det i själva verket handlar om att defekter introduceras av människor. Jag gav exempel på defekter som orsakat stor materiell skada, nämnde att de ibland tar människoliv, berättade om statistik som uppskattade kostnaden för defekter i USA till 60 miljarder dollar årligen och om undersökningar som visade att nära hälften av alla användarprogram har icke-triviala defekter. Enligt en undersökning introducerar utvecklare i snitt 5-8 defekter per timme vi kodar!

Givet den stora kostnaden för defekter och det faktum att det verkar finnas så gott om dem: finns det verkligen ingenting vi kan göra för att undvika defekter? Jo, det finns många tekniker som kan hjälpa utvecklare att inte införa defekter: Design by Contract, Testdriven utveckling (TDD), formella kodinspektion (även kallade "Fagan inspections"), parprogrammering, m.fl. Tekniker som bland annat tvingar dig att noga tänka igenom specifikationen för vad som ska göras och koden för att uppfylla den; som leder dig bort från komplexitet genom att exempelvis tvinga dig att dela upp programmet i små och verifierbara delar.

Defekter kan också uppstå på grund av dåligt uttryckta krav, dålig återkoppling från kund eller användare, dålig kommunikation och andra saker som vi inte alltid förknippar med utvecklarrollen i ett team eller ett projekt. Eftersom jag befann mig på en utvecklarkonferens och hade begränsat med tid valde jag att fokusera på mjukvarukonstruktion i snäv bemärkelse. Det betyder inte att de andra delarna är mindre viktiga eller att utvecklarna inte ska bry sig om dessa saker - tvärtom! Men jag var tvungen att dra gränsen någonstans.

Att "uppfylla specifikationen" är emellertid inte allt. Att det fungerar är viktigt, men det ska också gå lätt att arbeta vidare med koden utan att riskera att introducera defekter och utan att produktiviteten lider. Därför bör vi undvika dålig kod (eller "fulkod"). Dålig kod kännetecknas framför allt av att den är svårt att förstå och svår att förändra, till exempel på grund av att den har långa och omständliga klasser och metoder, obegripliga metod- och variabelnamn, duplicering av logik och hårda beroenden.

Vi vet hur man skriver bra kod. Vi vet hur man undviker defekter. Så varför gör vi inte det?

Okunskap är en ursäkt. Den kan inte godtas mer än i början av en yrkeskarriär eftersom det faktiskt går att bli bättre på de här sakerna; även om de är svåra att bemästra är de lätta att lära sig. Tidsbrist är en annan ursäkt. Uppskruvat tempo - av oss själva eller andra - gör att vi gärna tänker att koden kan bättras på och tester skrivas senare. Men senare blir ofta detsamma som aldrig. Kan verkligen brådska vara ett acceptabelt skäl att skriva dålig kod och riskera att introducera defekter? Vad skulle du säga om du var läkare och en patient krävde att du skulle strunta i att tvätta händerna innan en operation för att hon hade bråttom? Eller om du var patient och läkaren struntade i det därför att hon hade bråttom?

Det kanske är någon annans fel? Chefen har satt upp orimliga tidsramar eller kunden vill inte betala för kvalitet? De flesta chefer och kunder vill faktiskt ha bra och defektfri kod även när de är besatta av tidsplaner och budgetar. Men det är deras jobb att passionerat försvara tidsplan och budget. Det är ditt jobb som utvecklare att försvara koden med samma passion! Du måste använda din kompetens för att förklara vad konsekvenserna av dålig kod och inga tester/kodinspektioner/etc blir.

Vi måste helt enkelt sätta ned foten och säga som det är: alla sätt att producera kod är inte lika bra. Vi behöver en "yrkesetik" eller en sorts kollektiv yrkespraktik som definierar vår profession, vårt yrke. Med den kunskap och erfarenhet vi har samlat på oss de senaste 50 åren kan det inte längre vara den enskilde utvecklarens ensak hur hon producerar sin kod. Vi utvecklare borde kunna vara överens om vad det är som skiljer oss från vem som helst med en dator och en kompilator. Vi behöver en gemensam uppfattning om vad som är professionellt och vad som inte är det. Slarv och ursäkter som tidsbrist och okunskap är bara möjliga i en kontext där undermåligt utfört arbete tolereras och där ingen ställer krav på vad som är fackmässigt godtagbart.

Professionalism handlar inte om att använda en viss sorts språk eller en viss sorts verktyg. Det handlar om praktiker och tänkesätt. Det handlar också om att sätta stolthet i det man gör och om att visa omtanke. Omtanke om kunder, användare, medarbetare, kod, affärsvärde o.s.v.

Resten av presentationen ägnade jag åt att gå igenom ett antal praktiker som jag och många andra anser utmärka en professionell utvecklare. Praktiker som TDD, parprogrammering, kontinuerligt lärande med mera. Jag avslutade med en förhoppningsvis inspirerande apell om varför man ska bry sig och om att förändring börjar med dig själv.

Det skall sägas att mitt snäva fokus på kodens kvalitet och mjukvarans korrekthet med rätta kritiserades av Peter Tallungs som anser att det måste vara användaren vi framförallt ska "svära" att skydda med vår yrkesetik. Detta är något jag borde ha tagit upp i min presentation, även om fokus som sagt var på utvecklaren och dennes "kärnverksamhet" denna dag. Vill man se det från den positiva sidan finns det utrymme för förbättring i fall jag skulle få för mig att hålla en liknande presentation i framtiden. :-)

De "slides" jag visade under presentationen kan du ladda ned här. Jag kommer förhoppningsvis att inom kort skriva ett par bloggposter där jag lägger ut texten kring några av de ämnen jag tog upp under presentationen. Om du har kommentarer eller frågor eller vill veta mer om något från min presentation får du gärna lämna en kommentar här på bloggen eller använda e-postadressen högst upp i högerspalten.

Uppdatering den 15 april 2008: Ibland går det för fort, särskilt när man ska sammanfatta något, vilket Henrik Engströms kommentar nedan påminner mig om. Något jag tog upp på Developer Summit - och som jag hoppas framgick där - var att det inte finns några universella best practices, precis som Dan North underströk i sin utmärkta presentation dagen därpå och som även James Bach förklarat på ett förtjänstfullt sätt. De jag lyfte fram är en skola och det finns andra, t.ex sådana som trycker mer på de andra tekniker jag tog upp, så som formella kodinspektioner och prototyping. Robert Martin, som inspirerat mig och som jag lånat mycket från, jämför med kamsporter ("martial arts") där man sällan påstår att någon kampsport är odiskutabelt "bättre" än alla andra, men när man väl valt sin skola så agerar vi som om dess tekniker är de rätta och försöker förfina dem till perfektion. Martin Fowler skrev något liknande häromdagen.

För övrigt var en av de praktiker jag lyfte fram att använda rätt verktyg för rätt uppgift och inte bara samma gamla verktyg som man råkar känna till (eller som Microsoft ger dig, som det ofta fungerar i .NET-världen).

Jag kanske helt enkelt får lov att göra en uttömmande bloggpost om allt jag pratade om...