About me

I'm a software consultant, coder, architect, tester.

I was a bit reluctant to include the words consultant and architect in this list. For a while I did not want to use these words. Architect can invoke the image of someone giving power-point presentations, leaving all the hard work of producing a working solution from a couple of drawn boxes and arrows to the developers. Consultant can make you think of men in dark suits, justifying large bills by being 'the smartest guys in the room".

Thankfully, I was lucky to work with architects and consultants who are not at all like this.

That being said, here comes the wrap up of my past work-life:

I work in software since a bit more than ten years.

The first couple of years I worked in a small company, learning the solid fundamentals of the programmer's trade.

I then joined ThoughtWorks and went to London. This broadened my horizon, now including the agile world, and the amazing diversity of people and technologies at ThoughtWorks.

I went back to Germany and joined Zuehlke, Frankfurt, where I once again had the pleasure to work with great people

After about three years I left Zuehlke because I did not want to spend the weekdays away from the family. I then joined Agheera. Unfortunately Agheera was not in good shape, and things did not improve much, so I left Agheera after one year.

But not all was bad at Agheera - and I was lucky that three of my colleagues decided to join the Bonner office of ise Oldenburg with me - the very same 'small company' that I had started with in the very beginning. Indeed 'ise' has grown a bit since then, and the four of us have started the Bonner outpost.

You can find out more about my prior work in my CV

The ZEN of building software

Some teams flourish, others falter. Some projects are on time, others are a dead end street. In the aftermath, in case of failure people will be certain its someone else's fault, in case of success they will see themselves as a pivotal contributor (I know that I am unfair, I have worked with people you are not like that, and I try to learn from them). This is not because people were evil or stupid, it is because we all have the desire to have a positive image of ourselves, and environments and motivations can be such that this is not possible without delusion. Of course, projects can fail because of inadequate technical decisions and poor quality of code. But these decisions are made by people, the code does not write itself.

I claim that a team of knowledgeable and motivated people, when being given the opportunity to recognize failures and correct mistakes will deliver, no matter what. They might not deliver the best solution ever, a masterpiece that will be admired by generations to come. But for me, and most teams out there, producing decent solutions in a row is as good as it gets, and even that does not come without concerted effort.

You may find all this trivial, and what's the point of my sermon, anyway?
Well, I would like to put emphasis on a couple of soft objectives that should supplement the often pronounced hard ones:

Humbleness: It takes effort and investment to produce a good application. We are not successful by default, no matter how smart we are. There are people who know things that I do not know and who are better at what I do, and I can learn from their experience.

Honesty: We all have our doubts once in a while, and we should feel free to share them. Acknowledging mistakes is not something to be ashamed of; instead, recognizing mistakes should be valued as an opportunity for improvement.

Ego-free: Every member of the team has the right to contribute and grow with the project. The goal is to be successful as a team; not to collect individual bonuses.

Professionalism: We constantly have to focus and prioritize to balance the expectation of early and incremental delivery with the need of producing quality software. We should be able to to explain the why and how of what we are doing, and acquire the necessary skills for what we do.

Whenever I write 'team', I do not exclusively mean the team of developers, but everyone involved; QA, designers, management, oh and lets not forget the users, they are the ones who eventually pay the bill.

It is important to me that we should actively support those objectives. It is not enough to write them on a piece of paper and stick it on a wall. While I do not have any prescribed methods for achieving these goals, I am convinced that we can improve by giving them the importance that we want them to have.

I do not say that other objectives do not matter. Technical knowledge, the pride we take in what we are doing and the individual's career are of course vital; The reason I do not want to put emphasis on these is that they are often prominent enough already.