Att skriva eller inte skriva kod

Tio frågor att ställa sig inför valet att köpa eller bygga själv

Det finns många bra skäl till att skriva kod. Som utvecklare tycker jag i grunden att allt som ingår i en digital verksamhet — all data, processer, relationer saker emellan — bör uttryckas som kod. Kod som du själv har full inblick i och rår över, vilket inte alltid är fallet när du använder en färdig lösning. Den egna koden är en del av det som utgör värdet i en digital organisation.

Samtidigt är kod också en belastning för den som äger den. Kod kan sluta fungera, blotta säkerhetshål, vara svår att förändra. Kort sagt kostar det tid och pengar att hålla sig med kod. Ju mer kod, desto mer kostar det (även om det inte bara är antalet rader kod som påverkar).

Det är viktigt att, som utvecklare, vara ärlig med det faktiska behovet av att skriva egen kod, i en värld där så många digitala problem redan har en färdig lösning. Det finns ett enormt utbud av molntjänster och färdig mjukvara, som i sin tur kan vara antingen köpt eller open source. Det är ett vanligt misstag att tro att ens egen situation är så unik att ingen standardlösning kommer att passa. Vi utvecklare lockas dessutom gärna av tanken på att sätta sig med ett rent blad och rita upp en perfekt lösning på ett problem — men det blir sällan så enkelt och bra som man tror.

Jag kan inte säga om det skrivs för mycket eller för lite kod i Sverige 2020. Men man kan nog räkna med att det ofta fattas fel beslut i den här frågan — alltså att man antingen undviker att bygga något skräddarsytt när det egentligen skulle ha behövts, och omvänt, att det skrivs kod som hade varit bättre att undvika att skriva. Många av oss har nog blivit brända av båda typerna av fall. Vi har säkert också tidigare erfarenheter där vi även i backspegeln har svårt att säga om beslutet var rätt eller fel.

Köpa eller bygga?

Så hur vet man då när det är en bra idé att köpa eller när det är relevant att bygga? Vi säger att du ska implementera en digital lösning — det kan vara ett komplett system för en hel organisation, en specifik applikation för en kundgrupp, eller en mindre beståndsdel i en digital lösning som du redan har.

Det här brukar kallas för build or buy-dilemmat. Här finns inget facit, men jag har genom att läsa, fundera och rådfråga branschkollegor kommit fram till en lista med frågor som du kan ställa dig inför ett sådant beslut. (Jag ville få ihop tio frågor, men det blev nio. Vilket bara är bra, för det är ju inte bara kod som det kan bli för mycket av.)

1. Hur viktig är lösningen för din kärnverksamhet?

Om det du gör faktiskt är att digitalisera din kärnverksamhet så finns det skäl att vara extra noga innan man lägger allt i händerna på en tredje part. Det handlar om saker som vem som äger och har tillgång till din viktigaste data, och makten över processerna i din verksamhet.

2. Är lösningen generisk eller unik för din verksamhet?

Som jag skrev ovan tror man ofta att man är mer unik än man i själva verket är. Men i vissa fall är det den specifika digitala lösningen som är själva existensberättigandet för verksamheten. Om det rör sig om en tekniskt innovativ produkt så är förmodligen beslutet enkelt — du måste bygga åtminstone kärnan själv. Med andra ord handlar det om att skriva rätt kod— bygg det som är unikt själv, och köp in det som är standard.

3. Finns det en lösning som passar er?

Hur väl lever lösningen upp till kraven? Ännu viktigare är kanske att fråga sig hur anpassningsbar organisationen är. En större organisation som har funnits ett tag kan vara svår att ändra på, och då kan en köpt lösning vara jobbig att implementera. Å andra sidan är det kanske ett bra tillfälle att tänka över hur organisationen jobbar?

4. Hur bråttom har du?

En köpt lösning kan du i teorin sjösätta på nolltid, men i praktiken kommer du behöva göra anpassningar, integrationer med andra system, och förankra arbetssätten i organisationen. Trots det kan man oftast räkna med att det är betydligt snabbare än att bygga en lösning själv. Finns det stora vinster med att nå ut på marknaden snabbt så kan det vara något som pekar mot en färdig lösning.

5. Vilka resurser har du?

Att bygga en egen lösning är kostsamt. Det är i stort sett alltid dyrare än en köpt lösning, eftersom du bär hela utvecklingskostnaden själv.

Det handlar inte heller bara om pengar. Du måste också ha tillgång till rätt kompetens för att bygga din lösning, och om du inte redan har den så kan det kräva en del att hitta den. Även om du hyr in proffsiga konsulter så är det inte säkert att det blir rätt från början.

6. Hur påverkar beslutet dina slutanvändare?

Något som många vill undvika att använda standardlösningar för är gränssnittet för slutanvändare. Väljer du en färdig lösning vill du inte att kunderna ska utsättas för ett generiskt eller rentav dåligt användargränssnitt, utan du vill kunna anpassa det efter ditt eget varumärke och försäkra dig om att användarupplevelsen lever upp till kundernas förväntningar.

En färdig lösning kan lysa igenom till slutanvändaren på flera sätt — det kan handla om mailmallar, standardtexter, felmeddelanden osv. Du bör se till att allt sådant håller hög kvalitet eller går att anpassa så att det passar er.

7. Kommer behoven förändras över tid?

Hur stor är risken att ni efterhand växer ifrån lösningen ni har köpt in? Hur flexibel är lösningen? Det kan vara svårt att veta hur behoven kommer att se ut framöver, men ofta kan man ha ett hum om hur pass förändringsbenägen organisationen eller användningsområdet är.

8. Går det att avgränsa lösningen tydligt? Är den utbytbar?

Rör det sig om ett väl avgränsat problem, som att slå upp adresser, konvertera bilder eller skicka SMS — då är risken förmodligen inte så stor för att låsa in sig i en lösning. Finns det komplexa integrationer eller viktig data i lösningen så blir den svårare att byta ut om det skulle behövas senare.

9. Hur långsiktigt kan du satsa på en köpt lösning?

Befinner du dig i ett sammanhang där externa leverantörer måste upphandlas med jämna mellanrum så kan du hamna i att du blir tvingad att byta ut en köpt lösning tidigare än du hade velat. I sådana lägen kan det vara värt att fundera lite extra på om man inte ska bygga en lösning som ägs av organisationen själv. I det fallet är det kanske extra värt att använda open source-lösningar.

Bonus: att utvärdera en tredjepartslösning

Checklistan för att välja tredjepartslösning är förstås olika för olika situationer, men här är några punkter som kan vara bra att tänka på:

• Organisationen som står bakom lösningen — är den pålitlig på tillräckligt lång sikt?
• Säkerhet och stabilitet — lever lösningen upp till den nivå som krävs av din organisation?
• Personlig integritet — hanteras data på ett sätt som är säkert och som tar individens integritet på allvar? Tänk på att du måste ställa samma krav på en tredjepartslösning som ställs på dig, i form av GDPR och annat.
• Rätten till datan — har du möjlighet att ta med dig din data till en ny lösning i framtiden?
• Flexibilitet och integrationer — finns det tillräckligt goda möjligheter att anpassa lösningen efter era behov?
• Konfiguration i kod — om det krävs avancerad konfiguration eller anpassning av lösningen är det mycket värdefullt om det kan ske i kodform snarare än ett webbgränssnitt, så att du kan dokumentera, versionshantera och felsöka lösningen lättare.

Det var allt. Lycka till med dina digitala äventyr! Hör gärna av dig och berätta om vägval som du står inför eller har tampats med tidigare.

Photo by Ivan Aleksic on Unsplash