Category Archives: Non-technical

Articles that can be understood without coding experience.

Forget about Clean Code, let’s embrace Compassionate Code

When your heroes start acting weird, you reexamine their influence on your life. I’ve long been learning, demonstrating and teaching clean code through TDD, patterns and so on. But when I look back, I am now worried that the ideas negatively influence my life and my work and that of others.

Many who know me consider me an exceptionally skilled programmer. I got that way because I have often spent my evenings practicing programming techniques and technologies. I often leave the office 1-2 hours later than my co-workers after polishing some piece of ultimately meaningless code. This is time I don’t spend with my family. Because I’ve learned to care about Clean Code.

Some of the most unpleasant experience in my professional life have been due to disagreements of the Clean way to write some piece of Code. I know people that I respect professionally that could have been good friends if one of us hadn’t insisted on purity of code in some situation or another.

And I’m not alone. I’ve seen teams that are at conflict with each other because of different expectations of a programmers obligations. Often fuelled by the idea of Clean Code.

As I’ve grown older, I learned to stop getting upset about “Unclean” Code. In any real world code base there will be an uncountable number of unfortunate quirks, odd and ends. This is okay. Things are the way they are because they got that way. People did what they did because of reasons. Those reasons are valid, whether it was because the surrounding needs changed, because the developer had insufficient experience, because they wanted to go home to their family instead of sitting late in the office or if they just had a difference in opinion on what’s good code.

I sometimes train teams in TDD, incremental design, refactoring and pair programming. I almost always have to spend a lot of time helping the team bridge their disagreements in a more constructive way. And often the ones who have read Clean Code are the most susceptible to this sort of conflicts.

Why do I bring this up now? Because the reason that the idea of Clean Code is unhelpful as a guiding principle came in stark relief last weekend. The reason is simply this: We get led astray when we follow a principle or a rule without reflecting on what it does to ourselves and others. Robert (Uncle Bob) Martin is the author of the Clean Code book and a prominent developer trainer. He often writes on obligations, the oath to defend and preserve the honor of the profession, and shames excuses for not doing TDD. For a long time, there has been a nagging feeling at the back of my head about this language of “honor”, “obligation” and “professionalism”. But I enjoy test-driven development, and I have experienced it as a more fun way to develop. I believe that developers should reject illegal orders. I agree with Uncle Bob on all of these specific points.

Only when he writes something that I strongly disagree with, does the hunch about Clean Code became clear. The last days on Twitter we watched Uncle Bob implicitly decry the violation of Godwin’s law rather than the internment of thousand children under conditions that Amnesty International compare with torture. In the following days, Uncle Bob fought back against his critics also stressing that he thinks the situation is horrible, “but…” not as important as “unhonorably” comparing others to Nazis. I think his priorities are horribly wrong. I responded “In light of @unclebobmartin’s recent tweets, ideas like Clean Code have started creating a bad taste in my mouth. Let’s just say “code”, eh? I’m officially instituting “dirty code Monday’s” to remember to question dogma, tribalism and things-before-people mentality.” Bob asked me to explain “why you decided to lead a boycott against the concept of Clean Code”. Thus this blog post.

I deeply disagree with his stance on this political issue. I respect that some people value rules and principles higher than individual fates. I do not value rules for themselves. Bringing this back to code: I don’t believe we should use TDD because it’s a professional obligation. Instead I use TDD when it makes my work more enjoyable. I don’t think we should refactor our code because it violates a SOLID-principle. Instead I sometimes reach to a principle to understand why some piece of code is hard to change or understand. I don’t want to shame people for writing Unclean Code. Instead I believe in having an honest dialog among equals about how we want our code to look. I don’t believe that professionalism should compel us to introduce tests for all untested code. Instead I believe we should prioritize which deficiencies we fix and which code monsters we allow to live out their lives in their part of the code base.

I want to accept my unclean code as battle scars to be proud of and to be humble about, not as failings to be ashamed of.

My friend Thorbjørn Sigberg writes If your agile transformation has only one goal, it should be “Do less boring stuff”. When Clean Code becomes a source of less boring work, I’m for it. When it becomes a source of frustration and guilt, I’m against it.

For me, the ideas of Extreme Programming that bring the greatest joy to my professional life and that of my team are ideas about the whole team, about pair programming and about focusing on the users. Uncle Bob acknowledges these elements of the programming practice, but hardly ever talk about how to do it well. I don’t agree with these priorities.

As Uncle Bob nominated me as leader of “the boycott of clean code”, I guess I should try to end with something profound. How about this: Your most valuable skill is to know what’s important. Code is not important. Principles are not important. Rules are not important. People are important. That means your users, your team, your family, yourself. To quote Joshua Kerievsky’s Modern Agile: Make people Awesome. Clean Code may help or hurt that goal. Learn to see the difference.

Posted in English, Extreme Programming, Non-technical | Leave a comment

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

På grunn av sykdom ble intervjuet med mellom meg og Robert Steen 1. juni flyttet. Du kan istedet se oss live førstkommende fredag 22. juni.

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

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

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

“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

Welcome to the Mobile Era

(Looks like I’m back in the conference organization game again! After a few years of lots of travel and then a few years of lots of family responsibilities, this year I co-funded the Mobile Era conference. It looks like it will be a blast!)

If your experience is anything like mine, most of the interesting projects around you are having a larger mobile component this year than last year. I think this trend will continue. It can be a mobile-first website or a custom internal app for a company that wants their workers to be more effective when they are in the field. It can be an app to engage your customers or an intelligent sensor or “thing”.

We now have the technology to move lots of applications that used to be tied to a workstation over to a mobile device and in so doing unshackle people from their desks.

But this leads to a new challenge for developers: If you were an “enterprise developer”, you’re used to large data volumes, complex domain models and integration with various systems in various degrees of disrepair. If you were an “apps developer”, you were used to multiple device configuration, designing for small surfaces, and APIs with various peculiarities. Now the need has come for people who combine those skills.

With this in mind, it dawned to me almost a year ago that there is no good event in Norway that addresses this challenge. I wondered if anyone else was thinking like me, so I send an email to a few people with “if you think this is cool, I’m meeting a couple of people at Espresso House next Monday to see where we want to go. Please forward.” I was pretty amazed by the turnout (I’m the guy hiding in the back):

Mobile Era team

When we compared notes, many of us had almost identical ideas about what we thought a Mobile conference could mean. In the front and center of the picture, you can see Maxim Salnikov who came up with the name that embodied everything we had in mind. Thus the Mobile Era conference was born.

After a long and winding road, Mobile Era is only a month away. We have an amazing program with deeply technical subjects like the Realm Mobile database, Mobile DevOps, the new Awareness API in Android, performance tuning in Swift, ionic 2 features, React Native, Firebase, IoT. If you wanted to catch up on what’s happening all over the Mobile space, now is your chance!

When I look at my own preferences, I see that I more and more often leave the computer behind and use my mobile instead. I do code review on my mobile, I watch tech talks on my mobile (as well as tv), I receive production logs on my mobile, I deploy the next version of my software on my mobile.

In the Mobile Era, I expect my users to demand as much from the software I write.

PS: The early bird closed last week, but if you write a comment on this blog post, I’ll email you a special discount code which is valid for another week or so.

Posted in English, Mobile, Non-technical, Technology | 3 Comments

Hva burde egentlig et norsk IT-prosjekt koste?

Er det noen som sammenligner omfang og kostnad på IT prosjekter i Norge? Jeg tror man kunne få noen interessante innsikter dersom man gjorde dette riktig.

(Jeg mÃ¥ unnskylde at teksten i denne blogposten blir litt vag – jeg ønsker Ã¥ si sÃ¥ lite som mulig om de aktuelle prosjektene for Ã¥ unngÃ¥ Ã¥ eksponere andre)

Akkurat når jeg var involvert i et tilbudsarbeid for et prosjekt, var jeg samtidig involert i den endelige godkjenningen av et annet prosjekt. Jeg stusset over den store forskjellen i kostnadsramme for disse to prosjektene. Problemstillingen gikk lenge og gnagde og etter en lang tid ble jeg bevisst på at de to prosjektene hadde nesten helt likt forretningsmessig omfang. Hvorfor hadde de så forskjellige kostnadsforventninger?

Begge prosjektene var løsninger som hadde noen hundre saksbehandlere spredd i noen titalls lokalkontorer som behandlet noen titusentalls forretningstransaksjoner i året. I begge tilfellene var det cirka 20 forskjellige typer forretningstransaksjoner og disse hadde cirka 50% like behandligssteg, cirka 25% av behandlingsstegene var sammenlignbare og cirka 25% av behandlingsstegene var unike per type forretningstransaksjonene. Begge prosjektene skulle produsere og arkivere dokumenter og integrere med en håndfull andre systemer i og utenfor virksomheten.

Føringene rundt teknologi, arkitektur og prosjektledelse var nok forskjellige i de to prosjektene. Men omfanget av hva de skulle gjøre virket for meg veldig sammenlignbart.

Og forskjellen i kostnadsrammer? Jeg har ikke tilgang til offisielle budsjettall for de to prosjektene, men vi snakker om en faktor på 5x-10x. Dette er dramatisk.

Er det noen som har gjort en systematisk objektiv innsamling av IT-prosjektene i Norge? Ville ikke dette være et interessant forskningsprosjekt?

Posted in Non-technical, Norsk, Software Development | Leave a comment