Vær kedelig

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
Kommentarer (2)
Jn Madsen

De fleste gode ideer er i virkeligheden "bare" en ny udnyttelse af eksisterende teknologier.
Ergo,- de fleste nye ideer kan designes med kendte og gennemprøvede metoder.

Det nye, smarte og genialt designede hus, det skal stadig bygges af en murer, en tømrer, en vvs'er osv osv.
-Med mindre det nye netop består af nye materiale valg.

Jeg har set flere gode ideer blive kvalt i netop forkerte materiale -og håndværker valg,- allerede i starten på støbningen af fundamentet til huset. Det giver alverdens problemer kort tid efter,- men tager tid, energi og ressourcer fra udførelse af den oprindelige ide.

Jeg ser også at problemstillingen kan opstå, hvis de personer der udvælges til at implementere en teknologi,- ikke har oplevet teknologien vokse. Et design kan være godt hvis det ikke skal være for stort,- men designet skal måske være helt anderledes, hvis ydelsen pludseligt vokser med faktor 1000. Det er her de "gamle rotter" i faget kommer på banen. De har set det meste før og laver ikke de himmelråbende fejl.

K.I.S.S. - ganske simpelt.

Alex R. Tomkiewicz

Det jeg får ud af at læse de linkede slides er nu ikke at man skal være kedelig. Det er primært at man, udover fokus på det spændende UX man laver, skal have fokus på infrastruktur, teknisk design, operations og supportprocesser. Sekundært at man skal vælge teknologi efter formålet: Smart UX kan gøres på stabil bagvedliggende teknologi. Cutting edge UX skal måske gøres på cutting edge bagvedliggende teknologi.

Dernæst kan man måske lære at man også skal tænke over organisation: Det er en fordel tidligt at sætte nogle folk til at tænke over operations og skalerbarhed. Man kan måske endda fristes til at teste systemernes performance og skalerbarhed inden man rammer muren?

Måske ikke revolutionær ny viden. Men muligvis godt input til udviklere som ikke først tænker på infrastruktur og til beslutningstagere som ikke først tænker på IT operations ;-)

Log ind eller Opret konto for at kommentere