[DDD] Products are made of people

[Reading time: 1 minutes 36 seconds]

Some friends of mine who are doing research similar to mine have independently come to quite similar results: most teams struggle with testing.

Be that in nascent fields such as serverless, or old, traditional fields like embedded systems.

And I’ve spotted something like that in my DevOps research as well: assuring good software quality it hard.

Why is that?

Well, part of it is: if you make software quality about testing, you’re doing too little too late.

The more I listen the less I know

[Reading time: 0 minutes 16 seconds]

Now that I listened to DevOps practitioners I know even less about DevOps

This is a quote from one of the generous people who agreed to an interview for my DevOps research.

This may sound disheartening, yet it’s hardly surprising.

DevOps is such a wide field, and it’s so ill-defined.

It’s not as much problem as it is a warning though: you can’t just look at what others are doing, copy it, and expect great results.

DevOps is about footwork

I’ve been an avid rock climber since before it became cool (disclaimer: the dude in the picture isn’t me. I’m not that cool.)

One thing I deeply enjoy about the climbing community is how welcoming they are of beginners.

Anyone who’s struggling to make it up a route, regardless of its (perceived) difficulty, will be offered encouragement and helpful advice.

Interestingly, newbies struggling to master a particular climb tend to think that they lack the strength to make it to the top. “I’m not strong enough!” is the number one complaint.

DevOps: Jetzt mal ehrlich (Teil 1)

DevOps: jetzt mal ehrlich

Was ist DevOps? Keiner weiß es. Aber jeder weiß es besser :-)

In der Tat rede ich mittlerweile von Rorschach’s DevOps: ich sage “DevOps”, und Du verstehst darunter, was Du willst.

Um so interessanter ist es, herauszufinden, was andere auf diese Fläche projizieren.

Durch meine Arbeit als DevOps Trainer und Coach habe ich viele Eindrücke und Bauchgefühl dazu gewonnen – aber das geht bestimmt auch noch besser.

The Smell of Frustration

[Reading time: 1 minutes 46 seconds]

Maybe you’ve heard of the term code smell. It was coined by Kent Beck.

A code smell is “any characteristic in the source code of a program that possibly indicates a deeper problem. Determining what is and is not a code smell is subjective, and varies by language, developer, and development methodology.” . Or so says Wikipedia.

Now, there are not just code smells. There are also other kind of smells: organisational, or cultural, or whatever else.

Mastery vs Purpose

[Reading time: 1 minutes 47 seconds]

Maybe you’ve read Daniel Pink’s Drive.

In this book, Pink argues that there are three factors to increase performance and satisfaction:

• Autonomy — The desire to be self directed
• Mastery — The urge to get better skills
• Purpose — The desire to do something that has meaning and is important

This is taken to apply to the feelings of a person, the foundations of their motivation.