Category Archives: Non-technical

Articles that can be understood without coding experience.

“No – you don’t understand…”

On the futility of understanding

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

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

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

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

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

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

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

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

Posted in English, Non-technical | 2 Comments

Welcome to the Mobile Era

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

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

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

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

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

Mobile Era team

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

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

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

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

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

Posted in English, Mobile, Non-technical, Technology | 1 Comment

Hva burde egentlig et norsk IT-prosjekt koste?

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

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

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

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

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

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

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

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

Er IT-prosjektenes tid forbi?

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. Arbeidet endrer seg til det bedre når man går fra å bygge noe på laben og over til å lansere programvaren for brukere som benytter seg av den til daglig. Før dette tidspunktet er “kvalitet” en subjektiv og spekulativ egenskap, “fremdrift” er et begrep som må kvalifiseres med mange forbehold og formålet til hele initiativet er fortatt en hypotese der alle har sin egen tolkning.

I dag er den ingen gode grunner til å levere programvare gjennom et prosjekt som sitter flere kvartal eller år og bygger noe som så skal være klart til en stor lanseringsdag. I den betydningen er prosjekter en avleggs modell.

Men noen ting har ikke endret seg: Mange organisasjoner vil ha behov for et team som er større i en periode – et prosjektteam. Mange organisasjoner kunne ha verdi av leverandører som kan ta ansvar for at det arbeidet som gjøres er av god kvalitet og har en rimelig kostnad.

Men organisasjonen gjør smart i å koble dette prosjektteamet tett opp mot den mer permanente organisasjonen. Linjeorganisasjonen kjenner behovet og rammevilkårene bedre enn den midlertidige organisasjonen og vil ta over forvaltningen av produktet på sikt.

Og nye produkter vil ikke lanseres dager eller en gang uker etter at de har blitt påbegynt. Ved å levere så ofte som hver uke eller endog flere ganger om dagen kan organisasjoner heve kvaliteten og redusere arbeidet og bekymringen i forbindelsen med nye leveranser. Men det er ikke gjort på en dag. Dersom man skal etablere et nytt prosjekt kan man med fordel drifte dette (for eksempel i en skybasert løsning) allerede etter få dagers utviklingsjobb. Men det vil ta noen måneder før man har nok funksjonalitet til at man ønsker å invitere noen utenfor prosjektet til å bruke løsningen.

Er IT-prosjektenes tid forbi? Jeg håper vi ikke lenger vil se initiativene som bruker titalls eller hundretalls millioner kroner før man lanserer noe for brukere. Men organisasjoner vil fortsatt måtte benytte seg av økt bemanning i satsningsperioder. Og nye produkter bygges ikke på en dag før de kan lanseres.

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

The key is empowering the people who do the work

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.

If you are a developer working on a project, both you and the people around you will benefit greatly if you learn new things and share what you know about the problem your project is trying to solve, about the technologies you use and about the way you’re working.

Ideas like pair programming to spread the knowledge, simple design to make it possible to understand the whole solution and collaborative product backlog planning to understand the problem can help you do this.

This was the inspiration behind me starting up Oslo Extreme Programming meetup in 2004. We have hosted about 100 meetups over the years.

But even beyond your project, if you can share and learn from others in you community, we will grow even further. I have long been a fan of the lightning talk format. Most of the smart experience is in the heads of those who don’t often give talks, who don’t have a lot of time to prepare a long talk and who perhaps only feel they have one or two things to share.

If you are a human being, you know something that can inspire someone else. All you need is to have the courage to try, the patience to structure your ideas and the discipline to practice your talk.

I am proud to have witnessed some of the first talks given by some of the speakers who inspire me today, such as Christin Gorman, Karianne Berg, Henning Spjelkavik and Filip Van Laernen.

This was the inspiration behind me and others starting the Smidig (Agile in Norwegian) conference in 2007. Since 2011, I have handed over the organizing baton to others and I am happy to see that the conference is still thriving and that our original vision is still a helpful idea behind the conference. Over the years, over 500 talks have been given at the Smidig conference, many by first time speakers.

As I saw the Smidig conference in competent hands, I looked around for other areas to contribute. Fellow Developer Hero nominee Simen Sommerfelt convinced me to join the board on the Norwegian Computing Association. The organization has a 60 year history and the people who are involved with the organization possess a well of knowledge. However, the competition from meetup and other communities threaten to siphon away the vitality of the organization.

If you care about a professional field, you can step up and help others in that field find their voice. If you know the people who are worth listening to inside a field, pulling together an event where they can share their knowledge is surprisingly simple. You can use meetup.com to organize a group or you can get help from an organization like the Norwegian Computing Association.

I have been helping events happen in Norwegian Computing Association and I hope to be doing this even more in the future. Together with a great team of organizers, I helped organize the Software conference the last few years. This year, we received recognition as the Event of the year in the Norwegian Computing Association, an achievement I’m very proud of.

As I have moved from event organizer to inspiring other event organizers, my own Oslo XP meetup has fallen off the list of things I’m able to attend to. If you are looking for a place where you can contribute to the community, I would love for someone to step up as organizer for a while.

I have been privileged to be able to watch what happens when developers care about their project, share their knowledge and take responsibility for their professional community. When I see the experience and the result of people caring, I also realize that this goes beyond just the sphere of software professional.

The Norwegian government is spending billions of kroner each year on software projects. Recently, there has been a lot of attention on many of these projects that have very little to show for their investment. I believe that this waste comes from projects being run without respecting the knowledge that the developer community possesses and the professional talent that is available.

Recently, Geir Amsjø has been able to gather together a loose group of like minded people who have been contributing in the public debate on public sector IT spending. We hope that this work can affect the very way money is being allocated to these huge and important projects.

By caring about your profession in your project, your community and the world at large, you can make a difference. Enormous resources are being consumed to build IT systems around the world. Only when the people building the system care about their craft and are being listened to can this investment truly pay off.

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

Getting excited about your project with a news headline from the future

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. A great way to focus your mind on the goal is to ask your future self to brag about what success the product was.

This exercise works great in groups: Form groups of 3-4 people (group of diverse people are better). Each group gets 15 minutes to draw the front page of a news paper (or online news paper) that picks up the story of the success of the product you all are building together.

Give each group a thick A3 paper and some colored markers. (Avoid pens – they don’t show up at a distance)

Some things to include:

  • The name (and logo) of the publication
  • A headline for the article
  • A sketch of an article image (including image description)
  • An ingress – a short summary of the news story

When the 15 minutes have expired, each group stands up and presents their article.

The posters make for great decoration of the team area (for a couple of weeks, anyway).

Remember: You will only build something remarkable if you can envision how it will be received.

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

Software 2015 i regi av DND

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.

Vi ser at både kravhåndtering, devops, prosjektledelse og arkitektur fokuserer mer og mer på å bevege seg mot kortere leveransesykluser. Da blir det viktig å forstå verktøyene og teknikkene som gjør dette mulig.

Et annet viktig tema er den stadig mer sentrale rollen IT spiller i samfunnet. Vi har samlet representanter fra store offentlige IT-miljøer som gjennomfører prosjekter som vil påvirke alle i Norge.

Software har også lykkes i å belyse den viktige debatten som skjer mellom sikkerhet, personvern, kriminalitetet og overvåkning i samfunnet.

Jeg synes også det var morsomt å snakke med Frode som er med å arrangere stormaskinsporet. Jeg har aldri satt meg nok inn i stormaskin, men har vært i flere organisasjoner der hjertet av virksomheten har ligget i stormaskinen. Det har som regel vært en målsetning å bli kvitt stormaskinen, men fordi man ikke har satt seg inn i hva den gjør blir dette veldig vanskelig. Frode sa: “De som vil bli kvitt stormaskinen setter seg ikke inn i hva den gjør – så de får det ikke til. Og de som setter seg inn i den vil ikke bli kvitt den”. Jeg er ikke 100% overbevist om at han har rett, men det er spennende tanker.

Meld deg på Software 2015 du også.

Jeg gleder meg, og håper å se deg også på Software 2015!

Posted in Non-technical, Norsk | Leave a comment

Pair programming with Sankalpa

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. In this session, we achieved something that we would be helpless to do alone.

The task Sankalpa and I was working on was to include information from a calendar in Confluence in a date picker in a web application. As we sat down, I was dreading the integration part. Integration is often dreadful. More than anything, I wanted to hide from the problem. But with Sankalpa sitting next to me, I didn’t feel that I could give up, so I suggested we took a look at our Confluence calendar to get started. Sankalpa was at the keyboard and he found a “calendar feed” where I hadn’t thought of looking for it.

Looking at the feed, I exclaimed “Oh, I know this – this is vcalendar”. A quick Google later and we had found a library for parsing vCalendar in JavaScript. We quickly finished the code to adapt it to our desired format and moved to the date picker.

I was at the keyboard and I had used a date picker library called jQuery datePicker before. We quickly integrated it and I proudly refreshed the page to show the calendar events in the view! But it turned out that all the functionality that depended on picking a date was now broken.

I started grumbling about how I was much more comfortable with jQuery than with AngularJs. Unfazed, Sankalpa mentioned that Manoj had gotten the date picker to work with AngularJs in an earlier project. “Hey, Manoj, where did we use this date picker?”

Having much more experience with AngularJs than me, Sankalpa integrated the code into our code base and everything was working.

All in all, I had expected this to take 2-3 times as much effort. If we had been alone, we would probably wouldn’t have the courage to start with the integration right away. If he had been alone, Sankalpa probably wouldn’t had known how to parse the vCal feed. If I had been alone, I probably would have searched the Internet for hours to find out how to make AngularJs play well with jQuery date picker.

Together, we did what neither of us could have done alone. (At least not anywhere close to this quick)

Posted in English, Extreme Programming, Non-technical, Pair programming, Software Development | 1 Comment

Using pair programming to combat project waste

  • 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)
Posted in English, Extreme Programming, Non-technical, Pair programming, Software Development | Leave a comment

Om å løse alt bortsett fra det egentlige problemet

“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). Og det er bare starten. Hvor kommer denne impulsen fra?

Jeg har hørt to teorier om hvorfor Java-programmerere ender opp med en kompleks hverdag. Den ene skylder på sjefene, mens den andre skylder på programmererne. Jeg vil ta for meg begge og peke på en vei ut av jungelen.

Teori 1: Steak and strippers

Zed Shaw, mannen bak “The motherfucking manifesto for programming, motherfuckers” skylder på IT-sjefene. Han mener at selgerne fra teknologiske giganter tar med IT-sjefer ut på strippebuler og kjøper biffmiddager til dem. Og vips så kjøper IT-sjefen inn et ubrukelig verktøy som programmererne er tvunget til å bruke. (Zed påpeker at det vil være positivt med flere kvinnelige IT-sjefer, ettersom de i det minste ikke vil være like interessert i strippebulene)

Ref: Zed Shaw: Control and responsibility (http://zedshaw.com/essays/control_and_responsibility.html). Zed Shaw: Programming, motherfuckers (http://programming-motherfucker.com/). Zed Shaw: Video – Steak and Strippers (http://vimeo.com/2723800).

Argumentet er underholdende, men forklarer bare en del av problemet. Mange av verktøyene som står bak kompleksiteten i Java-prosjekter er åpen kildekode og selges typisk ikke av selgere med fete representasjonskontoer.

Teori 2: Blinkende lys

Jeg tror en viktigere teori er at programmerere er opptatt av fancy ting som blinker. Enkle ting som firmaet tjener penger på er kjedelige. Å sette seg ned og flytte data fra databasen og putte det i en webside er kjedelig for en programmerere. Å lære seg et nytt rammeverk som gjør den samme jobben på en fancy måte er spennende. Å fjerne teknologier og lage en enklere løsning er kjedelig. Å innføre et rammeverk som skal skru sammen teknologien er spennende.

Alle foretrekker å gjøre det de synes er spennende. Jeg vet det, for jeg har vært der selv.

Grunnleggende sett tror jeg at Java-programmere selv har skaffet seg de problemene de ofte klager over med komplekse teknologier.

Veien ut av villmarken

For meg var det viktigste skrittet ut av villmarken foredraget jeg hold på JavaZone for to år siden. I foredraget bygger jeg og Anders Karlsen en webapplikasjon i Java uten å bruke webrammeverk. (Innbild deg at du hører et ironisk gisp her)

Jeg har øvet meg på å løse de problemene jeg har i prosjekter med å bruke enklere teknologier. Slik vet jeg hva de komplekse løsningen gjør. Og så langt er det nesten ingen løsninger som ikke innfører mer problemer enn de fjerner. Det de gjør er at de flytter fokuset fra den oppgaven programmet egentlig skulle løse over til alle de teknologiske delene som man skal få til å fungere sammen.

Jeg tror ikke programmerere er bedre eller dårlige enn andre mennesker når det gjelder det. Men vi har alle en tendens til å bruke tiden vår til å finne spennende problemer å løse i stedet for å løse det vi egentlig skulle på en naiv og enkel måte. Min far sa det egentlig best: Du bør ikke bruke en kalkulator før du kan løse de samme regnestykkene på papir.

Posted in Java, Non-technical, Norsk, Software Development | 27 Comments