17 Punkte von GN⁺ 2024-08-12 | 11 Kommentare | Auf WhatsApp teilen
  • Auf der Black Hat-Konferenz argumentierte Signal-Gründer Moxie Marlinspike, dass durch agile Entwicklung in den vergangenen 20 Jahren Software-Innovationen verschwunden seien
  • Er wies darauf hin, dass Entwickler in „Black-Box-Abstraktionsebenen“ gefangen seien und die für Innovation nötige Freiheit verloren hätten
  • „Jeder, der eine Engineering-Organisation leitet, hat wahrscheinlich eine Managementphilosophie, die ein Unterkonzept von Agile ist, davon abgeleitet wurde, in den Bereich von Agile fällt oder auf irgendeine Weise damit zusammenhängt“
    • Statt dass Entwickler sich Bottom-up bewegen und Engineering-Fachwissen mit der Vision verbinden, neue Möglichkeiten bestehender Technologien zu erkennen,
      würden Agile-Teams seiner Ansicht nach in einzelne Silos aufgeteilt, getrennt voneinander arbeiten und keinen Überblick darüber haben, was andere Teams tun
  • In der Abschlusssession ergänzte auch Window Snyder, Gründerin und CEO von Thistle Technologies, dass solche Black-Box-Teams zudem dazu neigten, nur wenig Einblick in die Funktionsweise ihrer eigenen Produkte zu haben
    • Snyder argumentierte außerdem, dass Studierende, die Programmieren lernen, nicht den Umgang mit Low-Level-Sprachen oder Maschinencode lernen, sondern nur High-Level-Sprachen, die die App-Entwicklung vereinfachen, weshalb Ingenieuren der nötige Kontext fehle, um zu verstehen, wie die Teile eines Puzzles in das größere Ganze passen

Sicherheitsforscher halten den Schlüssel zur Innovation in der Hand

  • Marlinspike sagte außerdem, dass Software Engineering in den vergangenen Jahrzehnten abstrahiert worden sei, um schneller, flexibler und weiter voranzukommen, während Sicherheitsforscher versucht hätten, über die Abstraktion hinauszuschauen
    • „Sicherheit ist der Prozess, etwas Abstraktes zu durchleuchten und zu verstehen, wie es tatsächlich funktioniert, was darunter liegt, und es manchmal sogar besser zu verstehen als die Person, die es ursprünglich geschaffen hat“
  • Daher, so seine These, halten Sicherheitsforscher den Schlüssel in der Hand, um neue Innovationen anzustoßen
  • Er zog auch den Vergleich, dass Software zu verstehen sei wie Magie zu verstehen, und Sicherheitsfachleute „die Menschen sind, die in der Bibliothek sitzen und Magie studieren“

Meinung von GN⁺

  • Es waren pointierte und aufschlussreiche Aussagen von Marlinspike, die die grundlegenden Probleme von Agile scharf benennen
  • Ich kann dem zustimmen, dass Entwickler durch die Fixierung auf Abstraktion und hohe Entwicklungsgeschwindigkeit zunehmend den Bezug zu grundlegenden Konzepten verlieren
  • Bemerkenswert war auch der Fokus auf die Rolle von Sicherheitsforschern. Da Sicherheit die Arbeit ist, die hinter Abstraktionen verborgene Realität freizulegen, kann sie ein Motor für Innovation sein
  • In gewisser Weise vermittelt dies die Botschaft, dass Software Engineers nach einem tieferen Verständnis streben sollten
  • Die Vorteile von Agile sind jedoch ebenfalls klar vorhanden, daher dürfte ein ausgewogener Ansatz nötig sein. Es gilt, Wege zu finden, Agilität und Flexibilität von Agile zu bewahren und zugleich die Grundlagen zu stärken
  • Dafür sind Verbesserungen bereits in der Entwicklerausbildung nötig. Neben High-Level-Sprachen sollte auch die Ausbildung in Low-Level-Sprachen, Computerarchitektur und anderen Grundlagenfächern verstärkt werden

11 Kommentare

 
jeokrang 2024-08-20

Es scheint, als würde man das Problem von Managern, die Agile falsch verstanden haben, mit einem Problem von Agile selbst verwechseln.

 
yangeok 2024-08-20

Mit dem Lauf der Zeit scheint es so zu sein, dass man, weil es sich ROI-mäßig nicht lohnt, Low-Level-Wissen zu lernen, nur noch beim Erlernen von High-Level-Wissen bleibt.

 
andrewchaa 2024-08-14

Warum ausgerechnet auf Agile herumgehackt wird ...

 
lordang 2024-08-12

Ich finde den Inhalt etwas verwirrend, weil hier die Konzepte von north-south und east-west durcheinandergebracht werden.
Dass man nicht weiß, was andere Teams machen, scheint mir eher ein Problem der cross-funktionalen Organisationsstruktur zu sein als von Agile selbst.

Dass man sich mit low level nicht gut auskennt: Wenn man sich den Inhalt ansieht, wird da eher so etwas gesagt wie „dann neigt man auch dazu, low level nicht gut zu kennen“.

Selbst wenn man gelten lässt, dass das Nichtwissen darüber, was andere Teams machen, zumindest ein wenig mit Agile zusammenhängt, kann ich wirklich nicht nachvollziehen, was mangelndes Wissen über low level mit Agile zu tun haben soll, hahaha

 
lordang 2024-08-12

Wenn man es genau nimmt, liegt es vielleicht eher daran, dass sich Open Source so weit verbreitet hat und man deshalb nicht mehr alles selbst bauen muss, also das Rad nicht neu erfindet, und im Low-Level-Bereich einfach alles übernimmt und nutzt, sodass man es gar nicht erst lernt.

Wenn man diese Aussage unbedingt verstehen will, könnte man sie so deuten, dass man wegen Agile nur noch schnell etwas baut und deshalb nichts über Low Level lernt, aber ist es nicht eher so, dass man es nicht lernt, weil es schlicht nicht nötig ist?

 
bbulbum 2024-08-12

Ich denke, dass durch Agile Entscheidungen vernachlässigt werden, die Probleme aus einer breiteren Perspektive betrachten und langfristig nachhaltig machen, und dass man sich dadurch auch aus Sicht der Software immer stärker nur darauf konzentriert, die unmittelbaren Probleme vor Augen zu lösen.
Blind einfach erst einmal etwas zum Laufen zu bringen, ist zwar nicht das, was agil ausmacht, aber es scheint eine Tendenz zu geben, sehr stark auf Geschwindigkeit fokussierte Entscheidungen zu treffen, und ich denke, dass dies ein Faktor sein kann, der es erschwert, nach tiefem Verständnis zu streben.

 
savvykang 2024-08-12

Ich verstehe nicht, warum man die Ursache des Problems, dass Engineering-Organisationen keine Entscheidungsbefugnis haben, bei Agile suchen will.

 
galadbran 2024-08-12

Was es mit Agile zu tun hat, dass man nicht weiß, was andere Teams machen, ist mir unklar ... ;;;

Allerdings ist der Name Window Snyder ziemlich ungewöhnlich ...

 
xguru 2024-08-12

Ich würde mir gern das Originalvideo ansehen, aber es ist noch nicht verfügbar. Ich denke, es wird wohl in einiger Zeit auf dem offiziellen YouTube-Kanal hochgeladen. https://www.youtube.com/@BlackHatOfficialYT/

 
GN⁺ 2024-08-12
Hacker-News-Kommentare
  • Die Wurzel des Problems ist die moderne Unternehmensstruktur

    • Es gibt die moderne Managementtheorie, nach der Verantwortung und Entscheidungsfindung entlang der Unternehmenshierarchie nach oben eskalieren müssen
    • Es wird angenommen, dass Mitarbeiter auf unteren Ebenen am wenigsten über das Produkt wissen
    • In Wirklichkeit haben jedoch die Mitarbeiter an der Front die meisten Informationen
    • Wenn Software Engineering zu einem Fließbandprozess gemacht wird, kommt Innovation zum Stillstand
    • Eine egalitäre Managementhierarchie ist nicht unbedingt die Antwort, aber es braucht Wege, die Mitarbeiter an der Front nicht zu entmündigen
    • Das Buch <i>Reinventing Organisations</i> beschreibt innovative Unternehmensstrukturen
  • Die guten Ideen von Agile wurden in allgemeines Software Engineering aufgenommen

    • Agile-Programmierer gelten als Leute, die strikte Stand-up-Meetings, Kanban-Boards usw. befolgen
    • Ich glaube nicht, dass Agile die Fragmentierung von Wissen und den Qualitätsverlust im Software Engineering verursacht hat
    • Das Problem ist durch den Trend zur Massenproduktion entstanden
    • Ähnliche Phänomene sieht man auch bei Autoherstellern oder in Möbelfabriken
  • Unzufriedenheit mit Agile, Scrum und OKR

    • Alle versprechen, Freiheit und Verantwortung an Mitarbeiter auf unteren Ebenen weiterzugeben, in der Praxis führt es jedoch zu Zentralisierung
    • Ich würde OKR gern einmal umgekehrt anwenden
    • Alle Mitarbeiter sollten in ihrem Bereich selbst die Key Results definieren, und Manager sollten darauf basierend die Richtung des Teams festlegen
    • Es braucht einen Bottom-up-Ansatz statt eines Top-down-Ansatzes
    • Man muss gut einstellen, gut ausbilden und den Mitarbeitern vertrauen
  • Erfahrung in einem Backlog-Refinement-Meeting

    • Ich musste einen Bugfix in mir unbekanntem Code schätzen
    • Weil die Schätzung schwierig war, habe ich einfach irgendeine Zahl genannt
    • Agile wurde an drei Orten auf ähnliche Weise betrieben
  • Eine Theorie zu den Problemen von Agile

    • Es ist nützlich, Arbeit in kleine Teile zu zerlegen, aber Programmierung erfordert Kreativität
    • Beim Aufteilen der Arbeit gehen viele Informationen verloren
    • Entwickler müssen kreative Lösungen finden, bekommen aber nicht die nötigen Informationen
    • Es braucht erfahrene Entwickler oder bessere Architekturdiagramme und Dokumentation
  • Sinkende Softwarequalität

    • In den letzten Jahrzehnten ist Software schlechter geworden
    • Wir nutzen leistungsfähigere Maschinen, aber die Reaktionsfähigkeit hat abgenommen
    • Das könnte mit dem Aufstieg von Agile zusammenhängen
  • Ingenieure sollten Teile des Codes „besitzen“

    • Das war die Zeit, in der die Software des Teams am besten war
  • Erfahrung damit, tägliche Stand-up-Meetings zu vermeiden

    • Ständige Retrospektiven und Arbeitszerlegung waren ineffizient
    • Nützlich war das nur für nichttechnische Manager
  • Probleme großer Organisationen

    • Entwickler geben nicht mehr die Richtung vor
    • Vision, Produkt, UX und Projektmanagement werden von oben entschieden
    • Entwickler arbeiten mit Cloud-Technologien an ihren Aufgaben
    • Sie können das Gesamtbild nicht verstehen oder wichtige Vorschläge machen
  • Die Meinung, dass man die „Magie“ der Softwareentwicklung zurückholen muss

    • Man merkt, dass die Person seit über 20 Jahren in der Branche ist
    • Wenn man Zeit mit jungen Programmierern verbringt, ist die Magie immer noch da
    • Auch vor 20 Jahren gab es ähnliche Beschwerden, aber die Arbeit hat trotzdem Spaß gemacht
 
savvykang 2024-08-13

> Es gibt eine moderne Managementtheorie, nach der Verantwortung und Entscheidungsfindung entlang der Unternehmenshierarchie nach oben eskalieren müssen.

Ist das nicht eher ein Merkmal bürokratisierter Organisationen?