Category Archives: Communities

What mobile strategy is best: Native or Hybrid?

So: What is best? A native app or a hybrid app? And if you build a hybrid app, what’s the best framework to use?

As with most interesting questions, it turns out that the answer is “it depends”. I often get questions like “isn’t Xamarin (or Cordova) better than build a native app”. Weeeell, it’s not as simple as that.

Here’s a few ideas that I’ve found myself repeating lately:

  • Are you building something that should be available to a large audience where you also want a (mobile friendly) web site? Then Cordova is probably worth a look. Actually, if you get the Progressive Apps parts right, you may want to use Cordova for iOS and a “pure” web app for Android. If you’re building something for an event (like a conference!), mobile web should probably be a strong consideration. People don’t like to download an app that they will only use for a specific period.
  • Are you building an app to internal users in the company where you can control what device they use? Then you may want to consider targeting a single native platform (either iOS – if you don’t think companies should pay taxes – or Android – if you feel that mobile devices can never be too inconsistent). CSS + JavaScript has a lot of sharp edges and adding a layer of abstraction on top of a programming model also adds a layer of obfuscation. If you can get away with targeting just one platform, then go native!
  • Also, if you want to go for absolute top-of-the-class, you probably want to build (two) native apps. Anything that wasn’t build with the native SDKs will probably feel a little foreign and weird on the device. At the very least, hybrid frameworks usually trails a bit behind the newest platform developments. This means two code bases, two copies of every bug and quite possible two teams (or 2 + a backend team). You pay for style!
  • If you want something that doesn’t have to be spit-and-polish perfect but that should still feel well integrated with the respective devices and you don’t want to invest in two separate code bases, then Xamarin or NativeScript may be a good bet.
  • Finally, you always want to consider the skillsets of the team at hand. If you want something native-looking and have a bunch of JavaScript developers, NativeScript and ReactNative are your friends. If you have a bunch of C# developers, then go for Xamarin.

As a mobile developer, there’s always more stuff you should learn. This is why I co-founded the Mobile Era conference which happens in Oslo November 3rd-4th, where we will have talks on Android, iOS, ReactNative, Ionic 2, as well as IoT, beacons, mobile databases and much more. Tickets are soon sold out at mobileera.rocks

Posted in Communities, English, Mobile, Software Development | Leave a comment

How to start a Coding Dojo

I recently attended the XP Days Ukraine conference in a rainy, but beautiful and Christmas-decorated Kiev. I conducted a coding dojo and gave a talk where I demonstrated pair programming live together with Dima Mindra. After the talk, I got a few questions about how to run a Coding Dojo.

This article is meant as a guide to anyone wanting to start up a Coding Dojo, whether it’s in Kiev (Mikail/Aleksey), in Odessa (I’m looking at you, Dima!) or anywhere else in the world.

A Coding Dojo is a place to learn and have fun while programming

Quite simply, a Dojo is a gathering of programmers who come together to have fun and learn while programming. It’s always hands-on and it’s always social. In Oslo there are about 300 people who have signed up their interest. We meet on average once per month, usually in a bar. There is anywhere from 5 to 25 people who attend any given meeting.

Alternatively, a Coding Dojo can be used to describe a single event for a company or team that wants to train their developers in a hands-on and engaging way.

Coding Dojo Style #1: Many programmers, one problem

In the martial art Aikido, “Randori” means that multiple people are attacking the same person. In the Coding Dojo, “Randori” means that multiple programmers are attacking the same problem.

In order to organize a randori-style dojo, you need a computer with a development environment, a projector, a place to meet, a facilitator and 4-10 programmers who attend. Here is one way to carry out a Randori Style Coding Dojo:

  • If the group is new to test-driven development, the facilitator demonstrates the red-green-refactor cycle with a simple example (no more than 10 minutes)
  • The facilitator introduces the programming problem (kata) to solve. The Prime Factors kata is a good first kata for a group
  • The faciliator invites a partner to join him at the keyboard. The facilitator writes a first test, makes sure it runs red and invites someone else from the group to take his place.
  • Each pair works on the problem for 5-10 minutes, the facilitator then makes sure that one person in the pair is switched out with someone in the audience.
  • After about 45-60 minutes of working on the problem, call a break and review what’s happened. Personally, I’ve had success with asking everyone to name one thing that they learned, one thing that surprised them, and one thing they want to change about the way they work.
  • After the review, the group can work on another kata (problem), try the same problem again or use another exercise form

The biggest barrier for most people to participate in a Coding Dojo is that most programmers have never programmed live in front of anyone else. This feels extremely awkward and vulnerable at first. As a facilitator, your most important job is to help everyone feel at ease at whatever level they are.

Coding Dojo Style #2: Pairs working in parallel

Some people report that a Randori-style dojo can feel slow and constrained. As an alternative, I sometimes use the CyberDojo software, created by Jon Jagger. For a CyberDojo style dojo, you need a place to meet, a computer with a projector and internet access, a facilitator and 6-30 programmers with their own laptops with a web-browser and internet access. Here is how I usually carry out a CyberDojo style Coding Dojo:

  • The group forms pairs of programmers
  • The facilitator sets up a CyberDojo on http://cyber-dojo.com. (It may be smart to send a quick tweet to Jon to make sure he’s not planning to restart the server at this time)
  • All the pairs work in the fashion the group has agreed to work for 30-60 minutes
  • After the coding session, the facilitator uses the CyberDojo dashboard as a focus for discussions of programming habits

If you’re thinking about facilitating a Cyber Dojo, just go to http://cyber-dojo.com, try creating a dojo and solve a kata. You can do this on your own now!

Coding Dojo Style #3: Working under stress

Extreme startup is a workshop based around a server that will ask questions of the software running on the computer of each participating pair. As the pairs answer questions correctly, they are awarded points. I usually run an Extreme Startup session after having run a strict TDD Coding Dojo. In the Extreme Startup, teams can work any way they want.

The Extreme Startup software is developed by Matt Wynne and Richard Chatley. There are several forks, including mine, which tries to maximize the stress.

In order to run an Extreme Startup workshop, you need a place to meet, a computer with a projector and the Extreme Startup software, a facilitator and 6-30 programmers with their own laptops with a development environment of their choice. All the computers need to be on a shared network so they can communicate using TCP/IP.

  • The group form pairs. If someone wants to work solo, or in bigger groups, that is okay, too
  • The facilitator starts the Extreme Startup software in warmup mode
  • The facilitator demonstrates how to get started (I use this collection of starting points in a number of languages)
  • The teams work for around 30 minutes until (almost) everybody have been able to get a web server running and registered on their computer
  • The facilitator starts the Extreme Startup software in real mode
  • All the teams reregister their servers. All hell breaks lose as they try to implement the questions as fast as they can
  • After the teams have worked for another 60 minutes, the facilitator breaks off the competition. Ask the teams on the top to describe how they worked

If you’re thinking about facilitating an Extreme startup, download my or Richard Chatley’s version of the software to your computer. The README file explains how to get it running. Then download Steria’s collection of starting point to your computer. Use the ruby/sinatra_for_dummies starting point to create a solution. Let me know of your experiences when trying out the software, so I can improve the README.

You can do this by yourself now!

Start a coding dojo

A coding dojo is a great way to build your professional network, become a better programmer, and to have fun! I hope this article can help you get started.

Posted in Communities, English, Extreme Programming, Pair programming | 7 Comments

Agile in Europe

Can the various European Agile User Groups benefit from working together? I am cautiously optimistic.

At XP2011 this week, Jurgen Appelo has taken the initiative to launch the Agile Lean Europe network. This is an initiative to bring together representatives from 17 European countries. Sergey Dmitriev and I will be representing Norway. To what end? I’m still not sure.

There is no doubt that there is much Europeans can learn from each other. For example, Norway has long had several active user groups (Oslo XP meetup, Oslo Lean meetup, and Oslo Coding Dojo are my personal favorites). The biggest of these groups gather as many as 100 people on a monthly basis. We have also hosted a local, Norwegian language conference for four years. Last year, the conference had over 400 attendees.

Norway has also had several large public sector projects adopting Scrum, driving the commercial adoption of Agile.

Our “sweet brothers”, the Swedes, on the other hand, don’t seem to have any user groups on the same scale, but they have a local, somewhat smaller Swedish sister conference to Smidig 20xx.

However, the Swedes have several very high-profile speakers, like Marcus Ahnve, Thomas Nilsson, Staffan Nöteberg, Henrik Kniberg, and several others. In Norway, we practically only have local speakers.

Also, the Agile Sweden mailing list is very successful. We have made a few attempts in Norway of getting an online community going, but it has never taken off.

It seems clear to me that there is a lot we Agile Europeans can learn from each other. Exactly what remains to be seen.

What do you think is the future of the Agile community in Europe?

Posted in Communities, English | 5 Comments

Guidelines for eGovernment Projects

The Agency for Public Management and eGovernment in Norway is currently developing guidelines for IT-projects within the Norwegian governmental sector. The Norwegian Computing Association hosted a presentation and discussion about this work yesterday. I was privileged enough to summarize the comments from one of the three discussion groups at the meeting. For the enjoyment of the internet, I hereby provide a few ideas on eGovernment projects.

(more…)

Posted in Communities, English, Software Development | 7 Comments

How to stay ahead

This is a test case from my current project:

It seems pretty run of the mill. A tester will sit down with a bunch of these and try out the application.

Except that the tester in question is not a person! Instead it is a program named Cucumber.

I first learned the ideas behind Cucumber from Dan North at the ROOTS 2005 conference. And this year at the ROOTS 2009 conference Aslak Hellesøy, the creator of Cucumber, will give a tutorial that brings the ideas of Behaviour Driven Development as the next step in effective requirements and testing into the mainstream.

I’ve been attending the ROOTS conferences every year since 2000 and was on the committee for three years. The conference hosts world-class speakers and has a focus on up and coming ideas. It’s a small and intimate conference with tutorial style sessions that lets the speakers go into depth on their areas of expertize.

Do you want to stay years ahead in your field? Go to Bergen for the ROOTS 2009 conference April 27th to 29th.

Posted in Communities, English, Java, Software Development | Leave a comment

Lyntalemanifestet

I’ve been part of the group organizing the Norwegian language, lightning talks based conference Smidig the last two years. This Norwegian language article describes the essential guidelines to giving a short presentation.

En god lyntale kan ha enda større påvirkning enn et godt foredrag, fordi lettere kan nå flere mennesker. Men det krever innsats. En god lyntale er:

  • Fokusert: Du skal ha ett poeng, én påstand eller ett spørsmål som foredraget bygger rundt. En god lyntale er ikke kortversjonen av et timesforedrag, eller abstraksjon over erfaringer. Snakk om konkrete erfaringer. Finn det aller viktigste poenget og snakk om det.
  • Forberedt: En lyntale krever forberedelser, akkurat som et annet foredrag. Men siden det er kort har du anledning til å trene på det flere ganger. Vis ditt publikum respekt. Hold talen for en vegg tre ganger før du holder den for et menneske. Det tar bare 30 minutter.
  • Pirrende: Når tiden din er brukt opp skal du ikke ha sagt alt du kunne ha sagt, og ditt publikum skal ikke ha hørt alt de kunne ha hørt. Både du og publikum bør ha appetitt på mer informasjon.

Kan du skape mening på ti minutter? Klart du kan.

Kommentarer, eksempler på gode lyntaler og forslag til revidering av “manifestet” mottas med takk!

Posted in Communities, Norsk | 10 Comments

Er smidige målprisprosjekter mulig?

The Norwegian computing association has released guidelines for contracts regarding agile projects. Wednesday, November 26th I will be part of a panel debating this work and the combination of agile and contracts. This Norwegian language blog post contains my introductory remarks for the debate.

Kom på debatten på Oslo Lean Meetup på onsdag og delta på debatten!

Jeg er ikke en prosjektleder, en advokat eller en politikker, så jeg kan ikke si så mye om hva som må være med i en slik kontrakt. Jeg er bare en programmerer. Jeg er en programmerer som ønsker å jobbe på gode prosjekter. Jeg håper at det er mulig for meg å jobbe på gode prosjekter som også advokatene og politikerne vil være fornøyde med.

Hva er et godt prosjekt? Den enkle definisjonen er at et godt prosjekt er et prosjekt som både leverandøren og kunden, både utviklerne og brukerne er fornøyde med. For meg som programmerer er dette viktig. Og jeg tror det er viktig for mange andre programmerer. Hva er det som gjør at enkelte mennesker synes programmering er spennende? Jeg tror svaret er enkelt: Programmerer er mennesker som brenner for å skape ting som noen har bruk for.

Jeg ønsker å skape verdi, og for meg er smidige metoder en god rettesnor. Jeg tror ikke smidige metoder er et magisk ord man kan bruke for å få til vellykkede prosjekter, men jeg tror at verdiene smidige metoder beskriver forbedrer sjansene mine for å delta på gode prosjekter. Men bare dersom man forstår verdiene og ikke bare utfører tomme ritualer som man kaller “smidig”.

Jeg har jobbet noen år som programmerer. Og jeg har deltatt både på prosjekter jeg var fornøyd med og på prosjekter som jeg ikke var fornøyd med. Den triste sannheten er at de fleste prosjektene jeg har sett eller deltatt på var ikke gode prosjekter.

Derfor var det veldig spennende for meg når jeg først fikk høre om veillederen. Spørsmålet jeg håper veilederen kan svare på: Er det mulig å forbedre sjansen for at leveranseprosjekter blir gode leveranseprosjekter? Kan veilederen forbedre sjansen for at prosjektene våre blir gode prosjekter?

Jeg har lest gjennom det som har blitt skrevet med en blanding av håp og skrekk. Mitt svar er “jeg vet ikke”.

Men jeg er skeptisk. Det virker som om smidige metoder, som mye annet, er i ferd meg å bli et offer for sin egen suksess. Kan vi risikere å falle i fella at vi tror at fordi vi bruker ord som Product Owner og ScrumMaster og Sprint og Product Backlog så vil alt bli bedre av seg selv?

Det er lett å si “smidig”, men det er ikke alltid lett å gjøre smidig. Så for å forstå hva smidige metoder dreier seg om, gikk jeg tilbake til kilden.

Jeg bladde opp på http://agilemanifesto.org. De smidige verdiene er kjent for de fleste nå. De står på forsiden. Men det ser ut som om mange overser den første linken herfra. Den går til de tolv smidige prinsippene. Jeg har valgt ut tre for dere:

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

“Simplicity–the art of maximizing the amount of work not done–is essential.”

“Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”

Det jeg har fått ut av smidighet, er erkjennelsen om at vi ikke kan anta perfekt informasjon. Vi er nødt til å få feedback på det vi tror og det vi gjør, og vi er nødt til å endre planene basert på denne feedbacken. Denne grunnleggende verdien ligger bak ønsket om hyppige leveranser og mye annet.

Så jeg står igjen med et siste spørsmål: Er det mulig å lage en leveransekontrakt som verdsetter denne dype verdien om feedback? Det håper jeg å få svar på i denne debatten.

Posted in Communities, Extreme Programming, Norsk | 4 Comments

On the road: Agile development and testing

I’m going on the road again. This time it’s not far, just to Trondheim for a seminar for the Norwegian computer association that I will be giving together with Aslak Hellesøy on agile development and testing.

This will be similar to our line-up at JavaZone: Aslak will cover “how to make the correct software”, and I will cover “how to make the software correct”. Hopefully, we’ll make a few test managers think and a few others angry.

Posted in Communities, Software Development | Leave a comment

“Smidig 2007”: A conference for the community

The Norwegian word “smidig” means “agile”. So when we wanted to make a Norwegian conference for the Oslo Agile community, “smidig 2007” (November 26th and 27th) was a natural choice for a title.

The seed of the conference was idea by Nils Christian Haugen and Aslak Hellesøy to have a whole day devoted to open spaces. Meanwhile, I had been experimenting with “lightning talks” on Oslo XP meetup, a user group that meets in Oslo every month. The inception of the open spaces conference was delayed over the summer, and towards the end of the summer, Trond Pedersen and myself were discussing the success of the Oslo XP meetup lightning talks over a beer. The more we thought about it, the more it seemed natural: We need a whole day devoted to lighting talks. Meanwhile, Simen Fure Jørgensen decided to start up Oslo Lean Meetup.

We tossed the ideas around on the smidig.no forum for a while, and Christian Hauknes noticed how disorganized we all were about it, and decided to make it all come together. Along the way, many enthusiasts have contributed. Without them, it would all still be a fantasy in the minds of a few people.

Finally, we all came together with a single vision: A two day conference for the community, by the community. We know that there are a lot of people with extremely valuable experience who seldom get heard. Instead, conferences focus on big names that tend to overshadow the participants.

We hope that Smidig 2007 will be different. Both days of the conference are devoted to ways to get the participants to learn from each other. Open spaces workshops allows for in depth exploration of topics and experiences, while Lightning Talks, a presentation form that limits all talks to 10 minutes, allows for a wide range of point of view and experience.

Over 50 speakers have already signed up. For a conference where we expect a total of not much more than 200 participants, this is great. I’m overwhelmed by the great support of the business community. Over 20 sponsors have signed up, ensuring that we won’t go broke in the process of pulling together this conference. We have the budget to pull of a spectacular conference dinner, video recording of the whole event, and the most interesting venue in all of Oslo.

There are still a lot of things that could be improved. If you read this blog, and you would like to play around with the Rails-based conference application, organize a conference dinner, organize an open space conference, write about the conference, discuss experiences using agile principles on the forum, or help move chairs and table around during the conference, we would like your help. Or even better: If you yourself see room for improvement. Send an email to the conference mailing list to get in touch with us.

I have always been impressed by the insights of Oslo software professionals. I am looking forward to hearing a dozens of them speak in November.

Posted in Communities, Ruby-on-Rails, Software Development | 1 Comment