Sharing and Learning in the European Communities: SoCraMOB

November 20, 2013

Last week I was invited by Marco to be part of the awesome series of Open Space events organized by the Software Craftsmanship (Softwerkskammer) community from Münster, Osnabruck and Bielefeld. These Open Space events are organized by the local Software Craftsmanship community that consists of software professionals from the three cities. A couple of years ago, they decided they cannot have evening meetings like in other bigger cities to learn from each other because of the distance between the cities, so they started to organize an Open Space. So they called the event MOBenSpace.

For this edition, around 25 people were present. The venue was a local company from Osnabrück, ASD GmbH. Almost everyone was present at 9:00, when our host Marco introduced Markus as the facilitator of the Open Space. Markus started to explain what Open Space is and we started to fill the Market Place. The Market Place is the agenda of the meeting, created on the spot by the attendees and each item is explained briefly to the audience by the proponent. At the top of the post is a picture with how the Market Place looked like for the first half of the day.

You can find more details about Open Space here.

For the first session I attended the discussion about Model-Driven Software Development. We mostly talked about how UML is a failed model for visual programming and for auto-generating a product. But we also talked about Behavior-Driven Development and other related subjects.

After this discussion I presented my ideas on Incremental Design and how Test First Programming (TFP) is very different than Test Driven Development (TDD). In my view a lot of programmers think they are doing TDD, but in fact they just follow a design that they thought about beforehand. And this is not TDD, because when doing TDD you are creating the design incrementally, step by step. TFP is a way of writing the tests first and knowingly guiding your design towards what you thought beforehand. The distinction was very important especially because we were talking about incremental design which happens when you do TDD. So I underlined the idea that TDD is a design tool and the tests are just a bi-product. Here is a flip-chart picture from during the session when I was talking about emergent design.

IMG_3543

I went into details on how I would start an implementation of a tic-tac-toe game, what would be the scenarios and which tests I would consider writing at the beginning. Then we talked about changeable design, and how incremental design helps you have a very decoupled code which can be changed easily. We also talked about the four elements of simple design, which I use for making abstractions emerge. After a long discussion, Jan asked me if I could do again a coding demonstration on TDD as if you meant it on the example we discussed: tic-tac-toe. So I committed to add a session in the afternoon on this topic.

At the end of the session we discussed about the difference between being a mockist and a classicist when doing TDD. In just a couple of words a mockist would do more design up-front, and focus more on testing the collaboration between two or more classes, while a classicist would not start with any up-front design, and would write more tests based on inputs and outputs (state tests). The basic idea is that any programmer is on a line between the two extremes. But depending on the situation we need to adapt on being more mockist or more classicist. And the way we adapt is a measure of our testing skills as a programmer. Here is a picture with some of the differences between a mockist and a classicist.

IMG_3546

After the lunch we discussed a bit about the problem: tic-tac-toe. We wanted to simplify it as much as possible, so we chose to have a very simple board where the result is clear. We started with a board having just one cell, instead of 9 on a full tic-tac-toe game. And then I started writing some code in java on this topic. We were discussing while I was writing the code based on simplifying the board, and increasing the size of the board when we want to introduce new elements. This was deliberate, as I wanted to introduce just one notion at a time as I usually do when I work with TDD. We had planned the session for 45 minutes, but it must have lasted around one hour and a half, just because there was a lot of interest in seeing this “odd” way of extreme incremental design which is called TDD as if you meant it. You can see the code we ended up on GitHub.

After this session I was quite tired, so I attended here and there. I talked a bit about contract tests and how they could be used for the collaboration between components.

In the end I think this event was worth all the 3000 km traveled because the attendees were passionate professionals who shared their experience about software development. I enjoyed a lot the way Markus facilitated, and I stole some ideas from him. Thank you Marco for inviting me, and thank you Markus for facilitating this event. We will see each other soon!


If you are worried about your tests or you want to find more about creating the design incrementally, we can help with a customized assessment of your process or learn more about:

Those workshops are also available in-company.

Categorised in: ,

Leave a Reply

Your email address will not be published. Required fields are marked *