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.

OpenID Connect 3: Slack can be the identity hub of small organizations

(Technically, this is a blogpost about Oauth2 and not OpenID Connect)

Are you using Slack as a central communication tool? Did you know that you can also use it as your identity provider for other apps you make or buy?

For informal organizations like user groups and volunteer based conferences, Slack is perhaps already your communication hub. This means that the information you have about your users here is as good as you have anywhere. Access to private channels is often well managed as you don’t want random people in your limited conversations.

For many organizations, especially small ones, Slack may be the best option for authenticating your users on other applications. Unlike Google or other social identity providers, you can control who is a member of your Slack team, you can audit and confirm their profile information and you can restrict which channels they can access. The channel membership is a nice fit for application privileges, so you can say things like “this application can only be used by Slack users on the private channel #admin”

Slack implements Oauth2, which is a subset of OpenID Connect. This means that once you have the user’s access token, you have to make a Slack specific API call to get the user profile and other information, like their list of channels. So there is slightly more custom integration code than for full OpenID Connect providers.

For organization that already have a well established Slack team and no other identity manager in use (such as Active Directory), Slack may be your best source of trust for other applications. You can integrate with it using the standard Oauth2 protocol.

You can start your journey at my Boosterconf workship in Bergen March 14th. https://2019.boosterconf.no/

Posted in English, Identity | Leave a comment

OpenID Connect 2: Why I ❤ ID-porten

The advantage of OpenID Connect is the fact that it’s standardized and widely adopted. This means that a library or tool designed to work with, e.g. Google accounts, can easily be adopted to work with e.g. Microsoft’s Active Directory or the Norwegian national ID provider ID-porten.

Different Identity providers can support different levels of trust between you and your users.

In my next few blogposts, I will explore different OpenID Connect providers and what they can offer you as an application developer.

Norway’s national Identity Provider

The advantages of using ID porten as an identity provider are considerable, but it comes with limitations as well. ID-porten is the identify provider supplied by the Norwegian government to all residents of Norway. It is (almost) fully compliant with OpenID Connect and is compatible with most tools and libraries.

When your user is authenticated with ID-porten, your application receives their national identification number (fødselsnummer eller d-nummer). This identity is generally safeguarded by two factor authentication and the user has been validated by personally showing their identification papers in a bank or police office. You can be very certain of the user’s identify.

The limitation is that even though you know the user’s identification number, you know very little about the user. You have to be authorized to use the national population register and do the lookup yourself to get their name and address. And even then, you don’t know what organizations the user is associated with and what authorization they have there. (This limitation is natural, considering the scope of responsibility of ID-porten)

So the dilemma is that you can be quite sure of who the user is, but you have no idea who they user is. 😂

(Some of this information is available in other national registers and as time goes by, it may be more accessible)

Furthermore, even though you know who your user is, you don’t know if you can trust them or if they are a crook. Most convinced criminals of course retain their right to use online banking and naturally they have ID-porten access. And that’s the way I think we should treat people, even those who have messed up in their lives.

Getting started with ID-porten is a bit harder than for other OpenID Connect providers, but this is mostly administration. First, not all applications are authorized to use it, of course, so you must contact Difi to get access. Secondly, ID-porten is very limited in terms for self service of application administration, so getting client credentials also involved soon emailing.

But once you have your application credentials, integrating with ID-porten is just as simple as any other OpenID Connect provider. As a matter of fact, I’ve made apps that work with Google accounts and re-targeted them to ID-porten with only changes to credentials.

Difi’s OpenID implementation is impressively accurate and robust, but there are still some issues you may run into in mobile app scenarios. (In technical parlance, response_mode=fragment doesn’t support response_type=code without a client secret, which is the easiest secure option for apps)

If you are providing services to Norwegians on behalf of local or state government, ID-porten is your mandatory identity provider. And you can use existing knowledge and tools for OpenID Connect to do so.

You can start your journey at my Javabin talk in Oslo this Wednesday. https://www.meetup.com/javaBin/events/258573600/

Posted in English, Identity | Leave a comment

OpenID Connect 1: Microsoft Azure Active Directory

The advantage of OpenID Connect is the fact that it’s standardized and widely adopted. This means that a library or tool designed to work with, e.g. Google accounts, can easily be adopted to work with e.g. Microsoft’s Active Directory or the Norwegian national ID provider ID-porten.

Different Identity providers can support different levels of trust between you and your users.

The protocol is perceived with an air of mystery by many developers, but it’s surprisingly simple to master. As a developer, you owe yourself and your users to play with OpenID Connect before you ever implement a username+password.

You can start your journey into OpenID Connect at my JavaBin presentation this Wednesday, or my workshop at Boosterconf in Bergen.

In my next few blogposts, I will explore different OpenID Connect providers and what they can offer you as an application developer.

Why Microsoft Azure Active Directory can enable cross-organization cooperation

The main advantage of using Microsoft’s Active Directory as an OpenID Connect provider is that you can validate your users’ association with specific organizations, whether it’s your own organization or one of your customers or suppliers.

While an identity provider like Google accounts or Facebook will supply the name of the user, this information is not at all validated. Just because a Google user is registered with the name “Johannes Brodwall”, there is no way of knowing if this is truly their name. But if you get the same name from Sopra Steria’s active directory, you can be a lot more confident.

Fingerprint

Similarly, end user Identity providers like Google and Facebook can validate that a user had an @soprasteria.com address at some point in time. But when the same claim comes from active directory, you know that this email address was still active at the time of the authentication. Again a much more powerful claim.

Your trust is limited to your knowledge of the users organization, of course. The first time a user arrives from an unknown organization (“tenant” in active directory terminology) you basically know nothing about the organization and the user. Anyone can register an active directory with email addresses that resemble a legitimate organization.

A common misconception is that an administrator of the user’s organization must be involved in order to integrate with an active directory. This is not the case. Anyone can make an application registration that can authenticate users from any active directory. (This used to be called “multi tenant applications”, but Microsoft seems to be smoothing out a lot of the difference between multi tenant and single tenant apps now). But the user will be asked if they consent to your app getting their name, email etc.

The full power of active directory can be unleashed for organizations where the administrator gets involved. If you make an app that e.g. Sopra Steria wants to use officially, an administrator at Sopra Steria can authorize your app to get user details without explicit individual consent and can also authorize your app to receive information about users’ roles and groups. And the administrator can require their users to use Multi-factor authentication for your app and even audit user logins from their organization to your app.

This means that your active directory application will have to deal with both unknown organizations, known organizations with default configuration and organization where an administrator at the organization have set up your app.

Active Directory gives considerable power out of the box and if you’re willing to deal with the complexity, you can get even more.

And all it requires from the developer is to integrate with the fully standard compliant OpenID Connect protocol. This is as easy for Java developers as for .NET developers.

Stay tuned for my upcoming articles about ID-porten and Slack as ID-providers.

Posted in English, Identity | Leave a comment

We’re not good enough – and that’s okay (Norwegian)

This Norwegian language blog post summarizes my talk at Oslo Agile Meetup in the beginning of October.

Jeg tror ingen egentlig vet hvordan de skal få til bra utviklingsprosjektet. Selv når vi lykkes så er det veldig mye flaks. De fleste av oss tror vi kunne gjort mye bedre. For de fleste av oss holder tilstanden til kodebasen oss tilbake fra det vi synes vi burde ha fått til.

Vi har lært en del ting om hva som i teorien skal være løsning:

  • Clean code skal være løsningen. Dersom vi bare hadde brukt de riktige patterns, prinsipper og teknikker så hadde alt vært bra.
  • Software craftsmanship – eller håndverksånd – skal være løsningen. Dersom vi bare hever lista for oss selv som fagfolk så hadde alt vært bra.
  • Funksjonell kontroll skal være løsningen. Hadde vil bare hatt en dyktig produkteier (fagfolk!) og en ryddig produktkø så hadde alt vært bra.

Men det er jo ikke sant.

  • Selv om alle er enige om a koden skal være god, så er vi veldig uenige om hva som er god kode. Spesielt koden andre skriver. Mange team har stille eller støyende uenigheter om koden skal være slik eller sånn.
  • Jeg programmerer som en adspredelse i stedet for å spille data eller se på serier. Det er veldig praktisk for meg at det å trene på faget er verdsatt; MEN DET BURDE IKKE VÆRE EN FORVENTNING for at man skal kunne være stolt av jobben.
  • Og det vi driver med er ofte ikke så viktig for den store verden. Det er ikke verdt å tape familietid eller søvn over. Noen ganger kan det være direkte skadelig. Vi skal ta oss i akt og huske at et av de eldste informasjonssystemene var det Dehomag leverte til Nazistene for å drive konsentrasjonsleire. Oppgaver som er verdt å gjøre følger ikke fra funksjonelle beskrivelser

Så hva kan man gjøre, da?

  • For å få en kodebase med mindre hindringer er det viktigste skrittet at utviklerne snakker mer om koden og at man lærer seg å være ydmyk. Spesielt vi mannfolka må bli flinkere til å si “jeg tok feil”. Og det krever trening! Og parprogrammering funker!
  • Vi må lære oss å begrense oss selv. Den viktigste måten jeg har fått opp farten på er ved å gå saktere – spesifikt ved at hele teamet fokuserer på ÉN oppgave om gangen. Dette kalles gjerne swarming. Som team: Bli ferdig med én ting og gå til neste i stedet for å starte på enda flere ting.
  • Til slutt må vi lære oss å si stopp. De fleste organisasjoner mangler mekanismer for å oppdage og handle dersom man driver med tull. De fleste personer har problemer med å innse at man løper et tapende løp. Det aller viktigste er på det personlige plan: Ikke forbli et sted der kulturen er dårlig og hvor folk ikke er snille med hverandre.

Jeg vet ikke hva som skal til for å lykkes, men jeg vet noen måter vi alltid tabber oss ut på: Jeg vet det er vanskelig å si “jeg tok feil”; jeg vet det er vanskelig å si “la oss bli ferdig med dette før vi starter på noe nytt”; jeg vet det er vanskelig å si “nok er nok”. Disse tingene er hva jeg vil bli flinkere til.

Posted in Extreme Programming, Norsk, Pair programming, Software Development | Leave a comment

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