Ordning och reda

Den här artikeln handlar om poängen med att ha ordning och reda. Min tanke är att ju mer symmetri och ju färre överraskningar det är desto bättre. Det minskar belastningen på vårt arbetsminne och minskar risken för misstag, speciellt under stress.

I ett exempel från levande livet fanns fyra testmiljöer och en produktionsmiljö. På det stora hela var miljöerna ganska lika med avseende på konfiguration men skiljde sig åt i prestanda. Två av test-miljöerna användes för test i teamen och de andra två för integrationstest.

I produktionsmiljön fanns fyra noder, två för publika applikationer och två för interna med failover mellan noderna för redundans. Till noderna fanns tre olika databaser kopplade. Testmiljöerna för integrationstest hade samma upplägg medan teamens testmiljöer bara hade en nod (av kostnadsskäl) som alla applikationer kördes på.

Alla nodnamn, databaskopplingar osv fanns väl dokumenterat och nedskrivet på en wiki där man klart och tydligt kunde se vad olika resurser hette. Alla förutsättningar fanns alltså för att det skulle bli rätt när något skulle uppdateras.

Så långt inget speciellt konstigt. Det jag tycker är intressant med det här fallet är namngivningen av noder och databaser och vad det ledde till. Av historiska skäl (förmodar jag) var namnen inte alltid logiska. Några exempel:

  • I produktion hette noderna prod1, prod2, prod3 och prod4 med interna appar på prod1 och 2 samt externa på prod3 och 4. I integrationstestmiljö 1 fanns samma symmetri (test1-test4) medan man i integrationstest2 (test5-test8) valt att kasta om noderna som interna och externa appar fanns på. Noderna test7 och 8 hade interna appar medan test5 och 6 hade externa.
  • Databasservrarna hade postfix i form av _dev, _test och _prod för att visa vilka miljöer de höre till. Själva databaserna hade en ”2″ på slutet av namnet för att visa att de hörde till miljö 2, dvs team-testmiljö2 eller integrationstestmiljö2. Om integrationstestmiljö 1 hade en databas som hette ”Kalle” hade integrationstestmiljö 2 en databas som hette ”Kalle2″. Märkligt nog fanns en databas som användes av en ”2″ miljö som hade 1 på slutet. Dessutom fanns en databasserver som inte följde mönstret och hade ett avvikande namn.

Egentligen var det inte så många avvikelser men jag tror att det fanns minst en i varje miljö utom i produktion.

Vad blev resultatet? Konkreta exempel på när det blivit fel under en vecka är att databasen som hörde till en ”2″ miljö blev uppdaterad i tron att den hörde till ”1″ miljön och att en lastbalanserare konfigurerades fel mot integrationstestmiljö2 eftersom noderna var omkastade. Inga allvarliga problem som inte gick att lösa, men det gick åt några timmar och skapade förvirring.

Vi människor är bra på att se mönster och symmetrier, det är en av våra styrkor. Låt oss då inte jobba mot den här egenskapen utan utnyttja den istället. Gör det lätt att göra rätt! Även om det var fullt möjligt att titta på wikin och se vad en resurs hade för namn så ökade det den kognitiva belastningen på ett onödigt sätt. Arbetsminnet, som redan är en bristvara hos utvecklare, måste lagra ännu lite mer data. Effekten blir fler fel och tröttare människor, förmodligen inte något någon eftersträvar.

Att underlätta kommunikation

Hos den kund där jag för tillfället sitter har man skrivbord med en skiva i bakkant av skrivbordet, dvs så det blir som en liten vägg bakom bildskärmen. Skivan är så hög att man inte ser över den utan att ställa sig upp. Lokalens utformning är sådan att vi mer eller mindre är tvingade att ha skrivborden i två rader med tre skrivbord bredvid varandra i varje rad.

Kommunikationen i teamet fungerade inte så bra så vi bestämde oss för att ta bort skivorna. Nu kan alla se alla och agera på de signaler som kommer från de andra i teamet.  Vi har visserligen gjort andra förändringar också men jag tror att det upplevda avståndet mellan individerna minskat och därmed ökat kommunikation och viljan att hjälpa varandra. Under alla omständigheter fungerar teamet mycket bättre idag.

Intressant nog tycker jag också att kommunikationen med det andra teamet, som sitter i samma lokal, också förbättrats. Förmodligen beror detta också på att vi har bättre visuell kontakt även med dom, men kanske också på att individerna i båda teamen blivit bättre på att vara  team-medlemmar.

Inom en snar framtid ska vi byta till smalare skrivbord vilket borde minska avståndet än mer. Framtiden får utvisa om det gör någon skillnad.