Visa meny
Visa meny

Att vÀlja vettiga verktyg

NĂ„gra tankar om att vĂ€lja teknisk plattform – varför vi ofta överskattar hur viktigt beslutet Ă€r, och nĂ„gra saker som Ă€r bra att tĂ€nka pĂ„ nĂ€r man vĂ€ljer.

Den som har sysslat ett tag med att utveckla mjukvara förvĂ€ntas ofta veta vilka verktyg som Ă€r mest lĂ€mpade för ett visst projekt. Folk förlitar sig pĂ„ att du kan ge kloka rekommendationer om ramverk, plattformar etc. Ju mer erfaren du blir, desto tydligare rĂ„d kommer du kunna ge. Eller – Ă€r det tvĂ€rtom?

PĂ„ vissa sĂ€tt tycker jag att jag blir mindre och mindre sĂ€ker pĂ„ min sak nĂ€r det gĂ€ller den hĂ€r typen av beslut. Samtidigt bekymrar jag mig inte lika mycket över dem som tidigare. Förr kĂ€ndes saker mer svartvitt (X Ă€r bra, Y Ă€r dĂ„ligt och Z kĂ€nner jag inte ens till Ă€n) – medan jag numera bryr mig mindre om vad folk vĂ€ljer, bara det Ă€r nĂ„got som uppfyller kraven och bara det Ă€r nĂ„got de trivs med. Det Ă€r ju vad man gör med tekniken som spelar roll, vilket lĂ„ter vĂ€ldigt sjĂ€lvklart.

Visst, det Àr viktiga beslut, men man kan tillÄta sig att slappna av lite!

Jag har kommit till insikt om tvÄ saker: 1. För ett givet problem finns det ett antal olika tekniklösningar som fungerar mer eller mindre lika bra. 2. Det Àr jÀttesvÄrt att förutse alla följder av att vÀlja en viss teknik. De hÀr insikterna sÀger mig att a) det Àr omöjligt att veta vilket som som Àr den perfekta lösningen och b) det fungerar alldeles utmÀrkt att anvÀnda vilken lösning som helst som man vet Àr nÄgorlunda lÀmplig för det man vill Ästadkomma. Med andra ord spelar det inte sÄ stor roll som man kan tro. Visst, det Àr viktiga beslut, men man kan tillÄta sig att slappna av lite!

För att försöka ge lite mer konkret hjĂ€lp pĂ„ vĂ€gen – hĂ€r kommer en sorts checklista. Vi kan kalla den Att VĂ€lja En Hygglig Tekniklösning.

Hur kritiskt Àr beslutet?

Till att börja med, fundera lite pÄ hur viktigt det Àr att du vÀljer den bÀsta möjliga lösningen. Vad blir konsekvenserna om du vÀljer "fel" lösning? Hur svÄrt Àr det att byta? Om produkten Àr liten, kortlivad eller snabbförÀnderlig Àr det inte vÀrt att grubbla för lÀnge. Om du bygger en mÄnlandare Àr det ju en annan sak (vÀnta, det kanske Àr det du gör?). Mer sannolikt Àr att du ska vÀlja en databas för ett lÄngsiktigt projekt. Det Àr ett exempel pÄ en teknik som kan vara knepigare att byta ut lÀngre fram. En annan sak som förtjÀnar mer eftertanke Àr nÀr man bygger ett API, sÀrskilt om det Àr publikt.

NÀr ska man bestÀmma sig?

Det Àr ofta bra att inte fatta ett beslut alltför tidigt. UtgÄ Ätminstone inte ifrÄn en teknisk plattform frÄn allra första början, eftersom det kan pÄverka alla kommande beslut i projektet. Börja istÀllet med att skaffa dig en ordentlig förstÄelse för projektet. SÀrskilt om du Àr nÄgon som har en tendens att kasta dig in i det okÀnda.

Men du kanske Ă€r tvĂ€rtom – du gillar att grubbla pĂ„ beslut och vĂ€ga fördelar mot nackdelar i all evighet. Visst Ă€r det bra med vĂ€lgrundade beslut, men lĂ„t det inte bli nĂ„got som blockerar projektet. VĂ€lj nĂ„got lĂ€mpligt bara och börja testa. Om det visar sig att det finns bĂ€ttre alternativ – byt tidigt.

Flexibilitet

Det Àr ocksÄ viktigt att tÀnka pÄ att det Àr omöjligt att detaljplanera ett helt projekt frÄn början. Den smarta, snygga lösningen som du förestÀller dig nu kommer förmodligen skilja sig en del frÄn det du kommer bygga i slutÀndan. DÀrför bör du anvÀnda lösningar som Àr flexibla och lÀtta att anpassa till nya omstÀndigheter. Undvik stora monolitiska lösningar som försöker lösa allt. Det du inte vill hamna i Àr att inte kunna göra ett nytt vÀgval pÄ grund av att du valde plattform X nÄgon gÄng i början av projektet. (Eller, vilket sÀkert Àr vanligare, pÄ grund av att du byggde applikationen pÄ ett sÀtt som gör det svÄrt att göra förÀndringar.)

Gammalt beprövat eller nytt och modernt?

Alla har sina favoritverktyg, eller Ă„tminstone sĂ„dant som de kĂ€nner sig mer bekvĂ€ma med Ă€n andra. Det Ă€r inget fel med det, men undvik att anvĂ€nda favoritverktyget till allt – det finns inget verktyg som Ă€r sĂ„ pass mĂ„ngsidigt. Det finns specialanpassade lösningar för i stort sett varje problem man kan tĂ€nkas stöta pĂ„, och varje dag föds det nya tekniker som Ă€r bĂ€ttre Ă€n de gamla (eller, ibland Ă€r det bĂ€ttre i alla fall).

Det Àr förmodligen smart att vÀlja nÄgot som ditt team redan Àr bekant med.

Men det betyder förstĂ„s inte att man alltid ska anvĂ€nda det senaste. I början av ett projekt nĂ€r man vill kunna vara snabbrörlig och testa olika idĂ©er kan det vara smart att inte samtidigt testa helt nya verktyg. Det Ă€r förmodligen smart att vĂ€lja nĂ„got som ditt team redan Ă€r bekant med, sĂ„ vida du inte Ă€r i den positionen att du kan handplocka teamet utifrĂ„n dina tekniska nycker. Ett bra team Ă€r mycket viktigare Ă€n att kunna vĂ€lja en viss teknik. Och som sagt – ditt andra- eller tredjeval för tekniken fungerar förmodligen ocksĂ„ vĂ€ldigt bra.

Funktionalitet

Med allt ovanstÄende i bakhuvudet Àr det nu dags att börja titta pÄ den faktiska funktionaliteten du vill att plattformen ska ha. Den biten beror förstÄs helt pÄ vilka krav projektet stÀller.

Är plattformen lĂ€mplig för projektet i frĂ„ga? Har den tillrĂ€cklig prestanda, stabilitet och sĂ€kerhet? Är den lĂ€tt att testa?

Produktivitet

Kommer ni att bygga ny funktionalitet snabbt och ofta, eller Àr stabilitet och prestanda viktigast? Om det viktiga Àr att fÄ ut en produkt snabbt, vÀlj en teknik som gÄr snabbt att utveckla i, som underlÀttar samarbete i teamet och som kan anpassa sig till förÀndringar.

Man ska inte heller underskatta vikten av att lösningen ger en positiv utvecklarupplevelse rent allmÀnt. Ett team Àr produktivt om det Àr pÄ bra humör!

Förutom sjĂ€lva den tekniska plattformen – hur ser utvecklingsmiljön och verktygen ut för plattformen? Kan enskilda utvecklare anvĂ€nda olika verktyg, eller Ă€r de lĂ„sta till en specifik utvecklingsmiljö?

Man ska inte underskatta vikten av en positiv utvecklarupplevelse rent allmÀnt.

HĂ„llbarhet

Det hĂ€r Ă€r förstĂ„s mest viktigt i lĂ„ngsiktiga projekt. I det fallet bör man ta en titt pĂ„ organisationen som stĂ„r bakom plattformen. Är den hĂ„llbar och mogen?

Är plattformen öppen och "hackbar"? Man vill inte bli fast i en teknik som inte tillĂ„ter de Ă€ndringar projektet krĂ€ver. Finns det rimliga möjligheter till att koppla sig till andra system och kompatibilitet med andra tekniker?

LÀtt att komma igÄng

Även om teamet redan kan tekniken i frĂ„ga Ă€r det alltid en fördel om den Ă€r lĂ€tt att lĂ€ra sig för nya utvecklare. Det sker alltid Ă€ndringar i teamet för eller senare, och det kan ju hĂ€nda att projektet kommer att tas över av ett annat team.

Saker som pĂ„verkar hur lĂ€tt det Ă€r att sĂ€tta sig in i en plattform: storlek, komplexitet och fokus – och sĂ„klart om det finns bra dokumentation.

Kostnad

Utvecklingsprocessen Ă€r förmodligen den mest kostsamma delen i de flesta teknikprojekt, men det Ă€r ocksĂ„ bra att kĂ€nna till vilka löpande kostnader och startkostnader som tekniken har – saker som licenser och abonnemang. Hur förĂ€ndras de hĂ€r kostnaderna nĂ€r projektet vĂ€xer och fĂ„r mĂ„nga anvĂ€ndare?

Drift och underhÄll

Vilka tjĂ€nster eller hĂ„rvara krĂ€vs för att kunna köra projektet pĂ„ plattformen? Hur för man för att deploya projektet i olika miljöer – utveckling, testning och produktion? Hur gĂ„r det till nĂ€r plattformen ska uppdateras till en ny version och nĂ€r sĂ€kerhetsuppdateringar ska installeras?

MagkÀnslan

I slutÀndan Àr det mÀnniskorna som ska producera nÄgot med plattformen som bör fÄ bestÀmma. Vad kÀnner de sig produktiva med? Vad blir de glada av? Vad sÀger deras magkÀnsla?