.NET Open Space 2011 (Leipzig) - Review

by anton 24. October 2011 15:21

I have been again to the .NET Open Space in Leipzig. This time with my colleague Oliver.

I have written a Review last year. I want to take the opportunity to write what has changed in teamaton since then:

  • We took a few steps towards a more agile development. We think these were steps in the right directions :). Since we started with two new projects, we could practice different approaches. I still haven’t looked closed at Scrum and XP.
  • We implemented a good GIT workflow, even without the git flow software.
  • We are by far more disciplined when testing – even though there is still room for improvement. Mark has automated many of our Selenium tests. We work much more often according to TDD. With our last project we started with SpecFlow, that is with behavior driven development.

Back to the Open Space of this year. I liked it. It was refreshing to see so many developer from the .NET, and talk to them. The first day was not as interesting regarding the sessions as the second day. The atmosphere was good – there were more than 150 people, many from Berlin, where our office is. Everyone could kegel, get a massage, and participate at different lotteries.

Here are a few topics, where I joined the discussions.

NET Open Space Time Wall

Message Queues (RabbitMQ)

I haven’t thought about message queues a lot. Yet, we do have an area of application for those: Sending emails from within a web application.

Why should one use MQs?

  • separated systems – therefore a higher reliability of the different components
  • scalability with all the pros which come along
  • no waiting on feedback – important for long actions
  • the queue is persistable – does not get lost in case of a crash

How does it work? One or more publishers push messages into a queue. There are one or more subscribers listening to the queue, and work off the messages. Publishers can push different tasks to different queues, which then are listened to by different subscribers. One can imagine a system of prioritization with this feature.

Tools: We discussed a small example with RabbitMQ (und EasyNetQ). We talked about the differences to MSMQ und NServericeBus. As it seems, RabbitMQ is more powerful (applicable to different platforms), but MSMQ is easier to understand for beginners.

Agile Development

First we discussed the division between ProductOwner and ScrumMaster. Then we talked about how detailed UserStories should be written out, and who should create them. All in all we concluded that UserStories should first be roughly described by the ProductOwner and then refined with the help of a developer while talking about the problem at hand.

As a takeaway I will try to promote more feedback meetings or retrospectives in our firm. We should compare more often our expectations and the reality and impediments. Many other firms organize estimation meetings, where they also define acceptance criteria – maybe we should do something like that, too. I want to look into Scrum, even though we are not enough people for this process, but there may be ideas we can apply to our little firm.


There were a few sessions to CQRS, because it was new to many of us, and very interesting. Command-Query Responsibility Segragation is an architecture pattern, has many different aspects which for themselves are already patterns. It is also found under the name of CQS (Command-query separation).

It is (for me) a totally different approach at saving data and retrieving it. There is much emphasis on the thought process and the domain model. The patterns starts with the user and his/her actions, not with data objects. These actions are translated into commands, which are processed and generate events. These events are basically incremental steps to changing the state of the database. They are saved in an append-only database, so they do not get lost. These events can then be used to update denormalized databases where the views are saved. That way you can get fast access to the data you want to display to the user. (See also the CQRS-Website from Gregory Young with a long introductory video, and an article byMartin Fowler.)

We looked at a small Example (quellcode), where you can see that it does not take much to apply this pattern

I hope that we at teamaton will try this architectural pattern out on a new coming project. I like it a lot, especially the focus from the beginning on a sophisticated domain structure.

At last a few smaller things I ran into at the Open Space:

  • As a developer you often come to point where you ask yourself: Should I use existing software or program it myself? We should try to estimate the costs without a bias towards self-development. We should try to analyze the existing software more thoroughly.
  • I would like to learn more about REST and RESTful web-services.
  • I will read through the articles on heise online “Clean Code Development in Brownfield-Projekten”: http://www.heise.de/developer/artikel/Clean-Code-Developer-in-Brownfield-Projekten-855114.html
  • If you start with a Brownfield-Project, you first should write acceptance tests.
  • I was not at the session about Software Craftsmanship, but I will look into this site: http://groupspaces.com/softwerkskammer.

Next year will be again a .NET Open Space in Leipzig: 20th and 21st of October 2012. Thanks for the Organization!

NET Open Space Organisators


Learning More about Project Management

by anton 7. October 2011 15:49

After listening to the interesting interview from Mark Phillips by Tim Keirnan, I wanted to jot down a few points which I think are important to us as teamaton.

  • Project managers are not only there to distribute tasks. They should understand the customer and his or her needs. Afterwards he has to define goals for the project, and translate these goals for the different groups involved in the project (designer, developer, tester). Only after that has happened, can he transfer these goals into tasks.
  • Most of the difficulties (80%) occur because they are weaved into the project from the very beginning. There needs to be a clear vision (definition is crucial) – otherwise there will be friction and competing visions.
  • Work expands so as to fill the time available for its completion. That rarely happens in our team. Our difficulties arise from not making estimates and not having a fixed point for completion.
  • Multitasking is not a good idea. One should concentrate on one project, instead of trying to push two, three or even more forward. If you have more than one project to work on, try to separate them (don’t switch during a day or even a week).
  • Projects should be prioritized. So when time is getting scarce you know which projects can be halted to free capacities.

After that I looked at the Theory of Constraints and the five focusing steps:

  1. Identify the Constraint:  We are now working more with Kanban, and are sure to see at which stage work is piling up.
  2. Decide How to Exploit the Constraint: We try to distribute the work according to the load. We try to let the developers focus on programming, because they are usually the bottle neck, and give their other tasks to someone else.
  3. Subordinate Everything Else to the Above Decision: We can be more effective in this step by defining precise priorities.
  4. Elevate the Constraint: We are thinking, for instance, about hiring a student software developer.
  5. If the Constraint Has Been Broken, Go Back to Step  1: We haven’t reached that step, but will keep that in mind – trying to better the performance of our projects.



About the author

Something about the author

Month List