Scream-Driven-Development
Find the English version below
Hi ,
Das kennst du bestimmt. Du willst einen Breaking-Change in deinem System machen. Vielleicht willst du eine API ändern. Oder du möchtest deine Environments umstellen. Oder du willst einen Service abschalten, weil er nicht mehr benötigt wird.
Immer wenn ich vor so einer Entscheidung stehe frage ich mich welche Konsequenzen sie haben wird. Wird sie andere Stakeholder beeinflussen? Meistens lautet die Antwort, ja.
So auch im aktuellen Fall. Ich möchte häufiger Deployments in einem Environment durchführen. Sie wird genutzt, um den vorstehenden Release zu testen. Und, um den Feedbackloop kurz zu halten, möchte ich immer den aktuellen Entwicklungsstand auf der Plattform haben.
Als ich den Vorschlag gemacht habe gab es große Bedenken im Team. Wird die QA Abteilung in ihren Prozessen gestört? Was ist wenn die Plattform dann mal Stundenlang down ist, weil etwas™️ nicht funktioniert?
Es spricht die Angst
Lieber mit der aktuellen Situation weiterleben - schließlich haben wir das schon immer so gemacht.
Aber in Wahrheit: Mit dieser Einstellung machen wir keine Fortschritte.
Also ging ich weiter und schlug vor es einfach mal zu machen. Wir können ja mit nächtlichen Deployments starten. Dann wird innerhalb eines Tages zumindest niemand unterbrochen.
Doch auch das war noch nicht genug. Was ist wenn wir etwas übersehen haben? Was ist, wenn noch jemand anderes davon beeinflusst wird? Und wir wissen es jetzt einfach nicht?
Und die QA war natürlich not amused. “Was, wenn wir deswegen nicht arbeiten können?”
Diese Diskussionen kannst du nicht gewinnen. Es ist ein Totschlagargument. Getrieben von der Angst. Von der Ungewissheit. Lieber keine Entscheidung, als eine Falsche.
Ich betreibe in so einem Fall Scream-Driven-Development
Irgendwann wird es Zeit, einfach mal zu machen. Bis einer schreit.
Natürlich solltest du nicht mit Absicht andere behindern.
Natürlich solltest du nach bestem Wissen und Gewissen alle Interessen zusammenbringen.
Aber am Ende wird es immer eine Ungewissheit geben. Unsere Arbeit ist zu komplex, als das du alles, zu jeder Zeit, überblicken könntest.
Du musst irgendwann Fakten schaffen. Und am besten machst du das ohne vorher Stunden und Wochen in Meetings zu verschwenden, in denen sich die Beteiligten in einer Spirale der Angst und Befürchtungen immer weiter von der Entscheidung drücken.
Einfach mal machen
Du wirst überrascht sein, wie selten tatsächlich der Aufschrei kommt.
In den meisten Fällen merken alle sehr schnell, dass das Richtige getan wurde.
Sei mutig - aber nicht übermütig.
ps. Ich bin gerade auf dem Weg nach Berlin. Zur RabbitMQ Summit, um die Keynote “The Performance Mindset” zu halten. Es wird eine Aufzeichnung geben - und sobald sie verfügbar ist wirst du mit Sicherheit davon erfahren 😉
Rule the Backend,
~ Marcus
English
Hi ,
You probably know this feeling. You want to make a Breaking-Change in your system. Maybe you want to change an API. Or you'd like to switch up your environments. Or you want to shut down a service because it's no longer needed.
Whenever I face such a decision, I wonder about its consequences. Will it affect other stakeholders? The answer is often, yes.
This is the case now. I want to conduct deployments more frequently in an environment. It's used to test the upcoming release. And, to keep the feedback loop short, I always want the current development status on the platform.
When I made the suggestion, there were major concerns in the team. Will it disrupt the QA department's processes? What if the platform goes down for hours because something™️ doesn't work?
It's fear speaking
Better to stick with the current situation - after all, that's how we've always done it.
But the truth is: With this attitude, we don't make progress.
So, I pressed on and suggested to just go for it. We could start with nightly deployments. That way, at least no one gets interrupted during the day.
But even that wasn't enough. What if we overlooked something? What if someone else is affected? And we just don't know it yet?
And the QA, of course, was not amused. "What if we can't work because of this?"
You can't win these discussions. It's a killer argument. Driven by fear. By uncertainty. Better no decision than a wrong one.
In such cases, I practice Scream-Driven-Development
There comes a time when you just have to go for it. Until someone screams.
Of course, you shouldn't intentionally hinder others.
Of course, you should bring all interests together to the best of your knowledge and belief.
But in the end, there will always be uncertainty. Our work is too complex for you to have an overview of everything, all the time.
You have to establish facts at some point. And it's best to do that without wasting hours and weeks in meetings where participants keep pushing away from the decision in a spiral of fear and apprehensions.
Just do it
You'll be surprised how rarely there's an actual outcry.
In most cases, everyone quickly realizes that the right thing was done.
Be brave - but not reckless.
ps. I'm on my way to Berlin right now. For the RabbitMQ Summit, to give the keynote "The Performance Mindset". There will be a recording - and as soon as it's available, you'll definitely hear about it 😉.
Rule the Backend,
~ Marcus