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.

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.

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.

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.

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.

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”.

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.

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.

(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.

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.

Man kan lese fra moderne tanker på IT-utvikling at prosjekter er en avleggs arbeidsform. For de som har erfaring med utviklingsaktiviteter innen offentlig og privat sektor kan dette virke som en rar påstand. De aller fleste ser behovet for å unngå store prosjekter, men er prosjektet som arbeidsform virkelig avleggs? Det spør naturligvis på hva man mener: I alle de årene jeg har jobbet med IT-utvikling er det en ting som er sikkert.

I was humbled and encouraged to learn that I was nominated for Nordic Startup Awards category of Developer Hero for my contributions to the developer community. You can vote for me or one of the other great candidates here. For the last ten years, I have felt that the main pain points of the software development world could be fixed by empowering and inspiring those who do the work. From my perspective, I have focused on the developers.

I have an amazing time machine that lets me think better about projects. This is part 2 in a series of blog posts exploring the use of a time machine. This is a trick that I learned from my User Experience (UX) friends. In many projects, the project members have a great feeling about the possibilities of the product they are building, even if they quite know if they will get there or if the road ahead will be bumpy.

Jeg sitter i styret i Dataforeningen Østlandet hvor jeg er med å arrangerer Software 2015. Software er en kryssfaglig IT-konferanse hvor vi samler spesialister innenfor forskjellige fagfelt for å få dem til å snakke sammen på tvers av fagområdene. På konferansen er det dagsaktuelle temaer og trender som står på programmet. Jeg er stolt av alle de spennende temaene faggruppene har tatt fram og samarbeidet vi har fått til på tvers av fagmiljøer.

One of my favorite ways to develop software is to do it together with others. Pair programming has always been a motivating and fun activity for me, but some pairings work better than others. When our team was formed we decided to pair program and rotate partners every day. I had lots of fun programming with Milina, Asanka, Manoj and Chamath, but my favorite session was the one I had with Sankalpa.

Less Overproduction (of unused functions in interface between team members) Less Waiting (for the only person who knows a particular area) Less Motion (as everyone gets more skilled) Fewer Defects (because two pair of eyes see better than one) Less Over-processing (from duplicate responsibility) Less Inventory (as team works on focused set of features and tasks) Less Transportation (handoffs inside a story) Less Underused talent (as everyone gets to share their skills)

“Problemet med Java er at det krever så mange abstraksjoner. Factories, proxies, rammeverk…” Min samtalepartner gjenfortalte inntrykket han hadde av de Java-programmerende kollegene sine. Jeg måtte innrømme at jeg kjente meg igjen. Kulturen rundt Java-programmering har noen sykdomstrekk. Kanskje det minst flatterende er fascinasjonen for komplekse teknologiske løsninger. Et gjennomsnittlig Java-prosjekt har rammeverk (Spring, Hibernate), tjenestebusser - gjerne flere (OSB, Camel, Mule), byggverktøy (Maven, Ant, Gradle), persisteringsverktøy (JPA, Hibernate), kodegeneratorer (JAXB, JAX-WS), meldingskøer (JMS), webrammeverk (JSF, Wicket, Spring-MVC) og applikasjonsservere (WebSphere, WebLogic, JBoss).

When a software architect gets a good idea or learns something new, he has a problem. The main job of the architect is to ensure that the right information in present inside the heads of the people who should build the application. Every new piece of information in the architect’s head represents a broader gap between his brain and that of the rest of the team. The classical ways of adressing this gap is for the architect to write huge documents or sets of wiki pages.

Do you ever feel it’s hard to get real progress in a sprint towards the business goal? Do you feel the feedback from a iteration picks on all the details you didn’t mean to cover this sprint? Do you feel like sprint planning meetings are dragging out? Then a Rainbow Sprint Plan may be for you. Here is an example of a Rainbow Sprint plan: A customer wants cheap vacations The customer signs up for daily or weekly notifications of special flight offers Periodically the System checks which customers should get notifications The System checks for offers that matches the customer’s travel preference by looking up flights with the travel provider system The System notifies customer of any matching offers via SMS Variation: The System notifies customer of any matching offers via email The customer accepts the offer via SMS The System books the tickets on behalf of the customer The system confirms the booking by sending an SMS to the customer The customer can at any point see their active offers and accepted offers on the system website The customer enjoys a cheap vacation!

I have tried to create a simple process for debriefing workshops. This is the current process I use, and I think it may be useful for others. I give everyone sticky notes with three colors I ask everyone to write “a thing that surprised you about the workshop”, “a thing that you learned today” and “a thing that you plan to do as a result of the workshop”. Each question goes on a different color sticky note.

We were taught to categorize, but we know that searching beats sorting We were taught that information is scare, but we know that the real problem is too much information, not too little. We were taught that information must be protected from being viewed, but we know that the greatest threat to information is irrelevancy We were taught to estimate and plan what the marked wants, but we know that our customers don’t behave according to our plans We were taught to guide our customers, but we know they want to serve themselves.

This blog post is a summary of my lightning talk at XP2011 I needed to fail with modern methods for requirement gathering in order to understand old methods for requirements gathering. Many software projects write requirements in what is refered to as “user stories”. But a use story is not a story at all. There’s no drama, no action and no resolution. Instead, user stories are often just a bunch of interactions between the user and the system laying in a big heap in a shoe box.

This blogpost is a summary of my ScanDev 2011 talk: “Fearless Improvement” What is the goal of your current project? I currently work on a project for the transmission system operator for the Norwegian electrical grid. The value of the system we’re building is that my beer stays cool. Skill If you’re not skilled at what you’re doing, you may put in a lot of hours and end up having nothing to show for it.

At the Smidig 2010 Agile User Group confererence in Oslo, I conducted an open space workshop where I tested out a few retrospective techniques on the participants. The workshop was very well attended, and so I’ve posted a Norwegian language summary on the company blog for Steria Norway. Go check it out if you understand Norwegian!

As an architect for a team with a large number of people, I have a couple of problems: I often make decisions that turns out to be quite crappy. Even when I think I’ve written or drawn something that’s smart, it often turns out that it’s incomprehensible to everyone else Luckily, I’ve noticed that most developers have characteristics that almost always counter these weaknesses: Most developers are pretty smart, especially when they’re trying to solve a specific problem.

Sometimes I’m asked to write or speak about something with very little preparation. In these situations, I need a tool that can help me: Organize my thoughts quickly Prioritize the wheat before the chaff Maintain a coherent train of thought I find a very useful structure for archiving this to be what I call “three-by-three”: Three main points with three subpoints each. Forcing myself to keep to a structure will make my thoughts flow more quickly.

Smidig 2010: Norges største smidige konferanse Har du fått med deg at Smidig 2010 arrangeres 16.-17. November på Radisson BLU, Holberg plass i Oslo? Konferansen har åpnet for foredrag. Early bird prisen på billetter varer KUN TIL TORSDAG, så det gjelder å bestemme seg fort! Opplev vårt unike format, med over 70 lyntaler og 100 diskusjonsgrupper! Smidigkonferansen er den årlige nasjonale hendelsen som samler mennesker fra alle typer roller i IT-bransjen; prosjektledere, produkteiere, utviklere, bedriftsledere og testere og flere.

If you wonder why this blog has been so quiet lately, it not (just) that I’m getting lazier. Together with several of my colleagues at Steria Norway, I’ve started up a blog at http://sterkblanding.no. “Sterk blanding” is Norwegian for “potent mix”, and we hope that as representatives for several disciplines, we will be able to give a broad perspective on IT and management issues. I’ve not yet decided what posts to publish here and what posts to publish on Sterk Blanding.

Lately I’ve been thinking a lot about how easy it is to lose sight of the goal of the project and instead focus on whatever means someone first thought was a good starting point when the project was first conceived of. And I think it all comes down to words. The first years I was working in this business, I didn’t see any distinction between “the user” and “the customer”. Once I started seeing the distinction, I started to understand that the person who is going to use the system we’re developing is not the person who defines what the system should do and neither of these is usually the person that pays me to develop the system.

This Norwegian language article introduces a short two-page guide I’ve written to explain Scrum to people who’ve only just heard of it. I samarbeid med våre dyktige redaksjonelle medarbeidere på Steria, har jeg forfattet en “3 minutters guide” til Scrum. Denne tar for seg spørsmålene som “hva er egentlig Scrum”. [caption id="" align=“alignnone” width=“360” caption=“Dette er Scrum”][/caption] 3-minutterguidene kan lastes ned fra Sterias hjemmesider. Jeg planlegger å følge opp denne guiden med en guide som beskriver hva som skal til for å faktisk lykkes med Scrum.

Every Scrum-team should use their taskboard to support their particular way of working. I’d like to share the way we use our taskboard at my current project for your inspiration. [caption id=“attachment_447” width=“300” caption=“Colored ink, paper and makers support team process”][/caption] When I started my current project I went to pick up sticky notes and marker pens for the taskboard. I grabbed, more or less at random three colors of notes (red, green, yellow), four colors of pens (black, red, blue, green) and five color sticky bookmarks (yellow, green, blue, orange, red).

The generation that has been growing up was raised in a world that was radically different from the world we live in now. There is a generational shift, and we know that what we were taught is no longer true: [caption id="" align=“alignright” width=“200” caption=“What does your brain look like?”][/caption] We were taught to trust information from authorative sources, but we’ve learned to prefer the voices of named individuals. Be personal.

It’s not secret that Apple likes to control their platform tightly. As long as their dictatorship is a benevolent one, whether you find this objectionable or not is a rather uninteresting question. But lately, the question seems to be less and less academic: Google’s Voice Application for the iPhone got rejected and two existing applications (GV Mobile and Voicecentral) were removed from the AppStore! This is an extremely nasty thing to do to the developers.

This Norwegian language post talks a little about a quick intro to Scrum that I wrote for my employer Jeg har forfattet en “3-minutters guide” til Scrum. Dette er en to siders lettlest artikkel som publiserer via min arbeidsgiver Steria. Denne har som mål å være tilgjengelig både for tekniske og ikke-tekniske prosjektdeltagere som gjerne vil forstå litt mer om hva Scrum dreier seg om. Du finner artikkelen på Sterias arkiv over 3-minuttersguider.

Why do all societies we know of practice some form of religion? Either religion must be “true”, or there must be some sort of natural explanation for this universal phenomenon. [caption id=“attachment_403” align=“alignright” width=“161” caption=“Breaking the Spell”][/caption] “Breaking the Spell” by Daniel Dennett presents avenues of research into these explanation. He does not profess to have the answers to this question, or even the right question. He merely sets out to prove that the questions are important ones and ones that we can hope to gain insight into.

[caption id=“attachment_394” align=“alignright” width=“300” caption=“Summer is starting”][/caption] “Predictably Irrational” is a perfect book for lazy summer days on the beach or, in this case, while enjoying a beer from top of Oslo’s tallest office building. Dan Ariely is on a bit of a crusade against traditional economics, with it’s idea of rational behavior from everyone in the marketplace.

After receiving request to revive my book reviews, I’ve decided to blog about books I read again. If a known terrorist in police custody knew the whereabouts of a ticking bomb about to explode in a large city, would the use of torture be acceptable? Would it be helpful? I stumbled across Alfred McCoy through fora.tv. The program impressed me so much that I decided to pick up his book A Question of Torture.

I thought it was about time I wrote about topics where I’m an amateur. This time: Experimental philosophy. As a computer programmer, I often entertain myself with writing computer programs. Last Easter I stayed up a few nights playing with an insignificant, but entertaining program. During a discussion with my philosopher uncle, I discovered that this program might provide some insight as to why determinism is, if not dead, then at least lame.