Bør Norge eksportere velferdstjenester? Jeg intervjuer Oslos finansbyråd neste fredag

Jeg ble først oppmerksom på finansbyråd Robert Steen når vi ba ham om å holde åpningsinnlegg på Dataforeningens Software 2018. Som han selv sa på scenen: Å invitere en kommunepolitiker til å åpne en IT-konferanse kan virke litt rart. Men Robert Steen er en politiker som setter digital transformasjon på dagsorden, han har en bakgrunn fra oppstarten av FINN.no og han er lidenskapelig opptatt av tjenestedesign.

I etterkant av åpningsinnlegget på Software 2018 hadde jeg lyst til å sette meg ned med finansbyråden for en “alvorsprat” i Dataforeningens intervjuserie “Alvorlig Talt”. Samtalen blir filmet førstkommende fredag 1. juni. Du kan melde deg på for å delta på samtalen i vårt studio i Møllergata eller følge sendingen på nett.

Her er min introduksjon til temaene jeg håper vi vil dekke.

En fremtidsvisjon

Som alle gode visjonære starter Robert Steen med å male en trussel og en mulighet. Trusselen er en trussel mot selve sosial-demokratiet og velferdstaten vår.

Det er ingen tvil om at de fleste av oss forholder oss mye mer bevisst til tjenester fra selskaper som for eksempel Google, Udemy og Uber. Hva skjer når Google blir flinkere til å svare på helsespørsmål enn fastlegen din, når Udemy oppleves som en bedre utdannelsesinstitusjon enn folkeskolen og når Uber leverer et bedre transporttilbud enn Ruter? Folk vil gå over til de bedre tjenestene. Konsekvensen er at borgerne vil oppleve at skattepengene våre går til å betale for tjenester vi ikke benytter oss av og man vil bygge ned tjenestene. Men de private aktørene leverer ikke sine tjenester etter rettferdighetsprinsippene som er pilaren i vårt velferdssamfunn. Effekten vil være en konsekvens av mange små handlinger, ikke en demokratisk styrt og ønsket effekt.

Det offentlige Norge må innse at man er konkurranseutsatt og må selv være med på konkurransen. Og offentlig forvaltning er preget av et industrialiseringstankesett i stedet for et konkurransetankesett. IT styres etter et prinsipp om kostnadsbesparelse. Men dersom man skal lykkes i konkurransen må man ikke fokusere på effektivisering, man må fokusere på verdiskaping.

Her har Robert meg ombord med min egen entusiasme: Norge er et samfunn med en utrolig velferdsmodell og et av de mest digitale modne landene i verden. Vi burde eksportere velferdsteknologi.

Jeg tror på denne visjonen. Men jeg tror vi har kommet kortere på detaljene enn det byråden selv innser. Jeg håper vår samtale vil dreie seg rundt tre sentrale snubleblokker: For det første tror jeg vi fortsatt ikke vet hvordan vi skal forvalte systemene, for det andre tror jeg ikke vi vet hvilke tjenestereiser som har verdien vi leter etter og for det tredje lurer jeg på hvordan denne eksporten skal foregå.

Forvaltning av store systemporteføljer med “spaghettikode”

Det kjedelige og praktiske først. Robert beskriver at man i Oslo kommune har cirka 350 fagsystemer som gjør i stort sett det samme. Mange av systemene er preget av spaghettikode og mange små leverandører som ikke klarer å holde systemene i drift i tiden fremover. Som en som bruker mye av dagen min til å skrive egen kode eller vedlikeholde spaghettikode lurer jeg på hvordan man skal endre dette i praksis (bemerkning: En programmeres definisjon av “spaghettikode” er “kode som ikke var skrevet av meg”). Innen tankesettet rundt smidige metoder og moderne systemutvikling snakkes det ofte om negative stordriftsfordeler. Mens jeg kan anta at det å produsere brød eller bøker blir billigere dersom man har større produksjonsanlegg, så er dette ikke tilfelle med IT-prosjekter. I all enkelhet er suksessen til et prosjekt negativt korrelert med størrelsen.

Hvordan skal Oslo kommune forholde seg til disse hundrevis av systemene? Skal man starte nye store prosjekter som skal slå sammen mange av disse? Skal man erstatte skreddersydde systemer som brukes av erfarne saksbehandlere med generisk hyllevare?

Fremtidens borgerreiser

Det mer spennende punktet dreier seg om de borgerreisene som Robert bruker som eksempler. I god tjenestedesign-ånd har kommunen laget en underholdende, inspirerende og kreativ video om den fiktive Oslo-borgeren “Tim” og hans liv og familie fra unnfangelse til han selv får egne barn. Eksempelets makt er sterk og videoen om Tim viser at det er mulig å tenke nytt. Men. Men.

To av “borgerreisene” Robert bruker er barnehageplass og byggesøknader. Begge er temaer som interesserer meg mye om dagen og med det perspektivet vil jeg si at historien om Tim definitivt ikke treffer spikeren på hodet. Barnehageplass først: Min yngste er født i desember for 2,5 år siden. Alle med desemberbarn vet at det medfører utfordringer med barnehageplass på vårsemesteret. “Løpende opptak” var faktisk et valgløfte til Arbeiderpartiet ved kommunevalget i 2016. Jeg snakket litt om håpet med pedagogisk leder i avdelingen til storebror til vårt desemberbarn og hun påpekte en svakhet med løpende opptak: Så lenge hoveddelen av de ledige plassene i barnehager vil følge skolestart for de eldste, så er eneste mulighet for å ha et system som har rom for å ta opp flere barn i (for eksempel) januar dersom vi bruker midlertidig bemanning på våren eller har overkapasitet i bemanningen i barnehagen på høsten. Er det faktisk noe vi er villig til å betale for? Kanskje ikke. Som småbarnsforelder så er det ikke brukerreisen jeg tror er smertepunktet. (Når det er sagt synes jeg innføringen av det nye digitale verktøyet for samhandling mellom barnehage og hjem er spennende – selv om jeg ikke er flink til å bruke den)

Når det gjelder byggesøknader så bor jeg i et fortetningsområde i byen. Kort sagt: Som en som allerede bor her, så er det som regel negativt for meg når naboer vil bygge mer. Mange byggesaker er en nullsumspill og der noen taper privatliv, utsikt, sol eller ro, mens andre får plass. Slik må det være. Kommunens jobb med å balansere disse interessene i henhold til politiske prioriteringer bør ikke være lettvint.

Det viktige poenget er at det er mange ting der problemene stikker dypere enn det som digital transformasjon kan løse. Dette gjelder også hovedeksemplene til byråden. Jeg håper at vi i vår samtale kan gå inn på noen problemer som kommunen nå setter innsats bak å løse og hvordan man vet at man løser kjernen av problemet.

Eksport av velferdsteknologi

Av alle budskapene til Robert Steen så er det om eksport av velferdsteknolog det som fenger meg mest. Han dro selv fram at vi lever når en ny tidsalder blir til. Hva kan Norge bidra med til å skape denne tidsalderen? Både statlig og kommunal offentlig sektor har blitt mer åpene og deler av det de skaper for egen bruk. Jeg synes tanken på at dette vi skaper og lærer for oss selv kan bli en verdi vi kan selge eller endog gi bort til andre utenfor Norge.

Jeg håper vi får snakket om hvilke type løsninger som kan være grunnlag for å dele med andre og hvordan byråden ser for seg at man praktisk vil angripe denne problemstillingen.

Vi sees på fredag

Jeg blir inspirert av ledere som ser det større bildet og slike ledere som er folkevalgte er enda mer inspirerende. Men for å bli effektiv må en visjon ikke bare sette mål, men også finne og formidle riktig forståelse av de problemene som skal løses. Jeg vil prøve å ha en problemfokusert samtale med finansbyråden på fredag. Håper du vil bli med.

Posted in Non-technical, Norsk | Leave a comment

Teknologiledelse handler om å se menneskene – jeg intervjuer IT-direktør Torbjørn Larsen i NAV

For nesten nøyaktig tre uker siden var jeg så heldig at jeg fikk lov å sette meg ned med Torbjørn Larsen, IT-direktøren i NAV og prate med ham på video om hvordan man fornyer en stor offentlig virksomhet. NAV har de siste årene blitt et av de mest ettertraktede fagmiljøene for IT-folk og jeg tror dette er takket være Torbjørn. Konteksten av intervjuet var i Dataforeningen sitt nye samtaleprogram Alvorlig Talt.

I intervjuet får vi et innblikk i hvordan han tenker rundt IT ledelse. For meg er den viktigste lærdommen fra Torbjørn at en virkelig dyktig leder bruker tid med enkeltmenneskene. Det som skiller Torbjørn fra mange andre IT-ledere er at han tar seg tid til å sette seg ned one-on-one med folk fra alle lag i organisasjonen. Han både lærer og lærer bort i disse samtalene og jeg tror dette er grunnlaget for å endre kulturen i en bedrift.

I intervjuet får du høre om dette og du får også praktisk innsikt i hvordan man får til en overgang fra en organisasjon som kunne planlegge seg ihjel til en smidig organisasjon. Historien om den digital sykemeldingsløsningen er et godt eksempel på hvordan et autonomt team får mulighet til å levere en enkel tjeneste fra tanke til løsningen er i brukerne hender. Den første leveransen kom fort og var mager, men som Torbjørn sier: Dersom man ikke er litt flau over den første leveransen, har man tatt seg for god tid.

Du kan se hele interjvuet her:

PS: Neste Alvorlig Talt blir 1. juni med Oslo’s finansbyråd Robert Steen. Meld deg på (gratis) om du vil være i salen eller følge via streaming.

Posted in Non-technical, Norsk | Leave a comment

A wicked Java trick to make the JVM forget to check exceptions

I’ve long time been a critic of the mechanism of compiler checked exceptions in Java. Whether you love them or hate then, one thing is sure: There’s situations where you don’t want to have to deal with them. The solution in Java is to wrap a checked exception in new RuntimeException(e) but this gives long stack traces without adding useful information. Sometimes, we just want to tell the compiler to chill.

As it turns out this is possible, through some wicked abuse of the type erasure misfeature of Java-generics. Seeing this in action is instructive for understanding the inner workings for Java. Let’s go!

Here is what we want:

Notice that the businessLogic() neither catches IOException or declares that it throws IOException. Instead, the softenException() method removes the checkedness of the exception. When we run it, we get the following stack trace:

Huh! The exception being thrown in the main method is a NoSuchFileException, which is a subclass of IOException – a checked exception! How can that be? Why didn’t any of the methods in the program have to declare throws IOException?

Here’s the trick:

The checkednessRemover method uses a trick that reveals a few things about the inner workings of Java. First, the generic type argument T is bound to RuntimeException in order to fulfill the contract of softenException. This means that the expression throws T becomes throws RuntimeException, which the compiler interprets as if there was no exceptions thrown.

But the statement throw (T)e; theoretically should evaluate to throw (RuntimeException)e;. Since e is a NoSuchFileException, you would expect this statement to result in a ClassCastException. But the way generics work in Java, the type information is removed by the compiler. So instead, the bytecode reads as throw (Exception)e;, which is fine.

So this strange trick shows that the Java compiler removes generic information from the compiled code and that checked exceptions is purely a feature of the compiler. There are no runtime verifications of checked exceptions.

Would I recommend using this trick in production code? I don’t know. It’s pretty weird and may not be that useful, but I do use it myself when I’m feeling wicked. If nothing else, I hope learning about has given you some insights into the inner workings of Java.

Disclaimers: (1) I read about this trick somewhere else, but I cannot find the source any longer. I thought it was Heinz Kabutz’ excellent Java Specialist newsletter, but I can’t find the source. (2) This is also implemented in Project Lombok as @SneakyThrows. If you are using Lombok, you should under no circumstance reimplement the trick from this blog. Use @SneakyThrows instead.

Posted in Code, English, Java | 3 Comments

Fremtiden vi bygger med Software

As the year comes to an end, I describe some gloomy clouds in our future. This Norwegian language article was first published on the web site of the Norwegian Computing Association.

Hvilken fremtid overlater vi til våre barn og barnebarn? Endringstakten i samfunnet ser ikke ut til å sakke ned og en ting er klart: Programvaren som bygges i dag vil skape muligheter og problemer som vi så vidt kan se konturene av.

“Fremtiden vi skaper med programvare” er også tema for Dataforeningens konferanse Software 2018. Her er noen av utfordringene jeg personlig ser i årene som kommer.

Utfordring #1: Vil Bitcoins spise opp all strømmen vår? Bitcoin er en “virtuell valuta”. Et fantastisk eksperiment i økonomisk teori, kryptografi og liberalisme. Det baserer seg på at pengene i nettverket utveksles gjennom kryptografisk signerte meldinger og at disse meldingene valideres av nodene i det distribuerte nettverket ved at disse signererer “hovedboka”. Noden som signerer en blokk med transaksjoner på hovedboka mottar Bitcoin som insentiv for dette, men må ha fullført en “proof-of-work” for å motta gevinsten. Dette kalles “mining” (gruvedrift). Bitcoin er designet slik at denne arbeidsmengden er stadig økende.

Her møter vi en jernlov i økonomisk teori: Det kan ikke eksisterer gratis penger i et effektivt marked. Det betyr at kostnaden ved det påkrevde arbeidet må av nødvendighet tilnærme seg prisen for strømmen ved å utvinne den samme Bitcoinen i en public cloud som Amazon eller Azure.

Da får vi problemet: Når en Bitcoin nå omsettes for over $10,000 brukes en stadig økende mengde av verdens strømproduksjon til den essensielt meningsløse oppgaven å la maskiner løse tulleproblemer for å signere Bitcoin hovedboka. The Guardian estimerer at akkurat nå overskrider strømmen som brukes for å utvinne Bitcoins strømforbruket i hele Irland!

De miljømessige og økonomiske konsekvensene av dette er alvorlige. Vi bruker i dag enorme mengder strøm på helt unødvendige regneoperasjoner og det er ingen åpenbar måte å stoppe dette på!​​

Utfordring #2: Dataene om oss forråder oss. Samtidig som det blir mulig å utnytte større og større mengder med data, har tjenestene vi benytter på internett startet å samle inn mer og mer data om våre vaner, ønsker og preferanser. Tjenestenes livsblod er vår tid og oppmerksomhet og algoritmene som styrer dem optimaliseres uunngåelig for å gjøre oss avhengige.

Tristan Harris som har jobbet tre år som Googles designetikker, beskriver problemstillingen godt. Tjenester som Facebook og Youtube er avhengig av at vi bruker så mye tid som overhode mulig der slik at vi klikker på så mange annonser som mulig. I tillegg til de direkte konsekvensene av at Facebook kontrollerer en stadig større del av hva som kan sies har dette naturlige negative konsekvenser for oss som bruker opp tiden vår. Og ikke nok med det: Facebook sine algoritmer har oppdaget noe artig: Dersom vi blir sinte og provoserte bruker vi mer tid hos dem.

Selv tjenester som Netflix som ikke er avhengig av reklame for å tjene penger forsøker å bruke opp mest mulig av tiden vår. Algoritmene til Netflix har nemlig oppdaget at de som bruker Netflix minst er de som sier opp abonnementet sitt.

Utfordring (og løsning?) #3: Personvern og GDPR. 25. mai 2018 trer den nye Personvernforordningen (GDPR – General Data Protection Regulation) i kraft. Mange virksomheter kan da forvente et stort antall kunder som kommer til å kreve all data om seg utlevert på maskinlesbart format og de har kun en måned på å utlevere informasjonen før de er i brudd på forordningen.

Brudd på fordringen har en bøteramme på hundretalls millioner kroner. Naturligvis vil det ikke være hensiktsmessig for Datatilsynet å bruke de største bøtene i tide og utide. Men her er problemet: GDPR er ikke en norsk lov – det er en EU lov. En “forordning” gjelder i EUs medlemsland (og i dette tilfelle også i Norge) på lik linje med nasjonale lover. Så hva norske myndigheter mener er et rimelig bøtenivå kan være underordnet hva Tyskland, Frankrike eller Storbritannia (enn så lenge!) mener er et riktig bøtenivå. Og siden GDPR er den første forordningen som berører Norge i betydelig grad er dette helt upløyd mark!

Under EØS-avtalene kunne vi potensielt reservert oss mot å innføre GDPR, men det hadde egentlig ikke gjort situasjonen noe bedre: Norske bedrifter som leverer tjenester til EU-borgere må fortsatt forholde seg til lovgivingen (på lik linje Asiatiske og Amerikanske bedrifter).

Men GDPR er her av en god grunn: Når bedrifter som Facebook bruker data om oss på måter som kan være mer eller mindre i strid med våre interesser, så vil GDPR med høy sannsynlighet sette en stopper for dette. GDPR ville antageligvis også sette en stopper for saker som nå nylig når kriminelle stjal personinformasjon om 57 millioner kunder og sjåfører fra Uber. Det mest alvorlige her var ikke datatapet, men det at Uber holdt det skjult i et år. Under GDPR ville Uber antageligvis bli idømt høye nok bøter til at selskapets fremtid hadde stått i fare.

Kan vi løse fremtidens utfordringer med lovgiving? Utfordringene vi står ovenfor er nye og løsningene vil være ukjente. Men en ting er sikkert: Teknologien er uten følelser. Når Bitcoins spiser opp all strømmen i verden eller Facebook stjeler all tiden vår og gjør oss sinte så er det ikke fordi Bitcoins eller Facebook er slemme. Det er rett og slett fordi software ikke bryr seg.

Det er ikke noen tvil om at fremtiden byr på store utfordringer og muligheter når det gjelder bruk av programvare. Jeg gleder meg til Software 2018 – Dataforeningens flaggskipkonferanse som jeg selv er med på å arrangere. Da får vi se hvordan norske IT-organisasjoner bruker software til å forme fremtiden.

Posted in Non-technical, Norsk | Leave a comment

The same risks in every projects

To avoid the big problems with projects, everybody recommends risk management. At the same time, I’ve rarely seen risk management practiced effectively. Do we identify the same risks and do we actually prepare to handle them? The ironic thing is that I think most projects have the same top four risks. In this blogpost, I explore these common risks. To avoid exposing my customers and colleagues, the examples given is based on hearsay and not actual experience.

The biggest risk: Is the problem even worth solving?

The biggest risk of a project is that the problem we’re trying to solve is not worth solving. The project may have uncertain costs and will only save the company an insignificant amount of money, or we may be creating a product that nobody is interested in paying for. If what we’re doing is not worth doing, it doesn’t matter how well we’re doing it.

Lean startup recognizes this risk at the center of the process. This is why the Minimum Viable Product is such a strong concept. This is a great idea if the project is about developing a product for a market.

What if the project is about delivering something that a customer ordered? What if your customer ordered something that they don’t need? Your contract may protect you financially, but you will still have wasted your time working on something insignificant.

As an example: Everyone wants to develop chatbots today, but do you know how much you are currently spending on your human customer services representatives? Is it even worth reducing this cost?

Will the proposed solutions solve the problem in a reasonable way?

Even if we know the problem is real, will our solution actually address it? In the example of the chatbot, we expect that our customers will get their answers from the chatbot, so they won’t bother our (expensive) human operators. But what if our customers always end up transferring to a human after all? Many chatbots are nothing more than fancy, less usable, FAQ databases, which may be cheaper to implement anyway.

Do we have the means to execute our solution?

Even if the solution would solve the problem if properly used, do we have the skills, data, customer relationships and market conditions to execute it well and without extreme expenses? In the case of our chatbot, the chatbot won’t do us any good unless we have the people who can train it and the data to train it with. As technologies are becoming increasingly specialized, it’s often much less available skills than demand.

Do we have the processes to deal with fundamental risks?

When a fundamental risk materializes on a project that has been started, it may be very hard to actually deal with it. We had a project at my company where it turned out that after putting in a few person-years worth of effort, we realized that there was no value to the project. It took us two weeks from the realization until we had discussed the discovery sufficiently that everyone saw the same situation and that we had described the situation in a way that made the top management able to make an informed decision to terminate the project and cut our losses.

We’re not always so lucky. In many organizations, the inertia of a project is so large that there is no understood decision process that makes us able to terminate the project once we realize it’s a waste of effort.

Dealing with the fundamental risks

The three biggest risks to the value of any undertaking are:

  1. The problem may not actually be worth solving
  2. The solutions we select may not actually solve the problem
  3. We may be unable to actually master the solution effectively
  4. We may be unable to terminate out-of-control projects

If one or both of the first two risks actually materialize for your project, your current undertaking is a waste of effort. If the third occurs, it costs more than it’s worth. If the last occurs, you will be unable to stop the bleeding. All projects have these risks, but they may materialize differently. What are your fundamental project risks?

Posted in English, Non-technical | Leave a comment

Privacy concerns everywhere, but don’t panic!

Recently, my organization reached a big goal and we decided to celebrate by taking everyone out for dinner. What happened was a GDPR nightmare. Or was it?

We sent out a Google Form with three simple questions: 1. What’s your name, 2. Are you coming to the dinner? 3. Do you have any dietary constraints?

But wait!

According to article 4 of the GDPR, “‘personal data’ means any information relating to an identified or identifiable natural person”. Is the dietary constraints personal data? It certainly can be!

Julie wrote: “I’m a vegetarian”. That’s certainly personal information. Is it lawful to collect it? Jason wrote: “I’m allergic to shellfish”. That’s actually medical information. Fareed wrote: “I don’t eat pork”. Did we just collect data about his religious belief? Both medical information and religious beliefs are considered special categories of personal data, requiring stricter basis for processing.

But it gets worse: Google Forms doesn’t guarantee that the data is stored outside the US. As long as the US is a rogue nation, especially when it comes to privacy, article 45 will probably never allow for worryless transfer to the US. And I have to admit that when it comes to transfer to rogue nations, I really don’t know what to do.

So, what the heck, right? What’s going on here? Is the GDPR making everything impossible?

Not at all, we just have to start thinking in terms of common curtesy in a time when massive amounts of personal data is in danger of being misused. Let’s fix these problems!

The biggest problem is Google, and we’re all holding our breath on this one. Is Google going to provide sufficient control to comply with the GDPR after May 25th? We all hope so. If not, perhaps we need to find another place to collect the data. (Hey, Google! Norway is a great place for data centers – why don’t you leave the sinking ship that is the US?)

Second, collecting the data is lawful if we get the https://gdpr-info.eu/art-7-gdpr/consent of the data subject. Just add a checkbox saying “I consent that this information is used to pre-order the food”. We also have to provide transparent information to our hungry team members. “This information will be aggregated with the rest of the responses and used to place our order. It will only be read by Johannes. After the order is placed, the information will be deleted”. Remember to restrict access to the data as you promise and delete the data when you promise.

Yes, this means that you have to ask again for the next party. Don’t cry – that’s not that big of a hassle.

Finally, and most importantly, perhaps we should take a lesson from Data protection by design. Instead of asking if our members have dietary constraints, perhaps just ask the restaurant for the menu and ask everyone what they would like to order. A food order is (probably!) not personal data and then we sidestep the whole problem. Or we could just anonymize the dietary question.

What’s the point of this story?

Data protection is an everyday problem. It doesn’t just affect big IT systems. It affects all the small information streams within an organization.

But at the same time, data protection doesn’t require a project to carry out. It just requires you to follow a reasonable set of principles. It means you have to think about whether you have the consent of the person subject, whether you’re upfront about how the data will be used, whether you protect the data and that you consider whether you need personal information at all.

A huge disclaimer: I’m not a legal expert in any sense of the word. I may be grossly wrong in this article and I’d love to hear about it! Please comment!

Posted in English, Non-technical | 2 Comments

Using Trello and Google Forms to organize a conference

We’re running Mobile Era for the second year on October 5th-6th and I’d like to share some experience on how we’re using scripts and Trello to help with the organization effort. If you’d like automating simple tools, this is the article for you.

If you haven’t signed up for Mobile Era yet, you can leave a comment in this blog post for a discount code!

Google Forms is great! You can simply design pretty advanced forms and easily get responses. But after you get the responses, it’s a bit trickier. Similarly, Trello is great: Once you have your tasks in place, you can work on them easily by dragging and dropping. We decided to combine them with a little bit of script magic.

For a conference, one of the big tasks is to collect talk submissions and select who should get to speak at the conference. Here’s how we did it:

  1. A potential speaker submits a talk in our Google Forms call-for-presentation.
  2. Our magical script creates a card in a Trello board for the talk
  3. If the speaker updates the talk, the Trello card gets automatically updated (and marked with a special label)
  4. The program committee can comment on the card and move it around, safe in the knowledge that any work they do will be preserved even if the speaker updates the card

I started doing this with Trello’s email integration, but this fell apart when I wanted to update existing cards. Now I use the Trello API instead (there is a Zapier integration that has the same limitation, too). Here is the source code for my Google Forms script.

This is how you use it:

  1. Create a Trello board with an “Inbox” list and a “Updated” label. You will need to find Trello’s ID’s for these, which I leave as an exercise to the reader.
  2. Create a Trello API key and token at https://trello.com/app-key
  3. Create a new Google Form and set it up with the fields that you want
  4. In the Forms editor, open the “…” menu and select “Script Editor…”
  5. Copy the text from my gist into the Script Editor
  6. Update the autentication, idBoard, inboxList and updatedLabel values with the IDs from your Trello account
  7. Update “getCardName” and “getCardLabelIds” to include relevant fields from your form
  8. Run the function “sendAll” to send any existing form submissions to Trello. This will make Google Forms ask for permission to store the links between Trello cards and Form submissions.
  9. Add a trigger to “saveToTrello” on “On form submit”

The clunkiest part of the code in the gist is probably finding the values of a defined form field. This is also brittle if the form is changed, but what can you do, eh?

I’ve also started using information Trello to merge emails and save drafts for easily editing and sending. But that’s a story for another day.

A little bit of script can save a lot of tedium and help you extend tools like Trello and Google Forms to work together. I welcome your comments on how the script could be made even better!

Posted in Communities, English, Software Development | Leave a comment

How I learned to love GDPR and so can you

If you are working with software development as a developer, manager or tester, then you will be impacted by the General Data Protection Regulation (GDPR) – the new EU laws regarding data privacy. In many ways, the regulation is likely to have as big of an impact as the Y2K problem. But this time it’s because of a good cause! And you cannot ignore it, as the fines for doing so can be crippling. But for most people who find themselves face-to-face with GDPR it’s quite intimidating.

I hope this article can do something about that.

First, let’s say a few words about how to approach the regulation itself and then let’s look at some actions you should consider. I find the text of the regulation to be surprisingly well-written, but I wish I had a reading guide when I started out.

The actual text is officially published on http://ec.europa.eu. The text starts with 173 “recitals”. These are background considerations for the regulation. Even though they are well thought out and well written, they are not very much to the point. They are also often quite heavy to read, even if it’s for good reason (a perfect example is Recital 38 which talks about the data protection concerns of children). After the recitals are the actual 99 articles of the law, which are much easier to read. These are divided into chapters and many of the later sections are about the structure for enforcement, not for the actual regulation as it impacts most organizations.

Instead of reading the PDF, I recommend looking at https://gdpr-info.eu, which has organized the regulation in an easy-to-use structure. If you are responsible for an IT system, you need to understand at a minimum articles 1 through 50 and especially articles 5 through 35. Start by reading these.

Let’s look at some of the ways you may be surprised.

Surprise 1: Consent and test data

In order to collect and use personal data, you need to have permission to do so (article 6). For most people, this either means that you are required by law to use the information (for example medical information in a public health context) or that you have obtained consent from the data subject. This has actually been the case for a while, but some things will be more explicitly required: First, you must make it clear what your user is consenting to and second, you must make it optional (and non-default!) to give consent in cases where it’s not needed to provide a given service.

One very common scenario is for organizations to use production data from their customers for testing purposes. You can forget about that in the future. You could ask your customers for consent to use their data for testing purposes, but you must make this consent optional and non-default. So that means that at best, you need to find good routines to extract only data for consenting customers. Good luck! You could anonymize the data, but you are liable if there is a risk of reidentification.

Instead, I recommend that you invest in other testing strategies. In particular, most testing organizations can improve a lot by creating synthetic data. By investing in synthetic data, you can also improve your ability to stress the system with large and unusual values. Another testing method is partial production, where you gradually let more users onto a new version of the system. Perfecting this will also improve your delivery cycle a lot.

Now you have an excuse to invest in better testing.

Surprise 2: Functions required to support the rights of the data subject – data portability

When you store personal data, you now have to plan for functionality where the subject of this data can exercise their rights regarding the data. Much of this has already been the case, but the existing rights have been strengthened. This is described in articles 12 through 23. Just add them to your product backlog as system functionality or manual processes that must implemented. Basically, your customers have the right to see what data you are storing about them, including who has accessed the data. They should be able to correct errors in the data and to ask for data to be deleted.

A new and very interesting right is the right to data portability (article 20). Your customers have the right to get their data from you and take it to your competitors in a portable format (“structured, commonly used and machine readable”). As I understand it – if your customers can get an exported JSON, XML or CSV-format with everything concerning them, you’re pretty much set. If you wonder: PDF is not good enough.

Data portability is one of the most exciting parts of the GDPR and seems to be motivated by a desire to promote innovation. Just imagine what you can do with it! Imagine an app that can import your purchase history from all major store chains and help you analyze your own buying habits. It’s long been a dream, but the data was locked up. Until now!

Or you can use it to keep your competitors honest! Tell your customers that if they give you consent and upload their data from your competitors, you give the discounts and prizes. You have to be prepared for the case that your customers withdraw their consent again, but you are still allowed to keep aggregated data. And if you’re competitors are laid-back about GDPR – well, you can really put their feet to the fire!

Surprise 3: Keep data safe during transfer and storage – everywhere!

The final important consideration I want to talk about that comes out of GDPR is keeping data safe and under control (article 32 and also article 25, which mandates Privacy by Design). You are required by law to protect personal data in transit and rest at all locations. You are also required to report to the local authorities any breach of data that you detect.

What you need to do now is to map out every place you transfer personal data. What about temporary storage areas? What about backups? What about third parties that receive data? And what about logs?

Most organizations have less access protection of application logs than any other data. And often you log without considering the contents of the logging. I used to practice an approach of logging the full payload of all incoming and outgoing communication messages. That may no longer be a good idea.

The easiest way to protect data is to make sure you never collect it, and failing that, making sure that you don’t store it unnecessarily. You need to trace every piece of personal data through your systems and find out who can access it. If you can collect less, that will make your job easier.

Get started

There are more aspects of the GDPR that I have not discussed. In particular, the role of the Data Protection Officer is critical and has some surprising nuances.

But the goal of this article was to give you a place to start where there’s a good chance that you have something you need to do and perhaps something that you can benefit from as well. Here are three suggestions: 1. Verify that you’re not using production data for testing and develop new testing techniques if you do, 2. Add development tasks to support the rights of the data subject – a good place to start is Data portability, 3. Analyze the flow of personal data through the system, especially looking for less secured storage locations like logs and temporary files.

It’s not long until the law comes into effect and you need to get ready! The three places I’ve pointed out where you need to start touch most of the IT system related aspects of GDPR and can be used as a basis for understanding, implementing and benefiting from our improved rights to our own data as citizens and individuals!

Posted in English, Non-technical, Software Development | 3 Comments

Deliver early without sleepless nights

Trailblazing the first delivery of a software system requires courage and conviction, especially on projects that replace existing business critical software. When I’ve been acting as system architect I’ve employed a number of tricks in order to structure functionality and technical solutions in such a way that we can complete these early deliveries without sleepless nights. The most important is to find a subset of functionality that can be used with the rest being completed and investing in bridges from the old to the new.

Next Thursday (April 27th), I share my experience in the keynote for the ARK architecture conference in Oslo. A few tickets are still available if you want to make it.

In this blog post I explore the topic of replacing business critical software step by step.

As an architect I haven’t always have the joy of seeing my projects all the way to completion, but in those projects where I can see the software in the hands of my users early on are those I enjoy the most.

This article is not about streamlining a working delivery team to get from releases every few months to continuous deliveries. Many others talk about that. This is about how to get to production early the first time on a greenfield project. I will illustrate with two of my favorite projects.

Getting to the production the first time on a greenfield project takes courage and conviction, especially when you’re replacing part of business operations with a new system. Project stakeholders have many reasons to wait and often see no compelling reason to delivery a partial solution early. But when you get to production the first time, it’s like the sun has finally risen. The priorities and discussions in the project totally change. Now it’s real!

The first project I want to talk about was with the Norwegian electricity transmission system operator Statnett. We spent 4 years replacing the system that handles all reserve capacity of electricity deliveries on the Norwegian grid, but less than a year after the contract was signed, the users started using our software to control the power grid. Without any sleepless nights. Actually, they considered it such a non-event that they forgot to inform the development team about it!

The second project I would like to talk about is an app for internal mobile workers in private sector. As it is a project which is part of the competitive strategy of my customer, I cannot mention the purpose of the software, but I can describe techniques and technologies.

mobile workforce architecture

The mobile workforce app is especially interesting. Just like with Statnett, we were replacing an existing system in business use and integrated with other business functions. But in this project, we were live with the first users after 3 months, most of the user base after half a year and the remain users after around 9 months.

Here is what we did:

  • Realize that the journey is going to feel long and temporary investments made to ease the journey are often worth it. In both cases, I made sure the new system integrated well with the new system. I cannot stress how much it lowers everyone’s stress level when you can say: Why don’t we try the new system and if you experience problems, you can continue the very same process in your old system.
  • Isolate functionality that is small enough to deliver with a small fraction of the total project effort yet interesting enough to care about. In the case of Statnett we were able to replace the most used feature in the old system (while preserving the path of retreat). Even though the feature was a small part of the system, it was a large part of the usage. In the mobile workforce app, we found a business process that was missing in the old system and implemented this first. The process was interesting enough to the customer that they dedicated a few users to only perform this task.
  • Don’t wait for the rest of the world to complete their work. All projects I’ve been on has been part of a larger landscape of change where several of your dependencies are still under development by other projects. In the case of the mobile workforce app, we were dependent on core data that was to be owned by a system still under development. Realizing that our integration model would in any case be based on synchronizing copies of data, we decided that our copy of the core data would have several sources: 1. A manual CSV file exported by a sysadmin, 2. An automated dump from the legacy source which we established after half a year, 3. A feed from the new system (which is still not completed).
  • Spend effort making your system faster to deploy and easier to monitor. When you make a greenfield project, there is actually nothing that stops you from creating the production environment immediately (as long as you don’t put production data there before it’s hardened!). I’ve never regretted spending a few extra hours making it easier to deploy new version or making my logging smoother. Currently, I receive error logs on Slack with a clickable stack trace and a link to the user who experienced the problem.

When you do a major rehaul of a building, you may end up spending a lot of your effort setting up the scaffold to make sure the work is safe and effective. When you build a new software system, you should do the same!

If you do, you may be able to get users on your new system sooner rather than later without losing your sleep.

And when you get actual users to use your system the primary question of the project changes from “when is it all going to be done” to “what can we do next to deliver value.” And that’s much more fun.

Posted in Agile Release Patterns, English, SOA, Software Development | Leave a comment

“No – you don’t understand…”

On the futility of understanding

Is true understanding actually possible? I use my fingers to tap out keys on a keyboard and the light from your screen hits our eyeballs, but is it reasonable to think that there is any correspondence between the patterns in my brain and the patterns that were just created in your brain? Or are we just lucky if we have the same thoughts?

I used to think that if I just used the right words and asked the right questions and if only those I spoke with responded with the right words, then I would really understand what I needed to know. In software development projects I thought I would understand “the Requirements” (insert chorus of angels here). Either, the futility of understanding har recently dawned on me, or mind brain recently got out of focus (which is not unlikely: after my second child was born, my sleep deprivation is way up and my level of intellectual stimuli is down).

In short: I just realized I don’t really understand what others are saying to me. But maybe that’s okay. I’ve given up on understanding, but I don’t let it stop me. When my users tell me what they need, I listen, but I probably don’t really understand. I ask some questions and I get some answers, but not really answers to what I had in mind when I asked the question. So I retreat to my computer. Think a little. Sleep on it. Then I make something I can show my users without spending too much time. I see in their faces that they like it. Or don’t like it (which, to be honest, happens more often). I think some more. I create something different. In the end, I think my users are happier and more productive.

Would the process be improved by a Business Analyst on the project? I don’t know. I probably would understand the Business Analyst either. I would have someone to blame when I got it wrong. But would I get fewer things wrong?

Would it be better if someone had sat down and written a “Requirement Specification” (again: choir of angels)? I don’t think so. I usually feel even more lost when I read a spec than when I talk to “confused” users. (Disclaimer: The users are not really confused – they just seem that way from my point of view)

Perhaps we all really are walking with a blindfold in this world and we are just feeling our way around in the dark. The blindfold is not coming off any time soon. Perhaps it’s just as well we learned to live with it.

PS: If you didn’t understand the point of this blog post: That’s my point!

PPS: This seems like a philosophical position that someone must have thought a lot about before. I’d call it epistemological fatalism. I’d love to get tips to prior ideas in the comments.

Posted in English, Non-technical | 2 Comments