March 16 - 17, 2010



Telephone: +46 31 703 31 85


Find your best way to the conference with Eniro map or with GoogleMap:

Brian Marick

Brian Marick1Brian Marick was one of the authors of the “Manifesto for Agile Software Development”, is an Agile consultant, and wrote Everyday Scripting with Ruby and Programming Cocoa with Ruby. He speaks frequently. This year, he keynoted at Agile Roots and Ágiles 2009, and spoke at MountainWest RubyConf, Future Ruby, and Agile2009.

2 Recently the authors of Growing Object-Oriented Software, Guided by Tests, Addison-Wesley, 2009.

3 I learned the phrase “sashimi” from Ken Schwaber, I believe. I’m not aware who originally invented. It might have been him.

4From The Pragmatic Programmer, Hunt and Thomas, Addison-Wesley, 1999.

5 A browser-side language built on top of Javascript.

Track abstract - Development Process & Methodology

Artisanal Retro-Futurism

"Artisanal Retro-Futurism crossed with Team-Scale Anarcho-Syndicalism" - a problem with Agile is that everyone wants to be it. Who wants to be thought of as the opposite of Agile? Torpid? Sluggish? Rigid? So I resolved to capture the essence of Agile with a phrase so obscure that no one could say "Why, I'm that, of course!" without having to understand what "that" was. Although the name is deliberately obscure, each word does in fact matter, and the whole does in fact capture a bit part of what I think Agile is all about.

Track abstract - Development Process & Methodology

Seven Years Later: What the Agile Manifesto Left Out

Although the Agile Manifesto has helped many organizations change how they build software, the agile movement now suffers from backsliding, overselling, and a resulting backlash. Brian Marick believes that is partly because the manifesto is focused outwardly; it tells the business how the development team will work with it. What it does not talk about is how the team must work within itself and with the code. Watch Brian’s presentation to find out whether you're really doing agile or if you are agile in name only.

Track abstract - Testing

I think I finally understand MOCKS

To my lasting embarrassment, I reviewed the very first paper on mock objects, "Endo-Testing: Unit Testing with Mock Objects" (Mackinnon, Freeman, Craig), and completely missed the point. Like many people since, I mistook mocks for stubs. That confusion was quickly cleared up–and yet, as I came to hear more about what’s sometimes called the “London School” of test-driven design, particularly as represented by Nat Pryce and Steve Freeman2, I remained puzzled by the consequences of mocking. Representatives of the school described it as placing the emphasis on defining the interactions between objects, rather than on defining classes. It was easy to accept that intellectually, but I didn’t understand what it meant for program design or the act of programming. Now I do, I think, and I think I’ve hit upon an interestingly odd way to explain it: 1. In the early days, what we now call test-driven design (TDD) was known as test-first programming. The name changed after practitioners realized how to create tests that (a) ran fast and (b) didn’t break wholesale when the underlying code changed. They did it by building programs that had properties we knew all along were important: high cohesion and low coupling. But until TDD, the short-term cost of those properties kept us from enjoying their long-term benefits. TDD made them–and good design in general–matter to us right now because we care about ease of work. So we did what we should have done all along. 2. Mocks make programming even easier, especially when programming is done in “sashimi”3 or “tracer bullet”4 style, where classes are changed or modified in the order that user input would encounter them. 3. More importantly, programmers using mocks have more control over the pacing or cadence of their work. Working with mocks leads to a steadier pace than ordinary TDD. 4. The desire to control pace produces designs even more uncoupled and cohesive. In the talk, I’ll explain my claims in more detail, using examples from a web application I’m writing in Ruby and Objective-J5. I’ll also discuss the weaknesses of mocks (mainly expectation mismatches) and how they can be handled.


Scandinavian Developer Conference is organized by
Visit us at