Det er et nobelt formål at ville undgå, at andre begår samme fejl, som en selv, hvilket Marty Weiner kastede sig ud i med GOTO-foredraget “Scaling Pinterest“, hvor han gav et indblik i både teknologivalg og organisatoriske udfordringer i at vokse fra en lille startup, der kun bestod af grundlæggerne samt et par ingeniører (heraf Marty) og til at være blevet et særdeles populært site med hundredevis af medarbejdere.
Jeg kunne godt lide hans tanke om, at vi andre kunne få lov at lave “nye spændende fejl” i stedet for at gentage hans, men erfaringen viser også, at det kan være svært at finde ud af, hvis råd, man skal følge – for der er mange om buddet. Ikke mindst er der massevis af teknologier, som tilbyder løsninger på ens skaleringsudfordringer, hvis bare man kaster sig over det nyeste og smarteste.
Martys råd var først og fremmest, at man skal holde det så simpelt som overhovedet muligt (doh!). Enhver teknologi tilføjer nye fejlmuligheder og nye kompetencer, som teamet skal samle op og holder sig ajour med. Ikke mindst mente Marty, at man bør gå efter det gennemprøvede, det velkendte, det udbredte. Den teknologi, hvor man kan finde svaret på sine spørgsmål på Google. Den teknologi, hvor man ikke pludselig viser sig at være teknologiens største bruger. Den bruger, der presser den derud, hvor de andre ikke har været og opdager, hvor grænsen for skaleringen går.
Præcis samme råd var en af hovedpointerne fra Oliver Nicholas, Engineering Manager hos Uber, der på samme track fortalte om deres udfordringer med succesfuldt “vokseværk”: Vælg kedelig teknologi. Lad være med at tro, at bare fordi du laver noget revolutionerende nyt, så har du også brug for at bygge det på en revolutionerende ny databaseplatform. Tænk dig om og hold det simpelt fra starten, så du ikke er for let at friste i en situation hvor det hele er ved at ramle om ørerne på udviklerteamet og nogen tilbyder dig et skinnende nyt teknologisk quick-fix.
Et par yderligere take-aways fra de to foredrag:
* Tænk logging og alerting ind fra starten
* Design efter, at alle dele af systemet kan fejle
* Pak din database ind i en service, så dem, der arbejder med de dele af produktet, der udvikler sig hurtigt, ikke kan lave graverende fejl
* Få sat unit tests og build environment op, den tid kommer godt igen
* Ansæt mest generalister og lær undervejs, hvad der er vigtigt
* Lav fejl – men dokumenter dem (f.eks. på en wiki) og lær af dem
Leave a Reply