Det här med att ha många olika verktyg...

I management-lagret i många organisationer finns det personer som sammanställer listor på den mjukvaruhjälpmedel som används och som tittar på denna och säger: Vi ska effektivisera genom att bara ha ett verktyg för varje funktion.

Ointuitivt nog är detta ofta ett väldigt ineffektivt beslut. Jag ska försöka förklara varför.

Personligen har jag varit med om att införa åtskilliga testverktyg och QA-relaterade verktyg i olika organisationer. Det finns mängder av utmaningar inom olika områden med detta. Att ha överkommit många av dessa har gett värdefulla insikter i mekaniken som skapar ineffiktivitet i verktygsanvändning.

Kostnader för att införa ett nytt verktyg

Varje verktyg som tas in i en organisation är dyrt.

1. Det kostar i utvärdering av vilket verktyg som ska tas in, det ska utses ansvariga och etableras en förvaltningsorganisation.
2. Säkerhetsgranskning, leverantörsutvärdering och arkitekturrådsprocesser ska utföras och godkännas.
3. Någon ska ta på sig eventuella licenskostnaden, och kanske ska denna kostnad nycklas ut till användarna vilket kräver sina administrativa rutiner och interna systemstöd.
4. Ofta ska verktyget dessutom integreras i övriga IT-landskapet med API-integrationer, användarhantering, behörighetsgrupper och liknande. Detta kräver en utvecklingsinsats som ska prioriteras in.
5. Utbildning behöver sättas till och en supportorganisation för first line support.
6. Produktansvariga och leverantörskontaktsansvariga ska utses, informeras och fasas in i rutinerna kring dessa arbetsuppgifter.

Självklart kostar allt detta pengar och möda - och kommer med viss risk. Processer som tidigare fungerat, om än kanske taffligt, kanske slutar fungera med ett nytt verktyg som eventuellt visar sig vara trassligt att jobba med.

...men...

Det som lätt händer med ”ett verktyg för var sak” är därför att man först skaffar ett system av ”preferred supplier”. Man har en lista på leverantörer av IT-verktyg som redan levererar till organisationen, och så går man till dessa först och frågar efter verktyg. Det finns många stora mjukvaruorganisationer som lever på detta fenomen: IBM, HP, MicroFocus, Borland, Microsoft o.s.v. Alla dessa organisationer anstränger sig för att köpa upp andra leverantörer och således alltid ha verktyg för allt. Oavsett vilken leverantör vi pratar om har de nästan alltid ett verktyg som kan göra det vi önskar. Tyvärr driver det verktygsfloran mot stora enterprise-verktyg. Om ett team t.ex. vill automatisera tester mot sina API:er men inte kan välja de verktyg som är närmast till hands på grund av preffered suppliers hamnar man med testautomatiseringsverktyg som klarar allt och då kommer man att landa i stora och dyra verktyg som kräver mycket specialistkompetens och som är krångliga att fasa in i byggpipelines. Man hamnar på oavkortat på Tricentis Tosca, Microfocus UFT eller liknande istället för lättviktiga verktyg som språkgenerella webclients eller Postman.

Den typ av verktygsval man då hamnar på passar egentligen inte någon - och de blir oanvända eller har usel verkningsgrad.

Detta får med sig ytterligare nya kostander och gnissel:

• Långdragna införandetider för nya idéer. Tid är pengar.
• Svårt att byta enklare verktyg när bättre dyker upp.
• Personalomsättning för att medarbetare inte trivs för att de kommer långt från till synes enkla beslut som påverkar dem. Kostnaden för att lära upp nya människor i organsiation och verktyg är hög.
• Tröskel-effekt: Ved är kostnaden för att man inte sätter igång med testautomatisering eftersom man inte får använda ett verktyg som man redan är effektiv i.
• Ineffektiva medarbetare som inte får jobba med de verktyg de gillar, kan och arbetar smidigt med.
• Gnissel från ledningen som tycker att medarbetarna är motvilliga att ta till sig arbetssätt och att lära nytt - när de bara inte är sugna på att lära sig just detta verktyg.

Tankevurpan

Det finns en uppenbar tankevurpa här, och det är att det alltid är dyrt och krångligt att byta ut verktyg om man råkar välja fel. Om det är stora arkitekturpåverkande lösningar kan det vara värt att göra rigorösa utvärderingar inför dyra investeringar.
För små verktyg och utilities är det ofta mycket enkelt och smidigt att byta om man är missnöjd eller något bättre kommer ens väg.

Ett till argument man ofta hör på samma tema är att tänk om någon annan ska ta över lösningen, om varje team har sina egna verktyg måste vi ju lära upp dem på mängder av verktyg. Det ligger en sanning i detta, men man överskattar svårt hur krångligt det är att komma in och ta över någon annans tester i ett färdigt ramverk. Hela kodbasen är ju ett skolexempel på hur man ska jobba vidare.

Egentligen ligger sällan komplexiteten i själva verktygen. Har man lärt sig ett verktyg för API-tester lär man sig snabbt ett annat, för begreppen är likartade och funktionaliteten relativt analog.

På samma sätt:

• Det tar mer tid att lära sig git, maven/Javamiljö än att lära sig Java.
• Det tar mer tid att lära sig om target, nuget och TFS/Azure än att lära sig utveckla i C#
• Det tar mer tid att lära sig API:er än att lära sig ett verktyg för API:er.

Att sedan byta från Eclipse till IntelliJ eller liknande transformering är relativt enkelt. Visst är det en del utforskande och lärtid inblandat, men jämfört med att utforksa maven och olika bibliotek för funktionalitet är det försumbart i sammanhanget.

Den givna lösningen

Open Source software, där så funkar.

• Smidiga leverantörsutvärdering
• Ofta enormt tillgänglig och support
• Skalar fantastiskt väl
• Massa små smidiga verktyg - lätt att hitta något som passar som handen i handsken