Here is a wordle of my blog: (Inspired by Thomas Ferris)

Warnings are useful. You get warnings from your IDE when you write something that might be a bug. You have probably made your program print out warnings or error messages when something goes wrong. But too often, we down in the sheer volume of warnings. Then it’s impossible to separate the relevant and important warnings from the noise. To make warnings useful again, I use a zero-warning tolerance policy. Even if the warning is irrelevant, I fix it.

This Norwegian language post describes my response to the report from a task force exploring a common IT-architecture for the public sector in Norway. Den norske regjeringen har besluttet at en felles IKT-arkitektur for offentlig sektor ville være fint. Jeg fikk greie på arbeidet på tirsdag, og har lest rapport til den store gullmedalje. Jeg er fortsatt ikke helt sikker på hva som menes med “felles IKT-arkitekt”, men jeg kan se omrisset av mange store evighetsprosjekter i dokumentet.

Sometimes it feels like I’m stating the obvious. But the fact that users only care about the interface of the service is something we often say, but seldom understand. If this is true, how can we think that we can develop the interface as an after though to the central system. Not all your users might be human. And the computerized users are treated even worse. If the non-human users also care about the interface, how do we think that they will be satisfied with the same interface that is used internally between different parts of the application?

I am changing employers. As of October 1st, I will no longer be lead software architect at BBS Nordic. Instead, I will be the chief scientist at the Norwegian division of Steria. This weekend, I was invited to join my new employer at their gathering at a resort in the south of Norway. I’ve had a chance to speak with a lot of my new colleagues, and I was overwhelmed by the number of skilled, thoughtful and friendly people.

I’ve learned the value of dealing seriously with connecting requirements to the actual code. The JBehave project started work to make formal, “business friendly” requirements into executable specifications, but due to limitations in Java, it was very clunky to use. JBehave 2.0 has just been released, and it has a much better model. Here’s a specification: Story: Play Tabs As a music fan I would like to convert guitar tabs to music So that I can hear what they sound like Scenario: My My Hey Hey Given tab e|--------------------------------- B|--------------------------------- G|--------------------------------- D|----------0--0------------------- A|-0--2--3----------2--0-----0--0-- E|------------------------3-------- When the guitar plays Then the following notes will be played A0 A2 A3 D0 D0 A2 A0 E3 A0 A0 The scenario is connected to Java code.

I’ve looked over some of my code lately, and found ways that I often improve my tests. I’m planning on writing a blog post for each of my five favorites. First out: Using the data storage. I upgraded our API for billing customers. I had a few compilation errors in my code, as the API had changed somewhat. After fixing these errors, I was left with a test that broke mysteriously with a MethodNotFoundException.

I just watched another amazing talk from the TED conference. Spencer Wells is a natural public speaker. He talks about where we all, as a species, came from. Amazingly enough, everyone who is alive today share a common ancestor in Africa no more than about 2000 generations, or 60,000 years ago. Wells describes the fascinating questions and their answers, as we know them today. The TED conference is full of remarkable talks.

Looking back at my projects for the last two years, we’ve had a tremendous improvement in the way we’re working. There are many things that we have done to make it better, and I’m be hard pressed to pick just three things I’ve learned. After much consideration, my favorites are: Partial production; Whole team; Requirements = Tests. Partial production: Using real production data for production in various scenarios has been extremely helpful.

When the building blocks of your program fail and you don’t notice, the problem can be very hard to diagnose. In most of my projects, the building blocks are the persistent objects. Using Hibernate makes it easy to create a data access layer, but if you don’t watch out, errors can sneak into equals or hashCode, bidirectional relationships or properties that for some reason don’t get persisted correctly. Or the code you use to search for your objects can be wrong.