Author Archives: Johannes Brodwall

About Johannes Brodwall

Johannes is Principal Software Engineer in SopraSteria. In his spare time he likes to coach teams and developers on better coding, collaboration, planning and product understanding.

Dirty Code Monday!

Lately I’ve been thinking about how easy it is to fall into the trap of not challenging our ideas about the code we’re working on. In order to challenge the default mindset of Clean Code, I recently proposed to institute Dirty Code Monday (a proposal that sort of got me into a bit of a big discussion).

Anyway, here is the report from the first successful Dirty Code Monday one week ago:

An unpromising start: I had done a code review with “Programmer A”‘s code on Thursday where “Programmer H” and I had pretty much rewritten all of it. Now we had to go through the results together. We all admitted that code review is not ideal for a Dirty Code Monday, but rules are rules.

The first bit of code we came across was this:

Notice the comment? // TODO: Find out if SSLContext.getSocketFactory is expensive an if so, cache. I sighed. “We really have to remember not to do premature optimization, or we’ll never find out if it is really slow or not.” “Programmer A” responded “What? I thought you said this was Dirty Code Monday! Let’s just do it!” And so we did. We cached the result of createSocketFactory in a static variable. Dirty Code Monday!

By now, I was starting to get my spirits up that we could actually pull this off. We glanced up at the on-wall monitor: Someone had broken the build. “Sorry,” said ‘Programmer K’, “I forgot that my commit also changed the backend.” ‘Programmer R’ chimed in: “Yay! Your turn to get cake, K”. “Not today,” said A, “Dirty Code Monday!”

‘Project manager K’ just mumbles “The cake is a lie”.

I continued the code review with A. Next up was this beauty:

“Hmm…” I said, “I guess that really should deal with DELETE and PUT requests, too. But it’s Dirty Code Monday.” We discussed a little and A mused “a switch-case could work here”. “Ugh! I say, I don’t like switch-statements. They kinda violate the OCP. Maybe. Maybe not here. But I still don’t like it.” He just looked at me and we both laughed.

“Ooooh,” I said. “Look at that repetition of the complicated stream() expression. Perfect!” ‘Programmer A’ was pleased as well “Dirty Code Monday is pretty okay.”

Perhaps you think our code wasn’t that dirty. I’m actually not that embarrassed about it. But changing our perspective helped us see other ways of working with the code than we were used to. Having a phrase like “Dirty Code Monday” was a fun thing for the team to talk about. I’d like to try it again today.

Happy Dirty Code Monday, everybody!

PS: The code in this article is actual production code. The whole team has approved the quotes attributed to them

Posted in Code, English, Java, Pair programming | Leave a comment

A canonical XML test

I recently did a few days of TDD training for a client. They asked me to help them test and refactor a class that created XML from an internal domain model. This gave me the opportunity to examine a bigger pattern.

I wondered where the domain model came from. Looking through the code base, I found that the same or similar data structures were dealt with many places. As often is the case, I also found a bit of code that parsed an XML structure and output the domain model. This made it possible to use my favorite way of testing mapping code: Round-tripping.

The general pattern: To test translation code, you can test the encoding and decoding as one. These tests will often give you a lot of bang for your buck, both in terms of readability and in terms of error detection rates. Their main limitation is that they may not work to exercise all paths of the code well. If this is a problem, you should supplement them with more fine-grained test.

As I have dealt with this sort of problem a few times before, I’ve decided to create my own XML library, Eaxy (as you do). I introduced the library in the tests, but the production code remained using a combination of DOM and JAXB. Here’s a reasonable reproduction of the test:

When I introduced this test to the existing code base, we discovered a few interesting things: 1. There were internal dependencies in the XML file that the developers were unaware of as all the canned test data consisted of huge files that nobody would read. 2. A field was decoded from base64, but treated internally as if it was still encoded, leading to doubly encoding it in the output. 3. The output structure was slightly different from the input structure.

The test, combined with coverage measurements, gave us enough confidence to refactor some pretty crufty code that the team relies on in the future. Round-trip testing can give you a lot of bang for your buck.

Posted in English, Java, Unit testing | Leave a comment

How to write better code

My previous blog post took off on Twitter. It pointed out a problem: Insisting on the obligation to follow certain rules at all times isn’t actually helping people work better. The most common question (or objection) I got to the blog post was: So how do we teach new coders how to code well. This blog post is about that topic.

First learn to collaborate

The most important skill we should teach is how to work well with others on a shared code base. In my career, it took me many years before I started getting good at this, but it had the most impact on my effectiveness. So this is where I want to start with developers who are getting ready to join the work force. On almost all projects we work on, our success will depend on others.

Working with others can be taught. Here are some techniques that have worked for me:

  • Pair programming. Good pair programming requires training, but there exists training styles like coding dojos and code retreats. Some of the best programming instructors in the world use pair programming actively as part of their training.
  • Code reviews. I work so much with pair programming that I personally give code reviews a lower priority. But many teams find great value in them.
  • Patience. When working with pair programming, it’s easy to get stuck in arguments. Our profession says almost nothing about interpersonal skills, yet we depend on them all the time. Try this: When pair programming and you see your pair making a mistake, wait to see if she spots it herself before breaking in.
  • Humility. I often get asked “how do I convince others to write clean code”. Of course, the question assumes that you’re right and they are wrong. Most of us are absolutely rubbish at the skill of changing our minds. When pair programming, if your pair want do something you think is wrong, try indulging them. At worst, you get the chance to teach them something. At best, you learn something yourself.

Unless you are in a situation where you write all the code yourself, collaboration skills are paramount. It doesn’t matter if you “know” what the code should look like if you can’t agree with your team.

Now, let’s talk about code!

If you are one of the people who skipped ahead to this section, please go back and read about collaboration. Seriously. Nothing I say about code will help you if you can’t work well with others.

Go ahead, read it again. I’ll wait here.

Good to see you back! Now let’s talk about learning to write good code. Of course good code is crucial to professional success. If the code base is better, you spend less time fixing bugs, you have an easier time changing the code in the future and your team will have a better time working with you. This is understood.

Learning to write good code is quite simple: You have to read code, you have to write code, you have to change code, you have to observe what is easy and what’s hard, and you have to delete code and start over again.

For the first of these points, great books help you to read code: Clean Code, Implementation Patterns, Refactoring, the Art of Agile, the Pragmatic Programmer, Practices of an Agile Developer, Design Patterns. I’ve enjoyed reading all these books immensely. These books will teach you considerations such as low coupling, high cohesion and simple design. They will teach you useful principles like Single Responsibility Principle and the Open-Closed Principle (although I find I almost never refer to the rest of SOLID). The patterns and principles teaches you words to discuss code with your team.

For the second of these points, Test-Driven Development is one great way to learn how to write code. I enjoy doing coding katas myself and often use them for teaching. But the most valuable skill when writing code is one I learned at code retreats (thank you, Corey Haines!). Learn to delete code you write. I don’t just mean refactor it to be smaller. I mean that for coding exercises, highlight all the files and press the delete button. I mean for production code, after spending a few hours working on a task, (occasionally) git reset --hard HEAD.

The hallmark of great code is how easy it is to change. Can you navigate in the code? Can you spot errors quickly? Do you know where to make a specific change? You can learn by reading about principles, but the most safe teacher is to expose yourself to more experience. (I’m planning to write a blog post on how principles sometimes, but not always coincide with good code). When you write and change code, reflect on how limitations of the code and your current skillset impedes the changes you want to make.

In short: Code more, listen to the code and listen to your peers.

Can you release smoothly

I almost forgot the #1 quality of good code: It has to be used! Release cycles of teams can vary from several times per day until a few times per year. If you can release your code at will, you can learn both about your code and your users. When the whole team learns that you will release again tomorrow, or next week, priorities of “now or later” gets easy. When you release only a few times a year, people get stressed and discussions get heated.

I’ve almost always find that team under-appreciate the value of spending time on build and deployment tools and scripts.

“Don’t do stupid stuff on purpose”

If you find code you’re unhappy with, it bears remembering that it is that way because it 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 of pressure to finish, because they wanted to go home to their family instead of sitting late in the office or maybe they just had a difference in opinion on what’s good code.

Not everyone agrees with this, “what about those who just don’t care?” After 20 years of working as a programmer, I have never encountered anyone who just didn’t care. I have encountered programmers who had different preferences from my own, I’ve encountered programmers who are delivering under short deadlines, I’ve encountered programmers who get praised for making appearant progress at the expense of writing good code. And I’ve encountered many programmers who don’t care as much as me about the code. Having other interests in our life is an excellent reason to spend less time polishing code.

But I’ve never encountered a programmer who just doesn’t care. Have you? I’d love to learn from your story.

Posted in Code, English, Pair programming | Leave a comment

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

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