Taking the Bus – a Metaphor for Teamwork

Teamwork and Management

I want to introduce a hopefully helpful metaphor to show the differences between working in a team and trying to control the team from the outside.

Let’s take the bus

Imagine somebody invites you to take a trip with them. They own a bus and want to travel a rather long distance to somewhere in the south. They have a vision and a rough plan. But they do not know whether or where there will be traffic jams, blocked roads or bad weather.

This is how it might feel working in a team.

Sometimes people leave the bus; sometimes new people enter, sometimes people return. From time to time the driver will pass the steering wheel over to another driver. Every now and then you have to repair some parts of the bus.

…feel free to imagine…

I want to know when the bus will arrive

Now imagine local transport: There are strict plans for stops, routes and times. This expands even to long distance buses. These plans are great if you want to take a trip within well-known environments; yet even there delays may happen…

This is the manager’s view. He looks at the bus from the outside and loses contact immediately after departure. The only information of the travel is the plan or second hand information (telephone, gps …)

By this outside view from a controller’s cockpit you get different information. Maybe you learn about a blocked road and you can inform the bus driver to change the route long before she approaches the blockage. You can also see how far it is from the expected destination if you have suitable information.

So why should I care about that?

Often we find ourselves to have rather hostile attitudes towards the other group. No matter if you personally feel more like a member of the team or rather the manager. Neither of these groups is superior to the other. Each has its own strengths and weaknesses.

Reflect – think about it

It’s up to you and your mates to generate a massive impact of this. The impact can be really positively pushing or massively destructive.

If you are aware of your position’s strength and weakness, help the other side grow awareness, too.


Bye, I’ll catch the bus now…

Do you take it? – i.T.A.K.E.

I haven’t written an article for a long time. It’s time to come back.

During the last two days the i.T.A.K.E. unconference took place in Bucharest. I had the honor to be one of the presenters there. But I don’t want to speak about what I presented. Instead I want to thank the organizers and the visiting crowd that they created such an awesome event.


I felt really welcome and taken care of. I want to explicitly mention the organizers of Mozaic Works. They are a family that is open minded and open hearted and they let us be part of their family. The location was pleasant and – apart from minor problems (audio and video) – it went very smooth.


You people have been a great mix of experienced and fresh faces. Everyone has been very open and curious. I had many interesting and inspiring conversations about coding and team dynamics. It especially is worth going out with you in the evening.


In talks, I learned about a frontend developer’s perspective of the code (thanks @gion_13), found an easy way to explain “ports and adapters” (thanks @johan_alps and @sanlaville) and much more. But what really made my week was the keynote of @felienne. I usually do not like to listen to academics talking about software development. She changed my opinion.

Bottom Line

I am sure the event will happen again next year. It is definitely a “Not-To-Miss-Conference” if you are passionate about software craftsmanship and giving and taking.

Currently I am still sitting in my room in the conference hotel. A warm feeling is creeping up my belly when I think back of the last hours. Thank you Bucharest!


How I Made My Dream Come True

It’s been a few weeks ago. It has been a highlight in my life: SoCraTes 2012!

It started out as an idea around 2 years ago. I had been visiting quite a lot of events here in Germany: conferences focussing on programming, on agile coaching. – They have been OK. Still, something was missing:

Passion for “Good Programming”

The events were either focussing on technology or on processes. Truly, both are important. Yet, you do not need a fancy process nor do you need the latest technology to create great software. What you definitely need is great developers. People who know their craft. A craft that consists of much more than a programming language or frameworks or mastering the skills. It requires a sharp mind, curiosity, passion as well as communication skills, discipline, creativity.

The dream

Let’s organize an un-conference similar to the Agile Coach Camps focusing on Software Craftsmanship.

It started during XP-days 2010 as an open space session. There we founded the initial organizing group. The result was SoCraTes 2011 with about 50 attendees. During the event some of the attendees decided to continue the experience of learning and sharing by creating user groups all over Germany. That has been the ignition of Softwerkskammer. Currently it consists of more than 350 members and 9 regional groups.

This year we followed up with SoCraTes 2012. The event was sold out in less than two weeks and was really satisfying to me and – at least some folks told me – to others, too. I cannot imagine a life without events like that anymore. It has been energizing to see so many great and passionate developers sharing their knowledge and experience and setting a great stage for themselves.

Every End is a New Beginning

Shortly before SoCraTes 2012 I started to think about withdrawing my engagement for the future. The reason is simple: I always wanted the event to be a community event, not my personal thing.

I am really happy to have found volunteers for next year’s SoCraTes and I have no doubt that it will be great again. Nonetheless I am curios about how it will turn out to be.

Last not least I want to thank everybody for his/her support, especially Nicole who invested lots of her time and always took the load off me. It wouldn’t have been possible without her loving support.

The Eve of the SoCraTes Conference

The SoCraTes conference started at 5 o’clock in the evening. I like this, for several reasons: The participants can arrive at their own pace, it does not matter too much if they do not manage to be punctual, and they can get to know each other informally over a beer or two.

As one of the SoCraTes organizers, I asked myself: Should this be all they do at the first evening, or should there be some kind of official programme? If so, what should it be? The standard “sit in a circle and introduce yourself”? With more than 70 people, this would probably be the most long-winding and boring part of the whole conference. — What about Lightning Talks? This can be a huge success, but it very much depends on the people and their qualities as stand-up comedians. Also, I envisioned that the proposed activity should have something to do with the SoCraTes conferece and should give the participants a head-start into what it means to be part of an unconference.

Bob Marshall’s article on Better Conferences made me wonder what SoCraTes is offering its participants. Especially the problem of unconscious incompetence rang a bell with me.
Did the participants know what they wanted to learn and explore? Open Space, the format of SoCraTes, is ideal for asking questions about topics. How can we enable the participants to ask those questions?

So we decided to do an experiment: a World Café about finding out what we want to learn. I gave a quick intro: I told the participants that I believe they are attending SoCraTes because they want to actively build their knowledge, and they want to be in control of what they learn.
I briefly explained how a World Café works, and that it was set up to allow them to think more about this and to find out, together with the others, what it actually is that they do not know now and want to know when SoCraTes is over.

I only asked them to follow two rules:

- Ask yourself “What is it that I really want to learn?” Do not stick with tools or frameworks, address the underlying concepts.
– Just collect the questions, do not try to answer them! The answering can happen in the Open Space.

By looking into the shining eyes of the participants, I knew that there was no need to mention the third rule “Stay on topic”.
The participants rushed into the room and quickly gathered around the eight tables we had set up with paper tablecloths and pens, and soon the room was humming with discussions. After three rounds of vivid exchange, discussing and scribbling on the tablecloths, we closed the World Café, and many participants told me that they now had a better idea on what is missing in their repertoire and what they want to learn at SoCraTes.

If it’s Crap, Call it Crap – not Legacy

Tonight we were discussing code quality issues. During this discussion one thing came up to my mind:

Everybody is calling old code “legacy”, and now legacy is used as a synonym for code of poor quality.

Why that?

My first guess is: If it was me who wrote the code, “legacy” sounds much nicer than saying “this code is crap”. “Crap” sounds harsh, brutal, nasty.

But there’s more to it. Many developers have to deal with existing code on a daily basis. Much code. Code that is running at customers’ sites. This code cannot be all crap. People use it, so it must be somehow valuable to them. We even earn money with selling it to new customers. – But it slowly kills us. It kills our ability to change it to modernize it.

Why bother?

Most of us are aware of the fact that today’s produced code will be tomorrow’s legacy. If we allow the use of the word “legacy” as a synonym for “crap” then we have a perfect excuse for producing crappy code. – We should care more of tomorrow’s legacy. We should be proud of yesterday’s work. Today, tomorrow, next year, in five years!

For example: We live in a legacy house, more than a hundred years old. And we are proud of it. We are proud of the people who have built it. Of course there are necessary refurbishments and modernizations, but performing them is usually possible with quite low effort. – I drive a car that is 20 years old. And I love it. – Both the house and the car are legacy, but not crap.

I have a Russian friend that possessed a 7 year old Lada. It was slightly legacy but complete crap. We once bought a brand new replacement part (a rear axle). It was cheap, but crap from the start. Of course the car was running most of the time, but we often had the feeling that we were lucky to reach our destination.


Let’s imagine a huge class hierarchy. Nowadays we know that in most cases huge hierarchies are not a good idea if you want to write maintainable code. Some years ago this knowledge was not so wide-spread. But the now so big hierarchy started small, believe it or not. So if you start building a hierarchy today you are potentially laying the foundation for tomorrow’s hell. And you should consider yourself a crap-maker, because you should know better than – let’s say – 10 years ago. The knowledge that deep hierarchies are problematic and should be avoided is now a “best practice” and has been around for at least five years. This means that if you are now dealing with a deep hierarchy that is less than five years old, you can frankly call that crap.

If you even think of extending this hierarchy with more depth, that is also crap. No excuses. If a structure you have to deal with already is too complicated, adding more is not a way of producing legacy, it is just a horrible practice and it always has been. As soon as you sense the code you are working on is getting too complex, stop. Refactor or refurbish it. It will never get easier in the future. The more you add, the more difficult it will be.


Think – don’t just code!

Legacy Software – Why I love working with it!

For years I worked as a consultant and coach. Both on agile methods and coding. I guess I was of some help on a few occasions. At least that is what some customers stated. But in the end I always left them alone. I often felt relief when I left them. But on the other hand it was also like surrender. The software was not finished. Most software is never finished; development goes on and on and on and …

This is probably nothing new to you. Maybe you have similar experiences. But probably you belong to the majority of people in software development: employed developers.

Buried Under Tons of Code

Old code. Untested. Unreadable. Unloved.

Is this what you dreamed of when you started your career? – Probably not. You may have dreamt of creating new shiny software from scratch using great technologies and fancy tools.

But you don’t quit your job. Perhaps you are a masochist? – I don’t think so. There are many reasons to face the challenge working in such an awkward place:

  • Responsibility: You feel responsible for the product. Although it is not the “Big Fun”, it is your job to keep the thing alive and even add more features to it.
  • Challenge: You think it is much harder to work in a situation like yours than to do small projects from scratch. You know that every software will become legacy after a certain age or size.
  • Fear: You are afraid of being the one to produce the nightmare from scratch that you are now working on. For you it is easier to say: “I just clean up other people’s mess!”
  • Hope: You are just staying because you have hope that you will be amongst the chosen few to start the next product from scratch.

In my case, it is a mixture of the first two aspects. In addition I have a strong belief that every legacy product can be changed to the better so that further development will be possible for a long period of time. This work is not funny but deeply satisfying. In our current product everyone in the team is trying his best while working on the huge codebase. And you know what: The software and the code become better each day.

We are all learning. We are all improving ourselves. Maybe some of us will become masters in the end. Who knows…

Setters Destroy Objects


… and we are not referring to dogs who are chewing on things …


(this article was originally published in German)

What Makes Setters Dangerous?

A “classical” setter, i.e. a public method that directly sets an object’s field to a value passed in from the outside, undermines an object’s integrity.
The object can no longer take care of its fields and determine autonomously which field has which contents. This can especially destroy implicit object invariants, leaving the object in an inconsistent state.

Setters are often used for the initialization of an object. This bears several risks:

  • It is unclear which setters need to be invoked, and it is easy to leave out the invocation of a required setter.
  • It is unclear whether there is a given order in which several subsequent setter invocations can / should / must happen.
  • The setters can be invoked again in the subsequent code, thus potentially damaging the object’s internal data.

There is a Life Without Setters

Setters are used to initialize an object and/or to change its state. There are better ways to achieve these goals:

Initialize the Object at the Right Time

The initialization of an object should happen at the same time as its creation, in the same step. This way, we are sure that each object is fully functional right from the start. If we use setters, the object creation is already completed, and the “initialization” through the setter happens too late.

Instead of using setters for this initialization, we can use constructors that expect all of the required arguments to properly initialize the object. This way, the object can initialize itself, thus keeping its consistency.

If there are several combinations of arguments which can be used to initialize the object, we can offer several constructors. It is recommended that these constructors invoke each other internally.

Example: A vector in a two-dimensional coordinate system.

public class Vector {

	private final double x;
	private final double y;

	public Vector( double x, double y ){
		this.x = x;
		this.y = y;

	public Vector( int x, int y ){
		this( (double) x, y );

	public Vector( Point2D p ){
		this( p.getX(), p.getY() );

Consistent State Changes

Using setters to change the state of an object can easily lead to inconsistencies. Instead, we can send a suitable message (including all required arguments) to the object. The object can change its state in the desired way without losing its consistency.

Example: Scalar multiplication of a vector

public void multiplyWith( double scalar ){
	x = x * scalar;
	y = y * scalar;

Both fields of the vector are changed through the method invocation. There is no inconsistent state.

(Note: This code only works in combination with the first example when the fields are not declared final.)

Immutable Objects

Alternatively, we can implement an “immutable object” or “value object”. In this case, instead of changing the state of some object, we create a new object that reflects the changed state.
This approach is especially recommended for objects that are part of the internal state of a “surrounding” object, while the surrounding object at the same time allows the outside world to access these internal objects. Here it must be impossible to change the internal state of the surrounding object by directly modifying the internal objects from the outside. Therefore, the immutability of the internal objects is crucial.

Example: Scalar multiplication of a vector yields another vector:

public Vector multiplyWith( double scalar ){
	return new Vector( x * scalar, y * scalar );

The new vector is a modified copy of the initial vector. Of course, it is fully initialized and filled with consistent values.

Respect Your Objects!

If we treat objects with respect and if we allow for their need for autonomy, they will hopefully respond by being robust and fault-tolerant.