Just pick a price

by anton 14. January 2013 16:31

Joel Spolsky wrote an interesting post Camels and Rubber Duckies. Beware, it is an old post, and some things have changed since then. Yet, I liked the second have of his post, where he writes why segmentation pisses your customers off. And also, how you can never know for sure how your demand curve looks like.

If you are into the psychology of customers, watch the BoS Talk by Rory Sutherland: Praxeology - Lessons from a lost science.

I will end with a sentence by Joel Spolsky: The more you learn about pricing, the less you seem to know.


Learning Collaboration: Coding Dojo and Kata

by anton 8. December 2011 12:09

Yesterday I once again participated in a coding dojo – it’s been a while. These events are organized by the ALT.NET User Group Berlin.

We were 13 people. We formed three groups with one Laptop each. Each group got the same assignment – the tennis kata. It is a pretty simple task, which has to be completed in about an hour and a half with TDD.

What is interesting is not so much to implement the best solution. To me, it is more absorbing to see with what ideas the others in my group approach the problem, and their art and philosophy of coding. It’s always inspiring to see other methods performed live. Solving the problem is then more about finding a common language and agreeing on one solution and, if possible, on one coding style. It’s challenging to persuade the others that the approach one has in mind is a good one. The setting of four people per one computer enforces cooperation – a good skill to hone.

I like the coding dojos, and will try to participate again in the next one. Landau Medien was fine host – they provided their conference room and sponsored soft drinks, beer and pizza. Thanks also to Jan and Mike for organizing.


.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.



Agile – Last Man Standing

by anton 11. March 2011 11:51

We (teamaton) are beginning to develop a new web application, a ToDo-Management-Tool. It is our goal to be better at everything revolving around the process of developing this new application. Everyone at our company is diving into reading about and testing new tools and processes.

I took on the part of reading about different approaches to developing software, finding out about the pros and cons, figuring out which one probably suits best our needs, and gives us great power to develop the application effectively. I found the Wikipedia article on software development methodology, and went on from there to the different approaches.


Different Approaches



One approach is the Waterfall model, which is a sequential development approach with the following stages: requirement specification, design, implementation, integration, testing and debugging, installation, maintenance. This model assumes that all requirements are specified at the beginning. This is seldom the case.

There are many approaches which try to overcome the deficiencies of the Waterfall model. Seemingly all of them fall under the category of Software prototyping. Its main features are risk reduction, ease-of-change during the process, and involvement of the user.  For large projects some companies use Spiral model. Here the system requirements are defined in as much detail as possible to identify and resolve risks in the software development process. Our project is as yet not that large. Therefore we analyze risks only rudimentarily.

Rapid application development comprises many modern software development methodologies, like Agile software development, Lean software development and Scrum. The project is broken into smaller segments to reduce risk and provide more ease-of-change. Users are being actively involved in the process, and the software is build iteratively.


Iterative and Incremental Development Methodologies


Since requirements may change or the product owner may not now all requirements at the start iterative and incremental development methodologies are being used. The basic idea is to develop a system through repeated cycles of planning, design, implementation, testing and evaluation – and develop small portions of the software at a time.


One example is the Unified Process framework, which is iterative and incremental, use case driven, architecture centric and risk focused. Similar frameworks are the IBM Rational Unified Process and the Agile Unified Process.

Agile Development


Essentially we will use Agile software development. It allows for changing requirements, regular adaptation of the process, delivering working software frequently, getting feedback, and higher customer satisfaction. It promotes simplicity and trusting in motivated individuals involved in the process.


There is still much to learn about agile development. It is the superordinate concept for different software development methods like Scrum, Feature Driven Development, Extreme Programming. I will read about these in the near future. As a team we will need to adopt the mindset of agile development more thoroughly. The biggest mistake for teams using agile development seems to be to put implementation of the process over changing the way of thinking.


software development | methodology

About the author

Something about the author

Month List