Mir hat dieser Artikel über das Denken zweiter Ordnung sehr gut gefallen.

Er erklärt am Beispiel von 'Chestertons-Fence', warum es wichtig ist, vor Änderungen an Systemen das Denken zweiter Ordnung einzusetzen. Er nutzt dazu die Methapher eines Zauns über eine Straße. Diesen sollte man nicht einfach wegräumen, nur weil er nervt. Warum? Weil die Menschen die ihn gebaut haben hatten damit Aufwand, den Sie nicht einfach nur so zum Spaß investiert haben. Deren Gründe muss man verstehen um zu sehen ob der Zaun tatsächich weg kann, oder nach wie vor nötig ist.

Angenommen hinter dem Zaun befindet sich ein Straßenabschnitt, der mit Minen verseucht ist. Leider ist dies in der Ukraine ja ein häufiges Problem. Der Zaun sollte erst entfernt werden, wenn die Minen geräumt sind, um Todesfälle und Verletzungen zu vermeiden. Die Toten und Verletzten sind hier der Effekt zweiter Ordnung.

Denken zweiter Ordnung heißt also nicht nur zu hinterfragen, warum etwas so ist, wie es ist, sondern auch zu verstehen, warum die Menschen, die es geschaffen haben (in unserem Fall meistens Code), es auf diese Weise gebaut haben. Bevor ich Änderungen vornehme, sollte ich mir Zeit nehmen, um die Gründe für die ursprüngliche Gestaltung zu verstehen, da unbedachte Änderungen unerwünschte Effekte haben werden.

So zu denken finde ich nicht leicht. Oft misslingt es mir. Aber es ist für mich ein Ziel.

Was heißt das für uns Entwickler?

Besonders bei der Frage: Wieso sind unsere Systeme so wie sie sind? Ist das für mich super relevant. Aber auch immer wenn ich Programmiere. Wenn ich einen Zaun aufstelle, also z.B. etwas komplizierter mache als es sein könnte, dann schreibe ich einen Kommentar wieso ich mich gegen die einfachere Lösung entschieden habe, damit die nach mir kommenden verstehen ob meine - für Sie - überkomplizierte Lösung noch nötig ist. Wenn ich eine weiter reichende Entscheidung fälle, dann Dokumentiere ich diese gerne mit eineme Architektural Decision Record (ADR) der enthällt aus welchen Gründen wir uns so entschieden haben. Wenn ich eine Story schreibe, dann muss da nicht nur das Feature drauf, sondern eben auch der Grund dafür, damit ich oder andere später nachvollzieen können, wieso dieses Feature existiert, oder eben wieso es nicht mehr nötig ist. Idealerweise würde ich auch gerne vom Code über die Commits zur Story zurück kommen - aber das gelingt mir bisher regelmäßig nicht.

Fazit

Viele der Praktiken, die wir in der Softwareentwicklung als Standards ansehen, dienen eigentlich dazu, das Denken zweiter Ordnung zu erleichtern – ein wichtiger Zusammenhang, der oft unerwähnt bleibt, mir aber zunehmend klarer wird.

Ganz besonders wichtig ist mir aber der Respekt, im Zweifel sollte ich erst einmal annehmen das der andere sich etwas dabei gedacht hat. Bevor ich das nicht verstehe sollte ich nicht die Axt ansetzen.

Zu meinen Ikea Trådfri Leuchten habe ich mir jetzt einen Phillips Hue LED-Streifen dazu geholt. Letztlich aus drei Gründen:

• Weil die viel Heller sind als fast alle Konkurrenzprodukte
• Weil sie auch ZigBee verwendet und damit nahtlos in meine Ikea Trådfri infrastruktur passt (theoretisch…)
• Weil ich mir die Ikea Bridge sehr bewusst ausgesucht habe, weil sie eben ohne einen Cloud zwang daher kommt.
• Weil ich sie in einem Sonderangebot 3 Meter für 50 € bekommen habe.

Well, also der Klebestreifen auf der LED-Schlange verdient diesen Namen schon mal nicht. Nicht nur das man den in 10 cm Inkrementen abpulen musste, er klebt zwar prima an der Tapete - aber nicht am LED-Streifen. WTF?

Davon abgesehen ist er super hell und lässt sich über Tradfri gut anbinden und steuern. ABER: Tradfri pusht ihn NICHT nach HomeKit wie es das mit den anderne Ikea eigenen Produkten macht. 😣💩😣💩😣🤬

Software Updates spielt die Tradfri Basis auch nicht ein - aber ok, das kriege ich via Bluetooth hin, was der LED-Streifen auch noch kann.

Jetzt extra noch eine Hue Bridge zu kaufen, nur damit ich dieses eine Gerät auch in HomeKit schalten kann, sehe ich jedenfalls mal gar nicht ein. Also hab ich mein trusty schweizer Messer Python ausgepackt und mit etwas Code nachgeholfen das fehlenden Device von Trådfri nach HomeKit zu pushen. Et Voila. :-)

Fazit: Die Schaltzeiten leiden etwas, Kann durchaus auch mal eine Sekunde dauern, anstatt der fast instantanen schaltzeit der Lampen die direkt über die Tradfri Bridge gehen. Aber wurscht, keine extra Bridge, etwas Spaß mit Python und die Erfahrung das es leicht geht da beliebigen eigenen Code einzubinden, der z.B. schöne Hintergrund-Farbwechsel ambient Lights produziert.

Beim lesen dieses Interview mit Elon Musk (hier auch als Video) hatte ich wirklich Spaß.

Diese Dinge sind nichts neues - aber mir ist klar geworden dass ich in der Vergangenheit viel zu Wenig wert darauf gelegt habe Requirements als Dumm zu identifizieren und Los zu werden, sowie Prozesse zu löschen. Autsch. Mea Culpa - ich gelobe Besserung.

Hier vor allem für mich selbst archiviert:

Musk’s Engineering Philosophy:

Musk overviewed his five step engineering process, which must be completed in order:

1. Make the requirements less dumb. The requirements are definitely dumb; it does not matter who gave them to you. He notes that it’s particularly dangerous if someone who is smart gives them the requirements, as one may not question the requirements enough. “Everyone’s wrong. No matter who you are, everyone is wrong some of the time.” He further notes that “all designs are wrong, it’s just a matter of how wrong.”
2. Try very hard to delete the part or process. If parts are not being added back into the design at least 10% of the time, not enough parts are being deleted. Musk noted that the bias tends to be very strongly toward “let’s add this part or process step in case we need it.” Additionally, each required part and process must come from a name, not a department, as a department cannot be asked why a requirement exists, but a person can.
3. Simplify and optimize the design. This is step three as the most common error of a smart engineer is to optimize something that should not exist.
4. Accelerate cycle time. Musk states “you’re moving too slowly, go faster! But don’t go faster until you’ve worked on the other three things first.”
5. Automate. An important part of this is to remove in-process testing after the problems have been diagnosed; if a product is reaching the end of a production line with a high acceptance rate, there is no need for in-process testing. Additionally, Musk restated that he believes everyone should be a chief engineer. Engineers need to understand the system at a high level to understand when they are making a bad optimization. As an example, Musk noted that an order of magnitude more time has been spent reducing engine mass than reducing residual propellant, despite both being equally as important.