Thinking Inside a Bigger Box

På dagens møte i IASA Oslo fremsatte jeg påstanden at vi trenger en “vær-varsom plakat” for arkitekten. Spesielt fokuserte jeg på virksomhetsarkitektens rolle og risiko.

I diskusjonen etterpå kom vi inn på mange av aspektene og det var mange veldig gode forslag der jeg ikke fikk notert meg alt, så jeg har utelatt mange ting som kunne vært sagt.

Her er mitt førsteutkast til “vær-varsom plakaten”:

• Hold tilbake til innflytelse: Når du foreslår en løsning, kan løsningen bli valgt ukritisk. Når du tar ansvar for en løsning, umyndiggjør du de som skal utføre jobben og gjør dem i dårligere stand til å ta ansvar i fremtiden.
• Vær forsiktig med å foreslå løsninger: Løsningen du foreslår har høyere kostnader enn du forventer. Løsningen du foreslår løser problemet dårligere enn du forventer. Problemet du løser er mindre alvorlig enn du forventer.
• Byråkrati koster: Alle tid brukt i møter er tid som ikke brukes til fremdrift. All unødvendig informasjon (for eksempel standarder) som blir gitt fjerner oppmerksomheten fra en bit viktigere informasjon.

I stedet kan en arkitekt fokusere på å være en kulturkatalysator:

• Skap fora for andre: Du har en unik mulighet til å støtte læring og erfaringsutveksling mellom de som utfører jobben.
• Fremhev andre: Dersom du kjenner andres sterke sider og forbedringsønsker, har du mulighet til å bidra til andres personlige vekst.
• Vær et talerør: De som gjør oppgavene har ofte vanskelig for å få gehør for sine problemer og behov. Formidle disse problemene til ledelsen og hjelp sett fokus på daglige forbedringsmuligheter.

In this second podcast in the Oslo Developer Conversation series, I talk with Robert Martin about FitNesse. We discuss the origins of FitNesse and it’s relationship with Fit, the relationship between acceptance tests in FitNesse and unit tests and the new Slim-tables in FitNesse.

See the (English language) podcast at ProgramUtvikling’s site.

This is a test case from my current project:

Scenario: Finish gathering information
  Given I have an open case
  And the case has a task "gather information from X"
  And the case has a task "gather information from Y"
  When the user confirms that task "gather information from X" is completed
  And the user confirms that task "gather information from Y" is completed
  Then the case should generate a new task "evaluate customer standing"

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.

Doing the Code Dojo at Oslo XP meetup last Monday, I realized a new concept that I’ve been using unconsciously for a while: I only add to the structure of my system when I have a test that cannot be satisfied by the current design. The rules of test-driven development tells me to wait to create a more advanced design until I have a reason to do so. And that reason should be a failing test. However, the rules of refactoring require all tests to be green during a refactoring. So the failing test must be Ignored during the refactoring.

I revisited these ideas last Wednesday in my second Code Dojo this week in form of the problem of Yahtzee.

If you start solving the scoring rules for the game of yahtzee using the simple examples of “ones”, “twos” and so on, you will run into a problem as you approach, say full house. A full house in yahtzee is scored for example, when you roll three fours and two fives on your five dice. That is:

assertEquals(18 + 10, scoreFor(YahtzeeCategory.FULL_HOUSE, 5, 6, 6, 5, 6))

When I first solved this kata, the test for full house meant I had to take a step back. My solution was to come up with the design of creating a method to calculate the frequency of each die value. This could for example be represented as an array, so that

assertEquals(new int[] { 0, 2, 1, 0, 2, 0 },
                  calculateDieFrequency(2, 3, 5, 2, 5))

This refactoring also changes the implementation of ones, twos, etc:

public int scoreForOnes(int[] dice) {
    return calculateDieFrequency(dice)[1];
}

Clearly, I don’t want my tests to fail while I execute this refactoring. This means that the test for “full house” must be @Ignored (or commented out) during this change. Moreover, the existence of the test for “full house” is the very reason I want to introduce this more advanced design.

Thus: Only refactor to more a more complex design while you have an @Ignored test that cannot pass with the current design.