Ett försvarstal för ramverk
I den här branschen är det mer regel än undantag att en konsultprofil eller ett CV ska proppas full med, inte bara programmeringsspråk och tekniker, utan också ramverk. Begreppet “ramverk” i sig är väldigt brett och kan handla om allt från tekniknära användningar, som till exempel Spring, Hibernate eller Wicket, till mer verksamhets- och metodnära tillämpningar, som exempelvis Scrum (även om de mer bokstavstrogna Scrum-anhängarna föredrar termen “processkelett” snarare än benämningen metod- eller processramverk). När jag här och nu använder begreppet är det först och främst i programmeringsvärlden jag befinner mig.
Oavsett hur ramverket fungerar eller vilket problem det ska lösa är dess syfte detsamma. Tanken är att erbjuda återanvändbar kod som görs tillgänglig via ett tydligt definierat API för att på så sätt öka produktiviteten i ett utvecklingsprojekt. Genom att låta utvecklarna koncentrera sig på vad som gör systemet unikt krav- och verksamhetsmässigt behöver man inte lägga värdefull tid på att till exempel skapa en fungerande infrastruktur för applikationen.
Inga konstigheter, eller hur? Det är klart att det uppfattas som en lockande tanke för alla inblandade parter i ett IT-projekt.
Saken är bara den att jag på sistone uppmärksammat någon sorts backlash mot ramverk. Opponenterna verkar inte klaga på något specifikt ramverk i sig, utan på själva tanken att det finns andra som gjort tankearbetet åt en och så att säga redan trampat upp stigarna. Jag har identifierat två huvudspår i kritiken:
Den första kategorin av kritik handlar om att ramverken faktiskt inte löser de problem man som programmerare har eller att det rent av löser fel problem. Många gånger tycker man att det känns skönt att få en massa färdig funktionalitet gratis, men ganska snart inser man att ramverken snarare stjälper än hjälper vid utvecklingsarbetet. Om den tänkta koden inte hjälper till att lösa ett problem, utan i stället sätter käppar i hjulet för utvecklarna och tvingar fram ett arbetssätt där man försöker ”komma runt” ramverket upplevs det enbart frustrerande.
Den andra gruppen av kritiker fokuserar på att det inte längre är roligt att programmera. Tidigare har arbetet som programmerare handlat mycket om att arbeta från grunden och att klura på effektiva algoritmer. Numera har yrket skiftat fokus till att snarare sätta ihop färdiga block av teknikkomponenter. Jag har pratat med bekanta i branschen som tidigare sett sig själva som hantverkare, men som numera tycker att arbetet reducerats till att bygga en byggsats av givna byggklossar. Genom att arbetet inte längre går ut på att hitta den smartaste algoritmen eller det mest effektiva sättet att hämta en koppling till en databas upplevs det som att en del av yrkesstoltheten gått förlorad. Att titta i ett API och lista ut vilken metod som ska anropas känns helt enkelt inte lika utmanande eller stimulerande.
Min respons mot den första typen av kritik grundar sig i att IT-branschen är oerhört driven av tanken på förbättringar och genvägar. Nya programmeringsspråk och utvecklingsmodeller är alltid runt hörnet. När någonting vuxit sig för komplext eller långsamt ersätts det av något lättviktigare, något mer effektivt, något mer tidsbesparande eller något som är lättare att lära sig. Ett bra exempel på det här behovet av ständiga förbättringar hittar vi om vi tittar närmare på webben. När användare, kravställare och utvecklare plötsligt insåg att en webbsida kunde uppträda mer som en ”riktig” applikation med hjälp av Ajax ville alla ha den typen av system. Att göra webbapplikationer så att de vanligaste webbläsarna kan kommunicera asynkront kräver egentligen inte många rader egenutvecklad kod, men som svampar ur jorden dök det ena Ajax-ramverket efter det andra upp. En snabb koll på Wikipedia räknar just nu, förutom de två stora ramverken ”Prototype” och ”jQuery”, upp ytterligare trettiofem exempel under rubriken ”List of Ajax frameworks”. Det råder med andra ord ingen brist på de genvägar som erbjuds rent tekniskt för en utvecklare. Beställarmässigt då? Ja, många IT-arkitekter och kravställare frestas självklart av tanken på ett färdigutvecklat och färdigtestat mjukvarubibliotek eller -ramverk av tidsbesparingsskäl. Den här tidsbesparingen syns inte bara vid nyutveckling utan också vid förvaltning när ny personal tas in och denne kan fokusera på den egenutvecklade koden. Och här är vi nu – för att övervägas som konsult i ett projekt räcker det inte längre med att vara kompetent i till exempel Java. Du förväntas också ha jobbat med Spring, JSF, Struts, Hibernate, Wicket för att bara nämna några exempel. Den här bredden jag ser som en naturlig utveckling på konsultrollen och det här min respons på den andra typen av kritik kommer in i bilden. Yrkesrollen och därmed yrkesstoltheten har fått en annan fokus – Vilka ramverk gör jobbet bäst? Vilka fallgropar bör man undvika? Hur gör vi vårt system så strömlinjeformat som möjligt och undviker att ta in mjukvarubibliotek som är onödigt komplexa eller stora? Hur gör vi teknikvalet så transparent som möjligt? Det här är frågor som den nya tidens konsult måste kunna svara på. Det betyder självklart inte att själva grunden, programmeringskunskaperna, ska stå tillbaka, utan bara att en modern systemutvecklare eller IT-arkitekt måste ha en högre grad av omvärldsbevakning och större bredd än vad som tidigare behövts.
Jag hävdar inte på något sätt att ramverken i sig är ofelbara eller ens nödvändiga alla gånger. Min poäng är snarare följande – Om det du behöver är ett hjul, varför uppfinna ett eget? Vill man förlänga hjulanalogin kan man lite krystat hävda att så länge du vet vilka sorters hjul som finns tillgängliga där ute behöver du bara välja bästa sorten för just din uppgift och kan i stället lägga din kraft på att pumpa det fullt med luft.
//Mathias