Ryktene om Smittestopps død er overdrevet. Appen har blitt en zombie. Det uønskede barnet, unnfanget av myndighetenes teknologioptimisme, lever på nåde på norske mobiltelefoner.

Hva kan vi lære av denne tragedien? Fem perspektiver.

Innovasjon

I mars 2020 var det krise. Både kunnskapen om koronaviruset og pandemiberedskapen var mangelfull. De mest inngripende tiltakene siden krigen ble innført.

Hvordan lykkes med innovasjon i en slik krisesituasjon, i et ukjent landskap? Det finnes ingen fasit, men en mye brukt oppskrift ser omtrent sånn ut:

Generer så mange ideer som mulig.

Lag prototyper for de mest lovende ideene, side om side.

Få tidlig tilbakemelding fra reell bruk.

Gå videre med de løsningene som gir verdi.

Gå til steg 3.

Utviklingen av SmittestoppV1 låste seg fra starten på et løsningsmønster. Framfor å heve blikket eller invitere andre til å bidra, hoppet myndighetene ned i skyttergrava og kastet granater på kritikerne. Mulighetsrommet for innovasjon ble lukket. Til jul kom riktignok SmittestoppV2 med innovasjonen desentralisert kontaktsporing. Det åpnet opp for Anonyme Tokens, et eksternt bidrag for innebygd personvern. Deretter stoppet maskineriet helt.  

Smittestopp har gitt oss skylapper. Mulighetstrommet er større. Hva med desentralisert besøksregistrering, ultra-wideband framfor bluetooth og spesiallagede armbånd eller brikker framfor telefoner? Dette er bare noen få eksempler på ideer, gitt at vi ønsker å innovere med tanke på framtidig digital smittesporing.

Produktutvikling

En kollega skrev om Smittestopp april 2020, etter at ideen var kjent, før selve appen var lansert (mine redigeringer og uthevinger):

Men er det nok til å få over 3 000 000 brukere på rekordtid? ...Jeg har ikke sett appen eller prøvd den, men har lyst til å si litt om jobben FHI står ovenfor når det kommer til å få brukere.

Alle som jobber med brukerakvisisjon og brukeraktivisering vet at det er beinhard jobbing. Ikke alle er like heldige å ha markedsmusklene til DNB og løsningen på et like stort hverdagsproblem som det for eksempel Vipps løste. Vipps hadde 400 000 nedlastinger første måned, og i løpet av fem måneder rundet de 1 000 000 «Vippsere». Dette er blant landets beste historier på mange nedlastninger på kort tid. Men - om mine notater stemmer - er dette offisielle tall på nedlastinger, og ikke brukere. Det er nemlig forskjell på det å skaffe appen, og det å bruke den.

Mange avfeide denne innvendingen, og argumenterte med dugnadsånd og krise. Ved lansering av SmittestoppV1 så det ut som de skulle få rett. Men nedlastingene stoppet brått, og utbredelsen er milevis unna de 60% av befolkningen som var målsetningen.

I tillegg til helbom på brukermassen, har myndighetene gjort en klassisk tabbe: Et digitalt produkt blir aldri ferdig! La oss ta et eksempel. Aftenpostens overskrift er "Under 1 av 20 smittetilfeller deles i Smittestopp-appen", og FHI uttaler at "...men det virker også som at ikke alle som blir smittet, husker å varsle gjennom appen". Hvordan kan man få flere til å varsle når de er smittet? Nedenfor er informasjonen man får på Helsenorge ved positiv test:

Her er det ingen oppfordring til å varsle med Smittestopp. Det er heller ikke nevnt på lenken "Se hva du må gjøre for å beskytte andre".

Etter at SmittestoppV2 ble lansert, har den fått seile sin egen sjø. Digital produktutvikling krever fortløpende lytting, læring og forbedring fra vugge til grav.

Systemtenking

If we have a system of improvement, that's directed at improving the parts taken separately, you can be absolutely sure that the performance of the whole will not be improved - Russ Ackoff

Personlig mener jeg at hvis vi vil ha hverdagen og friheten tilbake, må vi ha flest mulig som laster ned denne appen. At man vil ha lengre tid med inngripende andre tiltak, blir jo selvfølgelig også et politisk valg for de som ikke velger å ikke bruke dette. Erna Solberg, 16. april 2020

Systemtenking lærer oss at vi må se på helheten, ikke de ulike delene systemet består av. I sin enøyde teknologioptimisme så myndighetene bort fra at appen er en begrenset del av en sammensatt helhet. Det sosiotekniske systemet, mennesker og tillit, ble enten glemt eller tatt for gitt. Tekniske løsninger lever ikke isolert fra samfunnet de skal brukes i.

Mangelen på systemtenking stammer sannsynligvis helt fra den opprinnelige forskningsartikkelen fra Coronavirus Fraser Group ved Oxford-universitetet, som har hatt enorm innflytelse internasjonalt. Den presenterer en teoretisk matematisk modell, med en hypotese om at en app kan stoppe spredningen av viruset:

The use of a contact-tracing app that builds a memory of proximity contacts and immediately notifies contacts of positive cases would be sufficient to stop the epidemic if used by enough people, in particular when combined with other measures such as physical distancing.

Vi vet nå at Smittestopp ikke er en game-changer. Systemtenking-perspektivet kunne allkevel gitt oss bedre svar.

Tillit

Nordmenn har stor tillit til myndighetene. Historien om Smittestopp ga oss to fundamentale lærdommer om tillit:

Myndighetene kan ikke ta befolkningens tillit for gitt. Tilliten i det norske samfunnet er bygget opp over lang tid, basert på rettferdighet, åpenhet, demokrati og menneskerettigheter. Men tilliten forsvinner som dugg for solen når den blir misbrukt.


Tillit kan ikke være en unnskyldning for å bryte personvernlovgivingen. Myndighetene kan ikke si "fortell oss alt, stol på oss, vi skal ikke misbruke informasjonen om deg" som begrunnelse for å høste uforholdsmessige mengder personopplysninger om oss.

Personvern

Årsaken til SmittestoppV1-havariet var brudd på personvernlovgivingen. At helseministeren og FHI i etterkant forsøkte å hevde at de allikevel var på rett side av loven er flaut, trist og skummelt. Myndigheter og politikere trenger et kompetanseløft på personvern.

At personvernet landet på riktig side i historien om Smittestopp, bør vi alle være glade for.

Epilog

Den viktigste lærdommen fra Smittestopp er at vi må investere i framtidig beredskap. Det bør ikke baseres på ensidig teknologioptimisme, men en helhetlig tilnærming innenfor rettstatens rammer. Ved å ta lærdom fra innovasjon, produktutvikling, systemutvikling, tillit og personvern, kan man sannsynligvis finne gode teknologibaserte løsninger som bidrar i kampen mot framtidige pandemier.

Smittestopp antemortem

Taking on the multifaceted role of facilitator can be intimidating. Get started by playing to your strengths.

Quick – Conjure up an image of a “facilitator.” What pops into your head first? As a UX designer, my image is heavily influenced by the era of the “Google Design Sprint.” I see a thoroughly planned workshop, with post-its covering every surface available. And the facilitator herself? Whiteboard marker in hand, she is a commanding presence in the front of the room and a major participant in discussions.



But facilitation is so much more than just this. Though a post-it wielding workshop leader is one very visible form of facilitation, facilitation as a tool that can be used in a wide variety of situations and take many forms. Unfortunately, many people shy away from facilitation because they do not feel comfortable with this traditional style – even though their teams desperately need the help.

The goals of facilitation

If you have a great team with high psychological safety and impeccable communication skills, you may be able to get by without a facilitator on your team. For the majority of us however, facilitation skills are a necessity as there are a couple of things that tend to go awry when groups of people work together. Have you ever scheduled a meeting to land a direction, discussed the issue for an hour, but left with no clear answer? Or been in a water cooler discussion with a colleague where you thought you disagreed, but found out that you were actually talking about the same thing? What about when a workshop is taken over by a strong personality, or even worse – people don’t share their opinions because there is a HiPPO in the room.


It is in these situations a facilitator can really shine. They can help to guide a group’s output, help participants understand each other’s viewpoints, create alignment and shared ownership, and moderate discussions so that everyone can participate. But there are many ways to do this, not all of which look like the typical sprint facilitator.

Like leadership, facilitation has many different styles.

Because facilitation has such a wide variety of goals, it can take a variety of forms. A facilitator can be the focal point at the front of the room, or working in the trenches. They can focus on creating engagement and participation, or ensuring useful output. Generally, facilitation falls into four “styles”:



The Energizer: Motivates people to think creatively and participate. Has a contagious energy.

The Driver: Keeps everyone on schedule, and maintains forward progress. Focuses on landing decisions or getting to the finish line.

The Diplomat: Builds trust, good will, and collaboration within the group. Tuned into individual needs and attitudes in the group.

The Interpreter: Reveals hidden connections and sees the big picture. Picks up on the essence of ideas and translates participants’ loose thoughts into clear terms.


Know your style: Play to your strengths and know your weaknesses.

An experienced facilitator switches between these styles to meet the needs of the group and situation. They put on their Energizer hat when motivation is low, but just as easily take a step back into the Interpreter when the conversation demands it. For most facilitators just getting started however, one or two of these roles comes more naturally than the others. Don’t try to be an Energizer just because that is what a typical Design Sprint facilitator looks like. Like leadership, facilitation works best if you play off of your strengths, personality and style. Weak on getting participation? Ally yourself with a participant who is good at cracking jokes and putting everyone at ease. Weak on ensuring outcomes? Display a digital timer on the board, or give a participant responsibility to watch the clock. By knowing your facilitation style, you can better play to your strengths and find ways to work around your weaknesses to step up in a big way for your team.


Happy facilitating!

Facilitation: What’s your style?

Vi laget nettopp et prosjekt helt uten automatiske tester. Hvordan gikk det?

Hvis vi går tilbake noen år var det svært vanlig å drive såkalt testdrevet utvikling. Testene skulle skrives først, så koden som fikk testene til å passere.

På den måten skulle du tvinges til å tenke gjennom alle scenarier som skulle oppstå, blant annet ved at hjørnetilfeller kom frem i lyset så fort som mulig.

Mange av oss fikk dette inn, om ikke med morsmelken, så enten i starten av karrieren, eller som en av mange introduksjoner til programmering når vi var på ett av mange programmeringskurs noen år tilbake. Et av de mest populære eksemplene var Uncle Bobs Bowling Kata


Man kan argumentere for at dette hadde sin verdi når det gjelder å løse et helt spesifikt problem med rigide regler.

Å kjøre samme tilnærming på et avgrenset område, f.eks. beregning av helligdager eller virkedager, kan vi på samme måte se nytten,
men når det gjelder størstedelen av produktene vi arbeider med dag-til-dag, er å skrive tester først kanskje ikke den beste tilnærmingen.

Mer unntaket enn regelen har vi ikke helt klart for oss hva vi skal lage, og i alle fall ikke hvordan det skal implementeres.

For oss som var med på større prosjekter var det også vanlig med verktøy som Sonar eller Jacoco som automatisk målte testdekning, der det gjerne var et krav om at dette skulle ha en viss, gjerne svært høy prosentandel av koden som var skrevet.

Konsekvensen var ofte at man skrev tester som i seg selv ga liten verdi, men testet kode som hittil var utestet, og ga uttelling på testrapporter.

Siden vi stort sett har beveget oss i mer smidig retning, hvor så hyppige produksjonssettinger som mulig er et uttalt mål, er naturlig nok også koden som blir lagt ut til brukere langt mindre i volum. Det vil derfor være kort vei til å kunne rette eventuelle feil som blir oppdaget i miljøet der de reelle brukerene tross alt oppholder seg.

Tester trenger også vedlikehold som alt annet. Det er ikke bare selve kodebasen man må forholde seg til, hver eneste bygging på utviklermaskinen vil typisk kjøre samtlige tester for å forsikre utvikler om at alt fortsatt er i vater.

Vi bygget nettopp en helt ny applikasjon der vi droppet å skrive en eneste test. Under utvikling opplevde jeg sjelden som utvikler at jeg var usikker på om det jeg hadde endret på ville føre til utilsiktede endringer.

Det skal sies at applikasjonen vi laget var forholdsvis enkel, med få krav til ytelse og skalering. Vi endte med en backend med noen få REST-endepunkter, og et funksjonelt språk til frontenden. Det var aldri et prinsipp for oss ikke å ha tester. Hadde vi sett verdien av det hadde vi innført tester der det var behov for umiddelbart.

Til nå har vi, bank i bordet, ikke fått noen feilrapporter fra første prodsetting.

En av de viktigste grunnene til å ha tester, er at en utvikler skal kunne være trygg på at endringene hennes ikke fører til sideeffekter.

Det vi har funnet ut har vært verdifullt på vårt prosjekt, har vært å fokusere på å teste applikasjoners oppførsel.
Finn ut hva som er det mest kritiske for din applikasjon og begynn der. Tilbyr applikasjonen betaling, begynn med å teste at den viktigste funksjonaliteten fungerer som den skal. At ordrenummer, varenummer, betalingsreferanser o.l. faktisk ikke lager kjipe
situasjoner for brukerne er en selvfølge å få avdekket tidlig i utviklingsprosessen, men skal også sørge for at de som utvikler applikasjonen skal få en god forståelse av systemet.

Mye av den helt vanlige vaniljefunksjonaliteten til en applikasjon er derimot ofte såpass rett frem at man kanskje ikke trenger all verdens tester.

Som med alt annet blir også dette en kost/nytte - vurdering. Som utvikler bør du begynne med det som er mest sårbart og kritisk, eller det som åpner for at andre utviklere kan trå feil.

Merk her at jeg bare snakker om automatiske tester. Brukertesting, sikkerhetstesting, og ytelsestesting blir en helt annen skål!

Det er ofte en god ting å slette kode når man er inne i refaktorering av en applikasjon, tester burde heller ikke være fredet.




Hvorfor vi skal droppe automatiske tester

Er du som meg — fersk ut av studiet med lite reell arbeidserfaring? Er du selvutnevnt toppkonsulent med mange års bransjeerfaring innen smidig arbeidsmetodikk ? Uavhengig av hvem du er, vil jeg tro at nettopp du kan ha godt av å lese Accelerate.




Dette blogginnlegget er ikke en oppsummering av Accelerate; hensikten er å gi en kort beskrivelse av eget læringsutbytte for å inspirere andre til å lese boka. Accelerate kalles ofte utvikleres bibel og tar for seg digital produktutvikling i lys av DevOps. På tross av det tydelige tekniske fokuset er det en nyttig bok å lese for alle som jobber i selskaper hvor digitale flater er en sentral del av verdiforslaget — alt fra bank og finans til retail. For effektivt å kommunisere læringsutbyttet forsøker jeg å besvare følgende to spørsmål:

1) Hvordan kan forretningsrådgivere bidra til å drive god digital produktutvikling?

2) Hva kan man lære av Accelerate som ikke direkte omhandler digital produktutvikling?

Hvordan kan forretningsrådgivere bidra til å drive god digital produktutvikling?

Dette spørsmålet har et todelt svar. For det første virker boka omforenende ved å bidra til forståelse for prinsipper og begreper fra Agile og DevOps, og for det andre tilbyr den konkrete verktøy for hvordan man øker kvaliteten på digital produktutvikling.

Utviklere er godt kjent med prinsipper og begreper fra Agile og DevOps. Disse legger føringer for hvordan man jobber med sprinter i mindre team, hvor hyppige og mindre leveranser legger til rette for høy leveransehastighet og kode av høy kvalitet. Dersom man jobber sammen med utviklingsteam er det derfor viktig med god kjennskap til de samme prinsippene og begrepene for å kunne kommunisere godt sammen. Misforståelser som følge av uklar kommunikasjon reduserer både hastigheten og kvaliteten på arbeidet, og et første steg for å unngå dette kan derfor være å lese Accelerate. Ved å omforenes om de samme begrepene vil man i fellesskap yte bedre.

I tillegg til å virke omforenende tilbyr Accelerate konkrete parametere for å måle kvaliteten på digital produktutvikling, og konkrete nøkkelkapabiliteter for å forbedre selskapers evne til å drive digital produktutvikling. Boka åpner med å påstå at alle selskaper er avhengig av digitale løsninger for å lykkes ettersom forbrukere og konsumenter av tjenester, uavhengig av bransje, forventer sømløse digitale kontaktflater. For å vite om man lykkes med digital produktutvikling må man kunne måle kvaliteten på utviklingen, og Accelerate foreslår fire objektive parametere som tar for seg både utviklingshastighet og -kvalitet. Ved hjelp av disse parameterne kan man isolere selskapene som lykkes og lære av disse uten tidligere bias. Fellestrekk fra disse selskapene har ledet frem til nøkkelkapabiliteter man kan anvende for å lykkes med digital produktutvikling. Accelerate virker dermed som en verktøykasse.

Hva kan man lære av Accelerate som ikke direkte omhandler digital produktutvikling?

Også dette spørsmålet har et todelt svar. For det første bidrar Accelerate gjennom DevOps til å forstå viktigheten av å vektlegge resultater heller enn gjøremål, og helheten heller enn enkelte team. Den andre delen leses ut av bokas fokus på faktabaserte beslutninger og anbefalinger, og hvordan det er viktig for alle beslutningstakere.

«Du har ikke gjort en dritt før du har pusha til prod»; under høstens onboarding ble dette løftet frem som et mantra for alle utviklerne i Bekk. Sagt med andre ord skal man måle kvaliteten på det man produserer, heller enn prosessen som kreves for å komme i mål. I tillegg til dette fokuserer Accelerate, basert direkte på prinsipper fra DevOps, på viktigheten av å omforenes om felles mål. Kjernen i DevOps er å knytte digital produktutvikling (software developement) til forvaltning av kode (operations) for nettopp å sikre både utviklingshastighet og -kvalitet. Dette kan man lære av selv om man ikke jobber direkte med digital produktutvikling — mål det man produserer, og sørg for at man jobber mot felles mål. Dersom man sørger for autonome team med få gjensidige avhengigheter vil man jobbe effektivt med høy grad av eierskap til egne arbeidsoppgaver. Gjennom hyppige tilbakemeldinger vil man sikre felles forankring om hva man ønsker å oppnå, og man vil raskere kunne gjøre endringer om man er på galt spor. Dette er arbeidsmetodikk som er nyttig for alt fra konsulenter og deres kunder, salg- og markedsavdelinger med tett kundekontakt og F&U i dialog med produksjonsavdelinger.

Datadreven argumentasjon og beslutninger kan testes og måles, og dermed verifiseres. Grunnen til at Accelerate er en bok man kan stole på er nettopp at den er skrevet basert på fire år med forskning og et solid beslutningsgrunnlag. Én av tre deler i boka beskriver forskningsmetoden, og dette skaper troverdighet hos leseren. Dette i seg selv er noe man kan lære av. Faktabaserte og datadrevne beslutninger har tyngde uavhengig av hvem som presenterer dem, så lenge dataen i seg selv er pålitelig. Alle yrkesaktive burde derfor tilstrebe å basere argumentasjon og beslutninger på et godt datagrunnlag. Ved å gjøre dette skaper man troverdighet og tar bedre beslutninger, uavhengig av om vitnemålet fremdeles lukter printer eller om luggen er så grå at det ikke er rom for mer erfaring.

Avslutningsvis vil jeg komme med en genuin oppfordring til alle som på en eller annen måte jobber med digital produktutvikling: la Accelerate være en førjulsgave til deg selv. Hvis du er nysgjerrig på hvordan fagmiljøet i Bekk jobber med disse temaene vil vår julekalender forhåpentligvis være til inspirasjon.

Hvorfor bør alle lese Accelerate?

When working with large tables with many rows and columns you might find that your application is starting to lag. Especially if your table has a lot of custom styles, clickable rows or sortable columns, rendering can become an issue.

In this post I'll show you how you can lazy render your table to make it fast and snappy!

What is lazy rendering

Lazy rendering means that you only render what you need to display. With very large tables we want to avoid rendering all the rows as we can't see them anyway. By only rendering what we need we can speed up our application and make it smooth to interact with.

How does it work

When drawing up our table we don't want to render all the rows. We add a filler row in the beginning and at the end of our table which will increase/decrease in size as we scroll. We will need a listener to monitor how far down we have scrolled and then calculate how large our filler rows should be. We will also need to calculate which rows we should render and which we should not. In order to make scrolling smooth I recommend rendering more rows than what is visible for the user. This way we won't experience that the table is flickering when scrolling fast.

So although we might have thousands of rows, when inspecting our code it will look something like this:

Let's code!

The magic will happen inside the table body, so lets start making that.
We will need some state variables to store values for how far we have scrolled, which index in our data array we should start rendering from, and which index in the data array should be the last to be render.

Static values

We will also need some static values for our calculations later. We will need to know how large each row is and how large the visible display is, in this case the screen height. An offset is needed so that we render a bit more than what we see. I want to render twice as many rows as I actually need to make scrolling smooth. Finally we need to know how many rows we should render at a time.



Calculating which rows to display

As already mentioned we want to render twice as many rows as we need. About half of those rows should be on the top, and the other half at the bottom. This way scrolling both ways will be smooth.

Then we need to find which index in our array should be the first to be rendered and which should be the last.

This method is a CallBack so that we can call it from a useEffect later on. If our data set changes in length we will need to recalculate the start and end position.

Add a scroll listener

Attach a listener to the scroll event on the window. This function will run every time the scroll changes.


We add throttle in order to optimize our scroll. This is done so we don't call our onScroll function on absolutely every pixel we scroll as that will be a bit excessive. Now it will only be invoked on every 100 millisecond. 

We also need to make sure our calculations are run when we first render our page, even before we have started to scroll. So let's add this

Adding our rows

Finally we can add our rows. We will add a filler row at the top and bottom.Then we will add the rows we want to actually render.


And now we're done!

You can see the entire code in sandbox


How to lazy render large data tables to up performance

Drypp er en lavterskel podcast fra Bekk. I denne episoden snakker vi om nudging.

2-Dec

Today's posts

Smittestopp antemortem

Facilitation: What’s your style?

Hvorfor vi skal droppe automatiske tester

Hvorfor bør alle lese Accelerate?

How to lazy render large data tables to up performance

Hvordan bruker vi nudging? (Del 2 av 3)