Devops Tools

DevOps has many levels of complexity. The cultural shift and the organizational structure are the hardest ones in my opinion.

Another one is simply the wealth of tools in that space. I really like the page that XebiaLabs put together. They formatted it like the periodic table of elements which helps you to select tools for a certain domain, e.g. repository management.


Unfortunately the page is not quite complete, nevertheless, it is a good starting point.


The Problem With Quick and Dirty

The last couple of weeks have been pretty busy. Privately our little daughter is rightfully consuming a lot of time and also we have been in the final phase of planning our big garden project which now will commence in May. For work, I’ve been traveling a fair bit being in the US now the second time in a month and on top of that was in Prague last week. Besides that, we are entering a time of change, which is good, but also intense.

I want to keep my schedule with posting something every Monday 6pm and really today I only will manage it with a cheat. I definitely missed German time 6pm, but I can still make Seattle time 6pm!

Recently on Twitter, I found this quote:

“The problem with quick and dirty is that the dirty remains long after the quick has been forgotten” – Steve C. McConnell

Steve McConnell is the author of Code Complete which you can order on Amazon (affiliate link)

It is a book full of wisdom for programmers and one of those books that I like to have a hard copy of. Its content remains true for a very long time.

Back to the quote: „Quick and Dirty“ is so appealing when you are acting under constant time pressure. Everybody seems to be happy at first. The developer can move on to the next task and the product owner gets the feature, extension, bug fix or what-so-ever quickly.

The problem is that just after delivering the item the next urgent thing is lurking around the corner and the quick win is soon to be forgotten. What remains, however, is the hack. Worst case it will cause a bug in future because of unconsidered use-cases or untested side-effects. Best case it will make your system less maintainable, less performant, less readable, less extensible, … the list could go on.

The collection of hacks that your system is built on over time when you have delivered too often „quick and dirty“ is going to make it harder and harder to maintain and extend the application. It will become more error-prone and you will deliver slower and slower until you eventually will have to go into a painful and resource consuming rewrite of large parts of your application.

Don’t be tempted by quick and dirty. Try to do things right and you will be faster in the long run. Constant investment into the architectural health of your system will pay off.

The MVP approach sucks – sometimes.

Defining an MVP is a great approach to deliver value quickly to your customers and also to get good feedback on functionality very early in the development process so that you can base future decisions on that feedback.

Let’s start with a definition. What is an MVP? Here is the definition from Wikipedia:

A minimum viable product (MVP) is a product with just enough features to satisfy early customers, and to provide feedback for future product development.

And another definition from the book The Lean Startup:

Version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.

To me the two key goals of a Minimum Viable Product are

  • be quick to market
  • get early feedback for future iterations

So why does the title of this blog say that MVPs suck sometimes? It’s when we deploy an MVP into production and then never listen to the feedback and never invest in future iterations.

In that case, the only value we will get out of an MVP is being quick to market. And of course that in itself is a value but you are risking to get unhappy customers because sure enough by delivering an MVP you are setting the expectation that feedback will be evaluated and eventually the piece of functionality will evolve into something fully featured.

Many of you probably know this picture comparing an MVP to a classic iterative approach.


I fully agree with the second row of the picture, but the important piece here is that the product evolves over time from a skateboard (something minimal to get from A to B) to a car (something pretty efficient and comfortable to get from A to B)! If you keep the skateboard for years without improving it you will end up with unhappy and frustrated customers.

Also, …. the agile teams who worked on the MVP will be disappointed that they cannot iterate on the product. It feels like an unfinished job. You might think that this is unimportant detail, but the contrary is true. It directly impacts the motivation and the engagement of the team. More about that topic in my post about what employees really motivates.

Of course, sometimes it is just fine to stop after the MVP is delivered.

  • You might decide that the skateboard is just fine and customers are actually happy with the MVP for long-term… in that case: awesome; job done!
  • You might learn that no customer actually wanted the skateboard and you retire it. Stop selling it. That is also a perfectly legit approach.

Getting feedback from the market and not iterating on it because you are already asking teams to work on the next top priority is what will hunt you down at some point future and has a negative impact on team morale.

So what’s the alternative? I think there are two, but really there is only one. And also…  maybe there are some that did not come to my mind …

  1. Stop defining MVPs, deliver a fully featured product (how again do I know  what fully featured means??!)
  2. Start focusing and embrace the MVP approach.

In my opinion, only #2 is the only long-term sustainable way to go. Everybody involved in the process of delivering software to customers should push for this. It is not easy because there are always so many important things that one could work on, but it will pay off over time because it allows for focus and the customer feels heard.

I’d love to hear your opinion on the topic!

Deutsch oder English als Blog-Sprache?

See for English language below….


Dem wiederkehrenden Besucher wird auffallen, dass manche Artikel in Englisch, andere wiederum auf Deutsch veröffentlicht werden.


Der Hauptgrund ist meine eigene Faulheit die Optimierung meiner eigenen Zeit. Ich schreibe in der Sprache, in der ich am besten über das gegebene Thema schreiben kann. Für Themen die sich auf irgendeine Weise auf meinen Beruf beziehen, fällt es mir leichter auf Englisch zu schreiben, da das die Sprache ich die ich beruflich zu 95% einsetze. Artikel über Hobbies fallen mir leichter auf Deutsch. Darüber hinaus ergibt es auch wenig Sinn über z.B. auf Englisch zu schreiben.

Wird sich das unter Umständen ändern? Vielleicht… „Nothing is as constant as change“. Das aktuelle Ziel ist zunächst einmal jede Woche einen Artikel zu veröffentlichen und ein paar Besucher zu bekommen.

Vielen Dank fürs Lesen!


The returning visitor might have noticed that some articles are published in English and some are published in German.


The main reason is my laziness my attempt to optimize my own time. I always write in the language in which I can express myself the best on a given topic. On topics that are somehow related to my job I’ll always use English as that is the language that I use 95% in my day to day job. Posts about my hobbies are easier for me to write in German. Furthermore it doesn’t make a lot of sense to write an article about in English.

Will this change eventually? Maybe… „Nothing is as constant as change“. The current goal is to publish a post per week and to get actually some visitors.

So thanks for reading this!


What really motivates us

My Development teams at Concur are currently all working on complex, high profile projects. Things are challenging and stressful.

In times like that it is important to remember what really drives motivation of a highly skilled workforce. As probably everybody knows by now: it is not money. Money is important and we need to pay people fairly, but it is not what ultimately motivates them long term. As I said, not a new thought, but in times like these, it is easy to forget.

What really motivates us can be distilled in three words:

  • autonomy: have the autonomy to do solve problems the way you think is best. We hire smart people, why not let them take the decisions they need to take in order to do a good job?
  • mastery: enable your people to become really really good at something.
  • purpose: answer the question why we are doing what we are doing.

Read all about it in „Drive“ by Daniel H. Pink. Or just watch this video:

The right DevOps Structure

Once your company has decided to adopt DevOps, that’s when the hard work actually begins. Typically Development and IT-Operations are separated organizationally. How do you bring the two together? What’s the best approach for your company and how do the different approaches compare to each other?

All those questions are non-trivial to figure out. For me, the work of Matthew Skelton and Manuel Pais really helped me to bring order to the various patterns and anti-patterns that exist.

I highly recommend you take a look at their work:


Focus more – multitask less

The ability to multitask is often looked at as a positive characteristic of an employee or of a team. I’m often impressed myself with people who are able to keep several balls up in the air. However, what everyone should keep in mind when asking anyone to multitask is the cost that is associated with it.

The cost of Multitasking

In „Quality Software Management: System Thinking“ Gerald Weinberg suggests a rule of thumb to calculate the cost of context switching when working on several projects at the same time. When a team is working only on one project they can dedicate 100% of their time on that one project. According to Weinberg, once you add one project 20% of the team’s time is wasted with context switching. When adding a third project only 60% of the time is used on projects. By adding a 4th and 5th project you are wasting more time than you are focusing on actual projects. Jeff Atwood wrote an article in 2006 referencing several studies about the problem: The Multitasking Myth

Dead Time

From the above one can easily think that focusing on one project is something that everyone should aspire to. Personally, I don’t think that is realistic or even pragmatic. First, the requirements for your business will almost never comfort you with the luxury of only focusing on one thing. Secondly, there is such thing as dead time in projects. So periods of time in which you are waiting on something in order to progress with your project. No matter how hard you try to align everything in order to avoid dead time, you will have some.

Knowing there will be dead time you can use this to your advantage by pipelining a certain amount of projects. If project A is blocked people can progress on project B, etc. The cost of context switching is still there, but it is mitigated by the ability to work on something highly prioritized during dead time of another project.

Don’t plan with 100% of your team’s time

Another false belief is when running only one project 100% of a team’s time will actually be used for working on this project. I’m doing that mistake myself a couple of paragraphs up in this post. You will not be able to spend 100% of your time on a project hence it is wrong to assume it. There are a couple of reasons for this.

One reason is, everyone will do something unrelated to work throughout their day. Several studies have been conducted and on average it seems that out of an 8 hour work day only 7 hours are effectively used for work.

Also, urgent things will interrupt the day. Especially if the development team is also responsible maintaining an application in production systems. How much of a team’s time goes into solving production issues highly depends on the quality of your software. In any case, things will happen and you need to be aware of that when thinking about how much time can actually be spent on a project.

Thirdly, teams will spend time in meetings, will receive training, will have to monitor production services, etc. Again, how much time goes into that is probably individual for each team, but it needs to be accounted for when thinking of how much time can be dedicated to a project.

So what does that all lead us to?

Just being aware of all the above already helps. Teams and organizations need to find the right balance between multitasking and focus. Finding that balance requires work from everybody involved in the process including the leadership team. Also embracing agile methodologies will help prevent over-committing and account for the fact that your team is able to spend all their time on a specific project.

What are your thoughts on this topic?