The Paradox of Freedom
Find the English version below
Hi ,
The Paradox of Freedom: The more options we have, the more anxious we become that we chose the wrong thing.
~ Mark Manson
Mark Manson ist kein Softwareentwickler. Er ist Autor. Sein Bestseller: "THE SUBTLE ART OF NOT GIVING A F*CK"
Er gibt Selbsthilfe für Menschen, die Selbsthilfe Bücher hassen. In dem Paradoxon bezieht er sich auf Lebensentscheidungen. Beispielsweise fällt es vielen Menschen schwer eine Liebesbeziehung über Tinder einzugehen. Die Optionen sind so groß, dass man sich bei jedem Date denkt, man könnte noch was besseres haben.
Dieses Paradoxon findet sich auch in der Softwareentwicklung wieder
Das fiel mir neulich auf als ich versuchte die Authentifizierung in einer Applikation zu verstehen. Dabei war ich nur an der Maschinenauthentifizierung identifiziert.
Wie wird sichergestellt, dass Service 1 mit Service 2 sprechen darf?
Als ich in das Repository schaute sah ich Code. Sehr. Viel. Code.
Das Problem ist *eigentlich* simpel. Ich hatte nur eine einfache BasicAuth
mit hard-verdrahteten Secrets erwartet. Aber was ich vorfand war eine Implementierung mit sehr vielen Optionen. Es sollte die gleiche Implementierung für jegliche Authentifizierung genutzt werden. Egal ob Maschine, Kunde, API-Nutzer oder Entwickler. Alle Bedürfnisse sollten mit der gleichen Implementierung abgedeckt werden.
Solche Lösungen haben ihren Preis. Es ist schwer zu verstehen. Klappen eigentlich alle Kombinationen an Features? Ich weiß es gar nicht. Es gibt vielleicht Tests. Wahrscheinlich jedoch nicht.
Zu viele Optionen in unserer Implementierung schränken die Freiheit ein.
Mein Ziel - nach dem Verstehen - war es die Credentials zu rotieren. Doch ich konnte es nicht. Es war viel zu komplex.
Ein anderes Beispiel: Die Auswahl in der CD Pipeline
Noch heute schaute ich in einem Projekt auf die CD Pipeline. Auch hier, eigentlich eine einfache Aufgabe. Es soll eine bestimmte Version auf ein bestimmtes System deployed werden.
Intuitiv erwarte ich also zwei Auswahlmöglichkeiten. Was soll wohin deployed werden. Die Pipeline bietet jedoch acht Optionen. Will ich wirklich deployen? Soll noch die folgende Subpipeline angeworfen werden? Soll nur ein Dry-Run ausgeführt werden? Möchte ich ein extra manuelles approval vor dem Deployment?
Es sind viele Fragen. Und jedes Mal, wenn ich sie laufen lassen will, dann kostet es mich mentale Kapazität. Ich komme nicht drumherum alles zu lesen und darüber nachzudenken.
Es sind zu viele Möglichkeiten. Ich habe nicht mehr Freiheit. Ich habe weniger.
Und was wenn dann ein Fehler aufgrund meiner Auswahl passiert?
Ich würde mich schrecklich fühlen. Schließlich hätte ich anders entscheiden können. Wenn aber alle Optionen für mich bereits getroffen sind und dann ein Fehler passiert, dann bin ich konstruktiver. Es war dann schließlich ein Bug des Systems. Nicht des Nutzers.
Vielleicht denkst du auch gerade an ein System, dass zu viele Optionen bietet. Wie wäre es sie wieder zu kürzen? Du wirst dich frei fühlen.
Dies ist die letzte Ausgabe des Newsletter für 2023. Nächstes Jahr geht es hier weiter und ich freue mich schon darauf :-). , komm gut ins neue Jahr und vielen Dank für deine Treue!
Rule the Backend,
~ Marcus
Hi ,
The Paradox of Freedom: The more options we have, the more anxious we become that we chose the wrong thing.
~ Mark Manson
Mark Manson is not a software developer. He is an author. His bestseller: "THE SUBTLE ART OF NOT GIVING A F*CK"
He provides self-help for people who hate self-help books. In this paradox, he refers to life decisions. For example, many people find it hard to enter into a love relationship via Tinder. The options are so vast that with each date, you think you might have something better.
This paradox is also found in software development
I noticed this recently when I tried to understand authentication in an application. I was only identified by machine authentication.
How is it ensured that Service 1 is allowed to talk to Service 2?
When I looked into the repository, I saw code. A lot. Of. Code.
The problem is actually simple. I just expected a simple BasicAuth
with hard-wired secrets. But what I found was an implementation with many options. It was supposed to be the same implementation for any authentication. Whether it's machine, customer, API user, or developer. All needs were to be met with the same implementation.
Such solutions have their price. They are hard to understand. Do all combinations of features actually work? I don't even know. There might be tests. Probably not.
Too many options in our implementation limit freedom.
My goal - after understanding - was to rotate the credentials. But I couldn't. It was too complex.
Another example: The choice in the CD Pipeline
Just today, I looked at the CD Pipeline in a project. Here too, actually a simple task. A specific version is to be deployed to a specific system.
Intuitively, I would expect two choices. What should be deployed where. However, the pipeline offers eight options. Do I really want to deploy? Should the following sub-pipeline be triggered? Should only a Dry-Run be performed? Do I want an extra manual approval before deployment?
There are many questions. And every time I want to run it, it costs me mental capacity. I can't help but read everything and think about it.
There are too many possibilities. I don't have more freedom. I have less.
And what if an error occurs because of my choice?
I would feel terrible. After all, I could have decided differently. But if all the options are already made for me and then an error occurs, then I am more constructive. It was then a bug of the system. Not of the user.
Perhaps you're also thinking of a system that offers too many options. How about cutting them down? You will feel free.
This is the last issue of the newsletter for 2023. Next year it continues here and I am already looking forward to it :-). , have a good new year and thank you for your loyalty!
Rule the Backend,
~ Marcus