Tre prinsipper for teknisk prototyping

..

Hvorfor lage tekniske prototyper?

Jeg jobbet med protyping av verktøy for design av strikkeplagg for strikkedesignere på Woolit høsten 2020. Det synes jeg var skikkelig vanskelig! Jeg satt med spørsmål som:

  1. Hvordan vet jeg om jeg bør prototype noe nå?
  2. Hvordan stiller jeg spørsmål som jeg kan svare på med en prototype?
  3. Hva er en prototype?
  4. Hva er effekten av å lage denne prototypen?

I dag føler jeg at jeg har bedre kontroll. Les resten hvis du er interessert i hva jeg har lært!

Takk til Sindre for tilbakemeldinger på utkast av denne teksten.

Prinsipp 1: start med en hypotese om hva du skal forbedre.

Hva er det du skal forbedre? Rettere sagt, hva er det du tror du kan forbedre? Skriv det ned. Det kan du bruke når du setter i gang hver dag.

Når du har gjort et stykke arbeid, kan du bruke hypotesen til å vurdere arbeidet ditt.

Prinsipp 2: test én ting av gangen.

Vi prototyper for å lære. Hvis vi tester fem ting om gangen og resultatet er bra, hvilken av de fem tingene var bra? Det er bedre å teste én ting av gangen.

Test det du ønsker å teste, hold resten fast. Hardkod API-responser. Tester du en brukerflyt, kan du ignorere alt utenfor den brukerflyten.

Når du tester én ting av gangen, er det også mye lettere å faktisk bli ferdig. Hvis det er mer du er interessert i, kan du alltids lage en ny prototype!

Prinsipp 3: loggfør progresjon hver dag.

Hva er din daglige rytme? Hvordan svarer du på spørsmålet “hva er viktig i dag” hver morgen?

Ser du på trello-lappene og river deg i håret fordi noen ikke skjønner at det er vanskelig å jobbe i kodebasen din? Stresser du over at API-et enda ikke er ferdig fordi hva “ferdig” betyr sklir ut?

Jeg ønsker å jobbe med mennesker som tenker sjæl og ønsker å levere høy kvalitet. Mitt triks for å tenke sjæl er å spørre meg selv “hva er viktig?” og tenke meg om.

Når du prototyper, leverer du kunnskap. Mottakeren av kunnskapen er deg selv i morgen, deg selv om en uke, og teamet når du er klar for å dele det du har lært. For å få til dette anbefaler jeg å skrive tekst.

Når du kommer på jobb om morgenen:

  1. Skriv ned hypotesen. Hva gjenstår? Eller er vi i mål?
  2. Hva er neste “to-timers-store utfordring” du kan gjøre?
  3. Er det noe du synes er vanskelig? Bør du spørre om hjelp?

Og når du har kommet et stykke:

  1. Hva var det du gjorde?
  2. Fungerte det?
  3. Hva er mulige neste steg?

Du skriver ikke dette for andre. Du skriver det for deg selv. Men det er mye lettere å oppsummere for andre hva du har lært når du allerede har kontroll på hva du har gjort og konkludert med!

Og bruk et verktøy for å loggføre som funker for deg. Jeg foretrekker plaintext i git. Jeg har sett designere få knallbra nytte av Figma og Figjam. Miro funker ofte bra hvis man er to eller flere. Og produktgjengen i Iterate har stålkontroll på Notion.

Appendix A: vi prototyper for å hypoteseteste en teori.

Teorien er hva vi tror vi kan forbedre. Men teorien er usikker. Hva betyr det egentlig at vi skal støtte grafnavigering i HOPS-terminalgrensesnittet? Det er sannelig ikke godt å si når ordene står alene uten noe å støtte seg på! Vi prototyper for å gi teorien tekstur. Målet vårt er å gjøre teorien bedre.

David Deutsch definerer en god teori som:

  1. Den forklarer noe interessant. På engelsk, “good explanations have reach”. Kan du faktisk forbedre noe i produktet? Hvis ikke, lager du ikke en teknisk produkt-prototype!
  2. Den er vanskelig å variere. Er det lett å erstatte teorien med noe annet? I Unicad har vi per 2023-03-28 en hypotese om at ingeniørselskaper er interessert i mer kontroll over beregningene sine. Kristian Collin Berge er kjapt ute med å stille spørsmål for å øke detaljgraden. Hvilke ingeniørselskaper? I hvilken kontekst? Hvilken rolle har personene i ingeniørselskapene, og hva er deres motivasjon? En ingeniør som prosjekterer bygg har kanskje mer enn nok å gjøre i hverdagen sin. En innovasjonsdirektør sitter kanskje og vurderer femten forskjellige initiativer, er nedlessed med ulest E-post, og har ikke ta stilling til løse ideer personen ikke kan gjøre noe konkret med. “ingeniørselskaper er interessert i mer kontroll over beregningene sine” kan bety mye forskjellig. “en byggingeniør som skal levere beregninger til rapport til tredjepart ønsker å ha én beregning som kan regne på én eller flere søyler” er spissere, og vanskeligere å variere gitt observasjoner.

Appendix B: smale utsagn gjør det lettere å jobbe sammen

jeg ønsker å gjøre det lettere for brukere å forstå HOPS-CLI-et første gang de møter det

er et smalt utsagn. Det er presist, mulig å teste, og hjelper teamet å koordinere.

jeg ønsker å gjøre HOPS lett

er et bredt, vagt utsagn. Hva betyr det, egentlig?

Jeg vil gå så langt som å si at det siste er ubrukelig! Selvfølgelig ønsker vi at det skal være lett for noen i Iterate å bruke HOPS. Men, for hvem? Til hva? Når?

Aforismer funker ikke når vi skal samle et team til å jobbe i samme retning. Da må vi snakke om verdi i kontekst! De generelle utsagnene dine om hva du mener er feil i verden foreslår jeg at du tar over en middag etter to øl.

Jeg har skissert litt på denne ideen i Prefer narrow statements.

Appendix C: sånn ser det ut når en ekspert lager en prototype

Eksperter som prototyper kan komme vanvittig langt. Hvordan ser det ut?

Her er et eksempel: Chris Nuernberger som bygger et streaming-system for probabilistisk programmering:

$ git log --pretty=format:"%h  %ai  %s" | cut -c -70
ce58ab7  2023-03-27 18:52:13 -0600  editing
feb6836  2023-03-27 18:50:56 -0600  one more edit
1ec005a  2023-03-27 18:49:32 -0600  Update README.md
3fd0a86  2023-03-27 18:46:03 -0600  adding link to api docs.
a03e0a1  2023-03-27 18:43:22 -0600  Added api docs.
21f8004  2023-03-27 18:17:48 -0600  Merge branch 'master' of github.co
5b6e479  2023-03-27 18:12:50 -0600  fixing examples and updating readm
bdb990f  2023-03-27 14:15:39 -0600  Updating readme
1aadf01  2023-03-27 14:11:00 -0600  Better pathway for take-n, less ty
3d4e48c  2023-03-27 11:34:17 -0600  Initial commit

Kilde: https://github.com/cnuernber/streams/commits/master

Noen observasjoner:

  1. Han utforsket et veldefinert problem. Hypotesen var noe ala “er det mulig å simulere monte-carlo-analyser uten å allokere?” Han trengte ikke snakke med folk for å få avklaringer.
  2. Han låste ned alle ting han ikke ønsket å bry seg om. Hvis han hadde prøvd å integrere med eksisterende systemer han har laget tidligere, feks dtype-next, hadde han ikke kommet i mål. I stedet brukte han verkøy han kjente godt, og gjorde så lite som mulig for å komme i mål.
  3. Han noterte seg ned hva han lærte underveis. Se på commit-loggen. Se på README, den beskriver hva han har gjort og hvorfor han har gjort det. Han kommuniserte tilbake til en relevant Slack-tråd der han, jeg og Daniel Slutsky hadde diskutert noe tidligere.

Se feks på `README.md`:

Simple programmatic model for infinite streams of numbers or objects primitive and doing arithmetic operations (in double space) on them. Provides basic structure for monte-carlo simulations.

Streams are an interesting concept as they are lazy noncaching and also not indexable.

Use fastmath/random for distributions and the transducers in kixi.stats.core for basic stats.

Konsist, kommer til poenget. Problemet er å kjøre monte-carlo-simuleringer.

Han gjør det tydelig har valgt nonocaching. Det gjør at:

  1. Vi tvinger oss til å loope over dataen én gang
  2. Som gir god ytelse
  3. Og gjør det mulig å slippe å allokere hele datasetttet i minne. Dette kjører på JVM, så vi har i utgangspunktet ganske stor minne bruk. Men jeg tror (tror!) denne måten å gjøre ting på kunne taklet så store sample-verdier som vi ønsker, uten å noen sinne gå tom for minne.

Som fersk utvikler, er det fullstendig urealistisk å forvente noe sånt av seg selv. Dette er en person som har jobbet for å bli kjempedyktig i 20 år, og aldri har stoppet å forvente mer av seg selv.

Men legg merke til tiden han brukte. Han holdt scope til noe han kunne få til på én dag. Det er lurt!

Start der. Hvor langt kan du komme på en dag? Kan du teste én ting i dag? Etter hvert som du blir bedre, kan den ene tingen være en større ting.

Appendix D: Kritikk og kommentarer på denne teksten

Har du innspill? Fyr løs! Kontakt meg sånn du vil. Hvis du er usikker, står det noen alternativer på https://teod.eu/.

“Prinsipp 1: start med en hypotese om hva du skal forbedre.” er vagt

“hypotese om hva du skal forbedre” er mange ord. Hva er det jeg egentlig mener?

  1. Definer et smalt problem først
  2. Så kan du tenke på hvordan du svarer på det problemet
  3. Når du har holdt på litt, kan du vurdere om svaret er “nei”, “ja” eller “vi vet ikke helt”.

Hvis du ikke starter med et mål, kommer du sannsynligvis til å gjøre noe uten å ha det du har gjort forankret i et solid “hvorfor”-svar.