Thinking Inside a Bigger Box

I don’t normally post just a link to another blog, but More thinking about “Agile” vs “Waterfall” by Jason Yip is just too important. It the most well-argued, well-referenced, short post I’ve seen about the subject. Here’s a taste:

Be careful about saying that Waterfall is more disciplined. The waterfall model is simple and structured but the “discipline” is in following prescribed steps as opposed to “discipline” in thinking. The second kind of discipline is by far the more important.

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.

Read the rest of this entry »

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.

Jeg har forfattet et svar på rapporten.

Spesielt er jeg bekymret for at dette skal bli en unnskyldning for store SOA-prosjekter uten veldefinerte formål. Rapporten beskriver en god del ønskede effektmål, men disse beskrives i såpass runde former at man aldri kommer til å etterprøve om prosjekter faktisk oppfyller dem. Formålene er ting som økt grad av interoperabilitet.

Frykt nummer to ligger i hvordan SOA-krigen går om dagen. Rapporten nevner veldig lite konkret på teknologier, så jeg slapp unna å gå inn i dette minefeltet. I stedet må jeg ligge våken og frykte effekten av de usagte ordene i rapporten.

Jeg har startet å høre om dogmatiske SOA-prosjekter som ikke lykkes, til tross for store investeringer. REST starter å bli mer akseptabelt å snakke om i høflig selskap. Men fremdeles virker det som om at “SOA prosjekt” er et kodeord for “vi skal kjøpe dyr WS-* programvare fra Oracle, IBM eller Microsoft”.

Jeg skulle ønske jeg hadde mer erfaring innen offentlig sektor før jeg skulle uttale meg om dette, men dersom det er som noe annet jeg har sett, handler interoperabilitet grunnleggende sett om å sende eller motta informasjon på et standardisert format. Det betyr tre ting: En aksjon (les, oppdater, lever), noe som identifiserer et objekt (søknad, personopplysning) og et innhold (”Jeg ønsker med dette herved å søke om bla bla bla”).

Og her har WS-* skadet oss mye. Når man bygde standarden SOAP (Simple Object Access Protocol, som verken er enkel eller handler om “object access”), skrellet man vekk to fine deler av HTTP standarden: Verb (GET, POST, PUT - det vil si “aksjoner”) og URL’er (det vil si den nøkkelen som representerer et objekt). Det betyr at vi ikke lenger kan si “legg til” (POST) en “søknad” (http://etat.no/tjeneste/soknad/) som inneholder noe data (ikke en del av standarden). I stedet må vi si “send en melding som inneholder informasjon om noe vi tenker å gjøre” (ikke en del av standarden).

I en rimelig verden burde interoperabilitet betydd at å utveksle informasjon om objekter burde være en del av en universell standard som er akseptert rundt hele verden. En standard basert på å sende meldinger om å utføre én eller annen oppgave (som for eksempel å utveksle et objekt) virker sørgelig utilstrekkelig. Og offentlig sektor i lille Norge kan vel ikke være den som brøyter vei her.

Så lenge SOA-krigen pågår er jeg ikke optimistisk for sjansene til at en rimelig standard dukker opp.

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? These interfaces are the scraps of the service table.

If this is true, why do so many system diagrams display the “service” layer for external users below the user interface layer. It should be next to the human user interface layer, shouldn’t it?

External programmatic interfaces, whether they be SOAP, REST or otherwise, must be treated as any other user interface. This means both to understand the needs of the non-human users and to only develop parts of the service interface that are needed now.

Any user interface expert will tell you: There are no taking-backs with user interfaces. Once you’ve given something to the user, they will react very negative to substantial changes. The non-human user is even more unforgiving. Yet, the scraps of the system internals that we give them will be even more necessary to change.

If the users judge your service by its interface, we should only give non-human users interfaces that are developed based on their requirements, and that we don’t mind never getting to change.

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.

Steria has lots of very talented people, and I’m still looking for the best way to help the organization in my new role. I hope I can personally teach a lot of people the architecture and testing techniques that I’ve learned over the last years, and I hope I can help the people who actually produce the results that are needed at the end of the day get a stronger voice with our management and our customers.

Watch the thrilling story: What happens when you take a domesticated programmer out of his natural habitat and put him into a new world. Will be be overwhelmed by the differences, or will he be a new invasive species in the foreign ecosystem?

(Yes: I will insist that my proper title should still be JustAprogrammer. How long will I get away with it?)

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 located the test and found that it was close to unreadable. After examining it further, I found that it was trying to do was simple, but hidden in technical code.

Read the rest of this entry »

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. While JBehave 1.0 used anonymous inner classes to do this, JBehave 2.0 uses annotations:

public class PlayTabSteps extends Steps {
 
    @Given("tab $asciiTab")
    public void tab(String asciiTab) {
    }
 
    @When("the guitar plays")
    public void guitarPlays() {
    }
 
    @Then("the following notes will be played $notes")
    public void theFollowingNotesWillBePlayed(String notes) {
    }
}

For more, see Ray Greenhall’s tutorial. The tutorial is good, but it suffers from an unintended large weakness: The second half of the tutorial contains the convoluted design that is often the result of overuse of mock objects. The last year, I have spent more time removing mocks from code than actually using mocks, and I’m just about fed up with mock-ish design.

Can you spot the nefarious effect of the mocks on the design? How would it have looked if the example had followed The Simplest Thing That Could Possibly Work?

(Still: A very good introduction to a promising new tool)