The last couple of months have been full speed and not much time to reflect and write. The fact that we’re pair programming on the team gives me less time to think about great blog subjects. As an architect, it’s hard to find enough time to complete a meaningful unit of work without doing the dreaded “architect-commit-and-run” move. However, I found that when I have time to program, the pair programming culture on our team works really well.

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.

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. Comments: jhannes - May 26, 2009 In the PodCast, Bob mentions Parnas tables as an inspiration for FitNesse table structures.

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.

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.

Agile development is easy to understand and hard to do. One of the hardest things to do is to base plans and actions on value instead of effort. An article by Alistair Cockburn includes a story that illustrates the point: A boy is behind on his German language home work. He now has to read ten stories and answer a set of question for each. He will be graded on the number of correct answers.

My friends at ProgramUtvikling just published the first PodCast in the series Oslo Developer Conversations. In this PodCast, yours truly interviews Uncle Bob about software craftsmanship. The podcast is still only available as video, but audio will come shortly. I had a great time doing this interview and I’m particularly happy that we managed to have a good combination of a technical discussion and an informal discussion. I’m looking forward to doing lots more of these in the future.

I’ve all but stopped using mock objects in my tests. The reason is that mocking have had a detrimental effect on the design of my systems. I’ve often ended up having the mocks trick me into adding a needless layer of indirection that does nothing except delegate to the next layer, just to satisfy the mocks. For a while, I was wondering whether I was the only one with this problem, but then I saw this tutorial on JBehave, which so perfectly illustrates the problem I saw myself doing.

The hard choice between duplication, paralysis and chaos A common programmer credo is “Don’t Repeat Yourself” (Pragmatic Programmer) or “Once and only once” (Extreme Programming). Like all credos, we risk following it even when it is not appropriate. The larger truth is that we have choice between three evils: We can duplicate our code, thus duplicating effort, understanding and being forced to hunt down twice. We can share code and affect everyone who shares the code every time we change to code to better fit our needs.

The following is a trick I don’t use very often, but when I do need it, it comes in very handy. It’s a trick that many developers aren’t aware of, even though it’s been possible to do with JUnit at least since version 3. Sometimes you want to have a lot of tests that are almost the same, but that contain different arguments. For example, for a yahtzee calculator, you might want to have the following tests: