Software Craftsmanship er en grasrotbevegelse som i varierende grad har påvirket vår bransje de siste ti årene. Vi programvareutviklere har kanskje ikke gjort en god nok jobb i å forklare hvorfor vi snakker om craftsmanship. Hvorfor oppsto den, hvorfor er det viktig, og hva kan vi få ut av det?
Software Craftmanship vil formidle at programvareutvikling er et avansert håndverk som det er vanskelig å definere en komplett og entydig prosess for. En konsekvens av dette er å øke fokus på fagpersonens kunnskap og ferdigheter. Pete McBreen skrev om problemstillingen allerede i 2001 i sin bok Software Craftsmanship. Det ble likevel ikke noen særlig stor oppmerksomhet rundt begrepet før i 2009 da man fikk Software Craftsmanship Manifesto. De siste par årene har vi sett utallige konferanser, bloggposter og tweets om emnet.
Ser man på aktiviteten rundt craftsmanship i dag er det sannsynlig at vi har passert “hype-fasen”. Ledere i IT-organisasjoner sitter kanskje igjen med ansvaret for å definere hva craftsmanship betyr for organisasjonen. Det kan være en vanskelig oppgave – bildet der ute er rimelig forvirrende. Vi som jobber med programvareutvikling har kanskje ikke gjort en god nok jobb i å forklare hvorfor vi snakker om craftsmanship og hvorfor det er viktig. Har vi gjort en dårlig salgsjobb? For å forstå innholdet i Software Craftsmanship kan det være lurt å tenke over hvorfor vi fikk denne bevegelsen. Smidige prosesser har forandret mye på hvordan vi driver prosjektledelse, men vi har kanskje glemt det tekniske aspektet ved å være endringsdyktig og smidig? Martin Fowler sier det slik::
- Organisasjoner ønsker å være smidig, og velger gjerne Scrum som metodikk
- Man innfører praksiser og prinsipper fra Scrum med variert hell
- Etter en stund erfarer man at progresjonen i prosjektet går ned på grunn av kvalitetsproblemer
- Clean Code: en økt bevissthet på å skrive kildekode som er ryddig og vedlikeholdbar
- Teknikker for programmerere inspirert av eXtreme Programming: Test Drevet Utvikling, Kontinuerlig Integrasjon, Par-programmering, refactoring m.m.
Du har hatt elektrikeren på besøk, du har fått lys i stua og alt fungerer som det skal. Uken etterpå får du en telefon fra elektrikeren som lurer på om han kan komme tilbake for å rydde opp i jobben han gjorde. Han sier at det fungerer slik det er - men ryddigheten i kablene er ikke slik han ønsker. Det vil koste 10 000 kr å rydde opp.
Hvordan ville vi forholde oss til det? Refactoring er en nødvendig aktivitet for oss programmerere, men vi må være pragmatiske i bruken av dette verktøyet, og vi må forklare våre arbeidsgivere hvorfor det er viktig.
Hva har vi fått ut av craftsmanship, og hva kan vi ta med oss videre?
Prinsippene i craftsmanship er fortsatt like viktige, også ett år etter “hypen”. Smidig metodikk vil aldri fungere uten de tekniske praksiser i bunn som gir endringsdyktighet. Vi teknikere må bare ikke glemme å koble vårt håndtverk til forretningsverdi. Da vil vi få større gjennomslagskraft for det vi mener er viktig. Her er noen tanker som kanskje kan være en ledetråd for videre arbeid med Software Craftsmanship:
- Vårt mål er å løse forretningsproblemer i programvare. Vi bør alltid søke teknologi, teknikker og metodikk som best støtter problemet vi skal løse.
- Som fagpersoner må vi være ansvarlige. Det betyr at vi må kunne gjøre pragmatiske valg. For våre kunder vil alt vi gjør være en kost/nytte vurdering. Lager man programvare som skal leve i flere tiår er sannsynligvis kvalitet, vedlikeholdbarhet og testbarhet essensielt. En perfekt kodebase er derimot feil prioritering i en løsning med kort varighet. Det er vårt ansvar som fageksperter å sørge for en balanse.
- Verktøykasse; for å kunne være effektive og ansvarlige problemløsere må vi ha et bredt spekter av teknologi, teknikker og metodikk å kunne velge blant.
- Dedikert trening. En verktøykasse bygges gjennom øvelse og erfaring. En systemutvikler bør ha et bevisst forhold til hvordan man øver for å hele tiden bli bedre i faget sitt.
