Technical Debt Records – Dokumentation technischer Schulden

Um technische Schulden systematisch zu dokumentieren und zu verwalten, eignen sich Technical Debt Records (TDRs).

Zur Abwechslung geht es diesmal weder um Microcontroller noch um KI, sondern um Softwarearchitektur, genauer gesagt um technische Schulden und ihre Dokumentation. In der heutigen schnelllebigen Softwareentwicklung stehen Teams vor der Herausforderung, kontinuierlich neue Funktionen bereitzustellen und gleichzeitig die Codequalität zu erhalten. Dabei entstehen oft Kompromisse, die wir als Technical Debt (Technische Schulden) bezeichnen. Um diese systematisch zu dokumentieren und zu verwalten, lassen sich Technical Debt Records (TDRs) nutzen. Dieser Artikel erläutert die Bedeutung von TDRs und stellt ein Werkzeug vor, das die Erstellung von TDRs vereinfacht.

Was sind Technical Debt Records (TDRs)?

Softwarearchitektinnen und -architekten nutzen heutzutage ADRs (Architecture Design Records), wenn sie Architekturentscheidungen festhalten wollen. ADRs haben sich in einer Vielzahl von Projekten als Micro-Architekturdokumente etabliert. Sie unterliegen der Versionskontrolle und liegen damit in der Codebasis. Was für Architekturentscheidungen gilt, lässt sich auch für technische Schulden nutzen.

Ein Technical Debt Record (TDR) ist ein strukturiertes Dokument, das Details über technische Schulden in einem Softwareprojekt festhält. Technische Schulden entstehen, wenn Entwicklerinnen und Entwickler kurzfristige Lösungen wählen, die sich zwar schnell implementieren lassen, aber langfristig zu erhöhtem Wartungsaufwand, schlechterer Performance oder anderen Nachteilen führen. TDRs bieten eine klare Übersicht über bestehende technische Schulden, deren Auswirkungen und die Maßnahmen zu ihrer Behebung.

Motivation für TDRs

Technische Schulden können, wenn sie unkontrolliert bleiben, erhebliche negative Auswirkungen auf ein Projekt haben:

Durch die systematische Dokumentation mittels TDRs können Teams diese Schulden frühzeitig erkennen, priorisieren und gezielt angehen, bevor sie unkontrollierbar werden.

Vorteile von TDRs für Entwicklerinnen, Architekten und Tester

Es ist somit essenziell, technische Schulden zu dokumentieren. Technical Debt Records bieten hierbei verschiedene Vorteile für die Projektbeteiligten.

Für Entwickler:

Für Architekten:

Für Tester:

Damit die Beschreibung von Technical Debt Records nicht nur theoretisch bleibt, soll das konkrete Beispiel im folgenden Kasten zur Veranschaulichung dienen. Es geht um eine veraltete Authentifizierungsbibliothek. Hat das zugehörige TDR schon ein paar Stufen des Workflows durchlaufen, könnte es sich so präsentieren.

Das TDR-Template und seine Felder

Ein gut strukturiertes TDR-Template ist entscheidend für die effektive Dokumentation technischer Schulden. Ein Werkzeug (siehe weiter unten) generiert TDRs mit folgenden Feldern:

• Titel: Eine prägnante Bezeichnung der technischen Schuld.
• Autor: Die Person, die die Schuld identifiziert oder dokumentiert hat.
• Version: Die Version des Projekts oder der Komponente, in der die Schuld existiert.
• Datum: Das Datum der Identifikation oder Dokumentation der technischen Schuld.
• State: Der aktuelle Status der technischen Schuld (z.B. Identified, Analyzed, Approved, In Progress, Resolved, Closed, Rejected).
• Relations: Verweise auf andere verwandte ADRs oder TDRs, um Zusammenhänge zu verdeutlichen.
• Zusammenfassung: Eine kurze Übersicht über die technische Schuld und deren Bedeutung.
• Kontext: Detaillierte Hintergrundinformationen, warum die Schuld entstanden ist (z.B. Zeitdruck, veraltete Technologien).
• Auswirkungen:
  • Technische Auswirkungen: Wie die Schuld die Systemleistung, Skalierbarkeit oder Wartbarkeit beeinflusst.
  • Geschäftliche Auswirkungen: Die Auswirkungen auf Geschäftsprozesse, Kundenzufriedenheit oder Risikoebenen.
• Symptome: Beobachtbare Anzeichen, die auf die Präsenz der technischen Schuld hinweisen (z.B. häufige Bugs, langsame Performance).
• Schweregrad: Die Kritikalität der Schuld (Critical, High, Medium, Low).
• Potenzielle Risiken: Mögliche negative Folgen, wenn die Schuld nicht behoben wird (z.B. Sicherheitslücken, erhöhte Kosten).
• Vorgeschlagene Lösung: Empfohlene Maßnahmen zur Behebung der technischen Schuld.
• Kosten der Verzögerung: Die Konsequenzen, wenn die Behebung der Schuld verzögert wird.
• Aufwand zur Behebung: Geschätzter Aufwand in Zeit und Ressourcen, um die Schuld zu beheben.
• Abhängigkeiten: Andere Aufgaben, Komponenten oder externe Faktoren, die die Behebung der Schuld beeinflussen.
• Zusätzliche Hinweise: Weitere relevante Informationen oder Überlegungen zur Schuld.

Das sind auf den ersten Blick sehr viele Aspekte. Doch keine Sorge, die Dokumentation dieser Felder erfolgt inkrementell im Lebenszyklus der dokumentierten technischen Schuld. Den augenblicklichen Zustand und damit den Workflow eines TDR beschreibt das Feld state.

Rationale für das State-Feld

Das State-Feld spiegelt den Workflow wider, also wie Entwickler technische Schulden handhaben sollten. Es hilft dabei, den Fortschritt bei der Bearbeitung der Schuld zu verfolgen und sicherzustellen, dass keine Schulden unbeachtet bleiben. Die definierten Zustände sind:

• Identified: Die technische Schuld wurde erkannt.
• Analyzed: Die Auswirkungen und der Aufwand zur Behebung wurden bewertet.
• Approved: Die Behebung der Schuld wurde genehmigt.
• In Progress: Die Arbeit zur Behebung der Schuld ist im Gange.
• Resolved: Die technische Schuld wurde behoben.
• Closed: Der TDR wurde abgeschlossen und ist nicht mehr relevant.
• Rejected: Die Behebung der Schuld wurde abgelehnt.

Diese Zustände ermöglichen es Teams, den Status jeder technischen Schuld klar zu definieren und entsprechende Maßnahmen zu ergreifen.

Inkrementelle Anpassung der Felder je nach State

Beim ersten Identifizieren einer technischen Schuld können einige Felder noch leer bleiben:

• Initiale Identifikation (Identified):
  • Zu beschreiben: Titel, Autor, Version, Datum, State, Zusammenfassung, Kontext.
  • Leer: Auswirkungen, Symptome, Schweregrad, Potenzielle Risiken, Vorgeschlagene Lösung, Kosten der Verzögerung, Aufwand zur Behebung, Abhängigkeiten, Zusätzliche Hinweise.
• Analysephase (Analyzed):
  • Zu beschreiben: Alle Felder des Identified-Status plus Auswirkungen, Symptome, Schweregrad, Potenzielle Risiken.
• Genehmigungsphase (Approved):
  • Zu beschreiben: Alle bisherigen Felder plus Vorgeschlagene Lösung, Kosten der Verzögerung.
• Umsetzungsphase (In Progress):
  • Zu beschreiben: Alle bisherigen Felder plus Aufwand zur Behebung, Abhängigkeiten.
• Abschlussphase (Resolved & Closed):
  • Zu beschreiben: Alle Felder einschließlich Zusätzliche Hinweise.

Durch diese schrittweise Ergänzung bleibt die Dokumentation stets aktuell und reflektiert den Fortschritt bei der Behebung der technischen Schulden.

Ein Werkzeug zur Erstellung von TDRs

Die Dokumentation technischer Schulden würde dann an Akzeptanz verlieren, wenn die Dokumentation technischer Schulden sich als manuell und aufwendig erweist. In diesem Fall könnte es auch passieren, dass Entwickler Felder vergessen, umbenennen oder wichtige Felder ignorieren.

Der TDR-Generator ist ein Go-basiertes Werkzeug, das die Erstellung von Technical Debt Records in verschiedenen Formaten automatisiert. Es unterstützt Markdown, Plain ASCII, PDF und Excel und erleichtert somit die Integration in unterschiedliche Entwicklungs- und Dokumentationsprozesse.

Features des TDR-Generators

Werkzeugunterstützung für TDRs hat sich auch schon bei ADRs bewährt. So lassen sich Schablonen generieren, mit deren Hilfe Architektinnen und Architekten die technischen Schulden beschreiben. Dementsprechend weist der TDR-Generator folgende Vorteile auf:

Repository und Installation

Der TDR-Generator ist auf GitHub verfügbar. Sie können das Repository hier [1] finden.

Zur Installation bedarf es folgender Schritte:

1. Klonen des Repositories: git clone git@github.com/ms1963/TechnicalDebtRecords.git
2. Initialisieren des Go-Moduls: go mod init technical_debt_generator
3. Installieren der Abhängigkeiten: go get github.com/phpdave11/gofpdf && go get github.com/xuri/excelize/v2
4. Kompilieren des Programmes: go build generate-td.go

Wer möchte, kann aber auch einfach make im Quellcodeverzeichnis aufrufen. Dadurch erfolgt die Kompilation automatisch über das mitgelieferte Makefile. Voraussetzung ist allerdings in jedem Fall die vorhergehende Installation des go-Compilers [2].

Nutzung des TDR-Generators

Das Programm lässt sich über die Kommandozeile mit verschiedenen Optionen ausführen.

Verfügbare Optionen:

• -format: Gibt das Ausgabeformat an. Mögliche Werte sind markdown, ascii, pdf, excel. Standard ist markdown.
• -output: (Optional) Gibt den Dateinamen für die Ausgabe an. Wenn nicht angegeben, wird ein Standardname verwendet.
• -empty: (Optional) Erstellt ein leeres TDR mit Platzhaltern, ohne nach Eingaben zu fragen.
• --help oder -h: Zeigt die Hilfsnachricht mit Nutzungshinweisen an.

Beispiele:

1. Generiere ein Markdown-Dokument: ./generate-td -format markdown
2. Generiere ein PDF-Dokument mit benutzerdefiniertem Dateinamen: ./generate-td -format pdf -output mein_td_record.pdf
3. Generiere ein leeres Excel-Dokument: ./generate-td -format excel -empty
4. Zeige eine Hilfemeldung an: ./generate-td --help

Integration in Versionskontrollsysteme

Um die Nachverfolgung und Zusammenarbeit zu erleichtern, sollten TDRs in ein Versionskontrollsystem wie Git oder SVN eingecheckt werden. Dies ermöglicht:

• Versionierung: Nachverfolgung von Änderungen und Historie der technischen Schulden.
• Zusammenarbeit: Gemeinsame Bearbeitung und Überprüfung von TDRs durch das Team.
• Zugänglichkeit: Einfache Integration in bestehende Entwicklungsprozesse und Pipelines.

Beispiel für Git:

1. Füge das TDR dem Repository hinzu: git add technical_debt_record.md
2. Bestätige die Änderung: git commit -m "Add TDR für veraltete Authentifizierungsbibliothek"
3. Speichere die Änderung: git push origin main

Durch die Einbindung von TDRs in das Versionskontrollsystem bleibt die Dokumentation stets aktuell und für alle Teammitglieder zugänglich.

Fazit

Technical Debt Records (TDRs) sind ein effektives Instrument zur Verwaltung technischer Schulden in Softwareprojekten. Sie bieten Transparenz, erleichtern die Priorisierung und unterstützen strategische Entscheidungen zur Verbesserung der Codequalität und Systemarchitektur. Der vorgestellte TDR-Generator vereinfacht die Erstellung dieser wichtigen Dokumente und integriert sich nahtlos in bestehende Entwicklungs- und Versionskontrollprozesse.

Indem Teams TDRs konsequent verwenden und in ihre Workflows integrieren, können sie die negativen Auswirkungen technischer Schulden minimieren und die langfristige Gesundheit und Wartbarkeit ihrer Softwareprojekte sicherstellen.

Wie erwähnt, finden Sie das beschriebene Werkzeug in einem GitHub-Repository [3].

URL dieses Artikels:
https://www.heise.de/-9876115

Links in diesem Artikel:
[1] https://github.com/ms1963/TechnicalDebtRecords/
[2] https://go.dev/doc/install
[3] https://github.com/ms1963/TechnicalDebtRecords/
[4] mailto:who@heise.de

Copyright © 2024 Heise Medien

Adblock test (Why?)

Die Einführung des EU Accessibility Act? Das wird teuer!

Es sollte selbstverständlich sein, Menschen nicht auszuschließen – doch in der IT wird genau das ständig gemacht. Ab 2025 gelten in der EU andere Regeln.

Ich bin mir ziemlich sicher, dass Sie diesen Artikel aus einem von zwei Gründen angeklickt haben. Entweder, weil Sie dachten:

"Ja, Accessibility ist wirklich ein leidiges Thema, und es kostet tatsächlich furchtbar viel, sich damit auseinanderzusetzen. Endlich spricht das mal jemand aus!"

Oder weil Sie dachten:

"Was ist das denn für eine Aussage? Natürlich kostet Accessibility Geld, aber das darf doch nicht der Maßstab sein, sich nicht mit dem Thema zu beschäftigen."

Nun, soll ich Ihnen etwas verraten? Wenn einer dieser beiden Gedanken Ihnen tatsächlich durch den Kopf gegangen ist, habe ich Sie erfolgreich auf eine falsche Fährte geführt, denn beide Interpretationen des Titels treffen nicht zu. Doch wie ist der Titel dann tatsächlich gemeint?

Vorweg möchte ich klarstellen: Natürlich kostet Accessibility Geld. Es ist definitiv aufwendiger, sich Gedanken um Barrierefreiheit zu machen, die entsprechenden Konzepte zu erlernen und diese letztlich angemessen zu implementieren und zu testen, als dies einfach zu ignorieren. Dieses Argument ist zunächst einmal legitim. Die entscheidende Frage aber ist, und das ist der zweite Punkt, den ich bereits angedeutet habe: Darf man die Entscheidung, ob man beispielsweise eine Webseite für Menschen mit Behinderungen zugänglich macht, allein auf Basis von wirtschaftlichen Überlegungen treffen? Oder ist das nicht vielmehr ethisch fragwürdig?

Letztlich handelt es sich dabei um keine technische, sondern eine philosophische Frage. Es geht um Ethik und Moral, um persönliche Überzeugungen, vielleicht sogar um die eigene Betroffenheit. Wer selbst eine Behinderung hat oder Menschen im nahen Umfeld kennt, die betroffen sind, wird vermutlich anders über dieses Thema denken als jemand, der meint, Menschen mit Behinderungen seien eine marginale Gruppe, die keine Rolle spielt.

Der European Accessibility Act kommt im Jahr 2025

Der entscheidende Punkt ist: Ganz gleich, welche Meinung Sie zu der Frage haben, wie viel man in Accessibility investieren sollte – ab dem kommenden Jahr stellt sich diese Frage schlichtweg nicht mehr. Ab dem 28. Juni 2025 haben Sie in vielen Fällen nämlich keine Wahl mehr. Denn ab diesem Datum tritt die neue EU-Richtlinie European Accessibility Act (EAA) in Kraft. Der EAA verpflichtet Sie, für bestimmte Produkte und Dienstleistungen Barrierefreiheit umzusetzen – unabhängig davon, ob Sie das wollen oder nicht.

Zu diesen Produkten und Dienstleistungen zählen unter anderem Webseiten. Die Liste ist jedoch viel länger und enthält viele allgemeine Kategorien, was bedeutet, dass sie vielseitig interpretierbar ist. Wenn man das ernst nimmt, betrifft der EAA am Ende viele Bereiche, in denen sich plötzlich jemand mit Accessibility beschäftigen muss. Dazu gehören neben Webseiten auch mobile Apps, E-Books, Self-Service-Terminals wie Geldautomaten oder Fahrkartenautomaten, Getränkeautomaten und vieles mehr. Auch "digitale Dienstleistungen" wie E-Commerce-Websites, Online-Shops, Online-Zahlungen und der Transportsektor, beispielsweise Buchungssysteme, sind betroffen. Die Anforderungen an all diese Systeme? Der EAA fordert eine einfache und effiziente Gestaltung, insbesondere in Bezug auf die Bedienbarkeit und den Zugang zu Informationen.

Warum sollten Sie sich für den EAA interessieren? Ganz einfach: Weil er ab dem 28. Juni 2025 als einheitlicher Standard in der gesamten Europäischen Union gilt. Wenn Sie also Software oder Hardware auf den Markt bringen, die zu den genannten Kategorien gehört und den Anforderungen des EAA nicht entspricht, drohen empfindliche Geldstrafen – und dann wird fehlende Accessibility richtig teuer. Die Geldstrafen fallen nämlich nicht gerade gering aus. Wer bereits dachte, die DSGVO sei teuer, wird vom EAA noch einmal überrascht werden.

Accessibility ist kein neues Thema

Es wird deutlich, dass es der EU ernst damit ist, das Thema Accessibility zu fördern. Ich sehe bereits, wie sich viele darüber ärgern und sagen werden:

"Warum wird das jetzt gesetzlich vorgeschrieben?"

Doch darauf gibt es eine einfache Antwort. Zum einen ist das Ganze gar nicht so neu, wie Sie vielleicht gerade denken. Es gab auch bisher schon gewisse Verpflichtungen zur Barrierefreiheit, allerdings betraf das hauptsächlich den öffentlichen Sektor, insbesondere Behörden. Dennoch gab es bereits entsprechende Regelungen, die nun erweitert werden: In Deutschland beispielsweise das Behindertengleichstellungsgesetz (BGG) und die Barrierefreie Informationstechnik-Verordnung (BITV 2). In der EU stellt seit 2018 die Web Accessibility Directive konkrete Anforderungen an Webseiten und Apps öffentlicher Stellen.

Zudem gibt es die Behindertenrechtskonvention der Vereinten Nationen, die zwar keine technischen Maßnahmen fordert, aber doch eine allgemeine Zielsetzung vorgibt. Die EU hält sich unter anderem an diese Vorgaben, und die Mitgliedsstaaten waren und sind verpflichtet, Barrierefreiheit zu fördern. Das Einzige, was sich nun ändert, ist, dass sich diese Regelungen nicht mehr nur auf den öffentlichen Sektor beziehen, sondern auch auf die Privatwirtschaft und eine breitere Palette von Produkten. Die EU verfolgt damit das Ziel, die technischen Maßnahmen innerhalb der Mitgliedsstaaten zu harmonisieren, um unterschiedliche nationale Regelungen zu vermeiden.

Ein Randgruppen-Thema? Nein!

Persönlich finde ich es traurig, dass es solche Gesetze und die Androhung von hohen Strafen braucht, um Veränderungen anzustoßen. Sollte das nicht von selbst passieren, weil es das Richtige ist? In welcher Welt ist es in Ordnung zu sagen:

"Wir ignorieren die Bedürfnisse und Anforderungen einer ganzen Gruppe von Menschen, nur weil es Geld kostet?"

Natürlich verstehe ich, dass das täglich so abläuft, aber das macht es nicht weniger falsch. Und natürlich weiß ich auch, dass meine rhetorische Frage überflüssig ist, denn offensichtlich passiert der Wandel nicht von selbst, sonst wäre der EAA nicht notwendig. Dennoch finde ich es bedauerlich.

Was mich daran besonders ärgert, ist, dass Accessibility oft als Thema betrachtet wird, das nur wenige Menschen betrifft und keine Rolle im Alltag der meisten spielt. Beides ist falsch. Es betrifft nicht nur wenige Menschen. Vielleicht denken Sie bei "Menschen mit Behinderung" an jemanden, der sehbehindert oder blind ist. Doch es gibt viele Abstufungen dazwischen. Ich zum Beispiel bin zwar nicht blind, aber ich habe sehr schlechte Augen. Ohne Kontaktlinsen oder Brille bin ich im Alltag stark eingeschränkt, und ich kann außerdem auch nicht dreidimensional sehen. Mein Gehirn hat es nie gelernt, aus den Bildern beider Augen ein räumliches Bild zu konstruieren. Alles, was ich sehe, ist flach wie ein Foto, weshalb ich Entfernungen nicht einschätzen kann. Hinzu kommt, dass es mir mit zunehmendem Alter schwerer fällt, kleine oder kontrastarme Schriften zu lesen. Früher war das einfacher.

Fast jeder Mensch ist im Laufe seines Lebens zumindest teilweise betroffen

Und so gibt es viele Menschen, die nicht perfekt sehen können: Sei es wegen einer hohen Dioptrien-Zahl, einer Rot-Grün-Sehschwäche, Farbenblindheit oder anderen Einschränkungen. Und das betrifft nicht nur das Sehen. Auch der Hörsinn lässt mit dem Alter nach. Wir können im jungen Alter sehr hohe Frequenzen hören, die später nicht mehr wahrgenommen werden. Das bedeutet nicht, dass jemand vollständig gehörlos sein muss, um eine Einschränkung zu erleben. Schon eine leichte Verschlechterung des Gehörs kann problematisch sein, wenn man auf sprachbasierte Systeme angewiesen ist. Und auch diesen Menschen würde eine bessere Accessibility helfen.

Gleiches gilt für einfache Sprache oder Menschen, die aufgrund einer Verletzung, beispielsweise eines gebrochenen Arms, nicht gut mit einer Maus umgehen können. Daher ist es nicht stichhaltig zu sagen, Accessibility betreffe nur wenige Menschen. Stattdessen sollten wir uns eher fragen: Wie wenige Menschen haben keinerlei Einschränkungen in ihren Sinneswahrnehmungen? Sollten wir Webseiten tatsächlich immer so gestalten, als ob alle Nutzer perfekt sehen und hören können? Oder wäre es nicht besser, wenn wir es ermöglichen, zum Beispiel ein anderes Design mit höherem Kontrast zu wählen? Oder wenn wir Audio und Video standardmäßig mit Untertiteln oder Transkriptionen anbieten würden?

Bevor Sie nun sagen, "das braucht doch niemand", denken Sie einmal kurz nach: Warum sind eigentlich fast alle Kurzvideos untertitelt? Ganz einfach: Viele Menschen schauen sich diese Videos unterwegs an, zum Beispiel im Bus oder in der Bahn, oft ohne Kopfhörer. Das zeigt, dass es oft auch einfach Situationen gibt, in denen man dankbar für visuelle Unterstützung ist, weil man den auditiven Kanal nicht nutzen kann. Mit anderen Worten: Sollte es nicht unsere moralische Verpflichtung sein, dafür zu sorgen, dass Inklusion stattfindet und wir niemanden ausschließen? Ich finde: Ja.

Technische Maßnahmen

Tatsächlich ist es auch gar nicht so schwierig, dabei den ersten Schritt zu machen. Gerade bei Webseiten bietet es sich an, sich mit semantischem HTML zu beschäftigen, was keine willkürliche <div>-Suppe ist, sondern dazu beiträgt, die Seite strukturell zu gliedern. Das erleichtert Screenreadern die Arbeit und ist daher eine Verbesserung. Dasselbe gilt für ARIA-Attribute, die es seit Jahren in HTML gibt, die aber kaum jemand kennt, geschweige denn einsetzt. Und natürlich wird es auch immer Situationen geben, in denen man an Grenzen stößt. Das sollte aber kein Grund sein, es nicht zumindest zu versuchen und so gut wie möglich umzusetzen. Eine bessere Nutzung von semantischem HTML führt übrigens nicht nur zu einer Verbesserung für Screenreader, sondern auch zu einer besseren Verständlichkeit der Seite für Suchmaschinen.

Um einmal ein Gefühl dafür zu bekommen, wie schwierig es ist, sich in der digitalen Welt zurechtzufinden, wenn man nicht sehen kann, aktivieren Sie doch einfach einmal die Bedienungshilfen auf Ihrem Smartphone, zum Beispiel die VoiceOver-Funktion bei iOS. Ich meine, wie schwer kann es schon sein, ein Gerät, das Sie jeden Tag unzählige Male nutzen, quasi "blind" zu bedienen? Ohne das "Erlebnis" vorwegnehmen zu wollen: Ich persönlich fand es erschreckend, wie schlecht das insgesamt funktioniert. Und dabei ist das System von Apple noch eines der besten auf dem Markt.

Dennoch habe ich nicht lange durchgehalten, bevor ich das Gefühl hatte, mein Telefon aus dem Fenster werfen zu wollen. Es ist erstaunlich, wie groß die Einschränkung tatsächlich sein kann. Dass ein Unternehmen mit einem Marktwert von über drei Billionen US-Dollar keine bessere Lösung bietet, finde ich enttäuschend. Genau deshalb brauchen wir leider doch Gesetze wie den EAA, damit sich etwas bewegt.

Eine gesamtgesellschaftliche Herausforderung

Für mich ist die wichtigste Erkenntnis dieses Themas: Wir alle müssen uns viel mehr mit Barrierefreiheit und Inklusion beschäftigen. Denn aktuell haben es Menschen, die nicht perfekt sehen oder hören können, in der digitalen Welt sehr viel schwerer, als man gemeinhin glaubt. Und je mehr das Digitale in unseren Alltag eindringt, desto wichtiger wird es, niemanden zurückzulassen. Accessibility ist so gesehen also weit mehr als nur ein technisches Thema – es ist eine gesamtgesellschaftliche Aufgabe. Und wir als Entwicklerinnen und Entwickler haben die Chance, mit relativ wenig Aufwand einen signifikanten positiven Unterschied zu machen. Und den sollten wir nutzen.

Wenn Sie von all dem nicht überzeugt sind, dann gilt ab dem kommenden Jahr der European Accessibility Act – und spätestens dann wird niemand mehr fragen, ob Sie Accessibility für sinnvoll erachten oder nicht. Dann sind Sie dazu verpflichtet. Aber wie schön wäre es, wenn möglichst viele Menschen von sich aus erkennen, dass es eigentlich freiwillig geschehen sollte – weil es das Richtige ist. In diesem Sinne möchte ich diesen Beitrag mit dem kleinen Appell beenden: Lassen Sie uns alle dazu beitragen, die Welt zu einem etwas besseren Ort zu machen für all jene, die es im Alltag ohnehin schon unnötig schwer haben.

PS: Übrigens, auch wir bei the native web [4] machen dabei definitiv nicht alles richtig, ich möchte uns nicht auf ein Podest stellen. Unsere aktuelle Website ist sicherlich kein Vorzeigeprojekt, aber das wird sich in der nächsten Version ändern.

URL dieses Artikels:
https://www.heise.de/-9939623

Links in diesem Artikel:
[1] https://www.heise.de/Datenschutzerklaerung-der-Heise-Medien-GmbH-Co-KG-4860.html
[2] https://enterjs.de/accessibility.php?wt_mc=intern.academy.dpunkt.konf_dpunkt_ejs_access.empfehlung-ho.link.link
[3] https://enterjs.de/accessibility.php?wt_mc=intern.academy.dpunkt.konf_dpunkt_ejs_access.empfehlung-ho.link.link
[4] https://www.thenativeweb.io/
[5] mailto:mai@heise.de

Copyright © 2024 Heise Medien

Adblock test (Why?)

Mehr als nur Programmieren: Ankündigung der tech:lounge Masterclass

Die the native web GmbH veranstaltet ab dem 11. November 2024 insgesamt zwölf Webinare zu den Themen Performance, Clean Code, Security und Architektur.

Im Herbst richtet die the native web GmbH [1] insgesamt zwölf Webinare aus den Themenbereichen Performance, Clean Code, Security und hexagonale Architektur aus.

Die Webinare finden ab dem 11. November jeweils montags, mittwochs und freitags von 9.00 Uhr bis 12.30 Uhr statt und vermitteln die aktuellen Themen der zeitgemäßen Softwareentwicklung auf anschauliche und verständliche Art in Theorie und Praxis. Die Themenauswahl umfasst sowohl grundlegende als auch fortgeschrittene Themen.

Performante Anwendungen entwickeln (Details anzeigen [2])

• 11.11. – Einführung in Performance-Optimierung
• 13.11. – Optimierte Algorithmen verwenden
• 15.11. – Performance-Tuning in der Praxis

Cleaner Code, hohe Qualität (Details anzeigen [3])

• 18.11. – Zeitgemäße Einführung in Clean Code
• 20.11. – Codeanalyse und Refactoring
• 22.11. – Qualitätssicherung durch Tests

Sichere Software entwickeln (Details anzeigen [4])

• 02.12. – Praktische Grundlagen von Security
• 04.12. – Security: Techniken und Werkzeuge
• 06.12. – Security im Entwicklungsprozess

Hexagonale Architektur (Details anzeigen [5])

• 09.12. – Grundlagen hexagonaler Architektur
• 11.12. – Modulithen und Microservices
• 13.12. – Transformation von Legacy-Software

Die Webinare werden als Livestream durchgeführt, sodass man einfach und bequem teilnehmen kann – ganz gleich, ob von zu Hause oder aus dem Büro. Für Fragen steht ein Chat zur Verfügung.

Der Preis beträgt 179 Euro pro Webinar. Wer drei Webinare aus einem Themenbereich als Paket bucht, erhält etwa 25 Prozent Rabatt gegenüber der Einzelbuchung, der Preis beträgt dann 399 Euro. Darüber hinaus gelten noch einmal günstigere Konditionen für Teams. Alle Preise verstehen sich jeweils zuzüglich 19 Prozent Umsatzsteuer.

Im Preis enthalten ist neben der Teilnahme am Livestream auch der Zugriff auf die Aufzeichnung des Webinars und die Codebeispiele.

Alle weitergehenden Informationen und eine Buchungsmöglichkeit finden sich auf der Webseite der tech:lounge Masterclass [6].

URL dieses Artikels:
https://www.heise.de/-9870380

Links in diesem Artikel:
[1] https://www.thenativeweb.io/
[2] https://www.thenativeweb.io/techlounge/developing-performant-applications
[3] https://www.thenativeweb.io/techlounge/clean-code-high-quality
[4] https://www.thenativeweb.io/techlounge/developing-secure-software
[5] https://www.thenativeweb.io/techlounge/hexagonal-architecture
[6] https://www.techlounge.io/
[7] mailto:mai@heise.de

Copyright © 2024 Heise Medien

Adblock test (Why?)

Eine Frage des Vertrauens: Finger weg vom Homeoffice!

Viele Konzerne wollen das Homeoffice abschaffen. Die Politik hingegen diskutiert über ein gesetzlich verankertes Recht darauf. Was spricht dafür, was dagegen?

Finger weg vom Homeoffice! Dieser Titel ist so wunderbar zweideutig: Einerseits kann man ihn als Warnung verstehen, bloß nicht erst mit dem Homeoffice anzufangen. Andererseits lässt sich dieser Titel auch als Aufforderung deuten, das inzwischen doch weit verbreitete Homeoffice nicht anzutasten oder es in Frage zu stellen. Im Sinne von:

"Nehmt uns bloß nicht unser lieb gewonnenes Homeoffice weg!"

Und genau dieser Titel spiegelt auch wunderbar die derzeitige gesellschaftliche Lage wider: Auf der einen Seite gibt es zahlreiche Konzerne, die das Homeoffice am liebsten wieder komplett abschaffen würden. Auf der anderen Seite steht die Politik, die derzeit immerhin darüber nachdenkt, ob es nicht ein gesetzliches Recht auf Homeoffice geben sollte. Und bei so viel Hin und Her, so viel Pro und Contra, stellt sich natürlich die Frage: Wer hat denn nun eigentlich recht? Was haben wir wirklich Positives vom Homeoffice? Und welche negativen Aspekte bringt es möglicherweise mit sich? Und genau um diese Fragen geht es im heutigen Blogpost.

Bevor wir richtig loslegen, noch eine kleine Ankündigung in eigener Sache: In den vergangenen beiden Blogposts hatte ich gefragt, ob Interesse besteht, dass ich einmal den von uns bei the native web [1] gelebten Entwicklungsprozess vorstelle. Da das Feedback sehr positiv war, wundern Sie sich jetzt vielleicht, dass es heute nicht um diesen Prozess geht. Der Grund, warum wir heute nicht über unseren Prozess sprechen, ist ganz einfach: Wir glauben, dass eine umfassende Beschreibung den Umfang eines Blogposts deutlich übersteigen würde, zumal es sicherlich zahlreiche Fragen dazu geben wird.

Daher wollen wir uns für dieses Thema mehr Zeit nehmen und veranstalten am kommenden Mittwoch, 25. September, um 18 Uhr einen Livestream, in dem wir uns unserem Prozess ausführlich widmen können. Wenn Sie diesen Livestream nicht verpassen wollen, rufen Sie ihn jetzt schon einmal auf [2] und aktivieren Sie dort die Erinnerung, damit YouTube Sie rechtzeitig daran erinnern kann. Alternativ können Sie den Termin natürlich auch ganz klassisch in Ihren guten, alten Kalender eintragen. Und damit zurück zum eigentlichen Thema.

Homeoffice: Eine Reaktion auf Corona

Homeoffice ist für die meisten Menschen, die in der IT-Branche tätig sind, etwas, das im größeren Stil erst seit der Corona-Pandemie existiert. Klar, auch davor war es je nach Unternehmen möglich, mal den einen oder anderen Tag von zu Hause zu arbeiten, aber die Regel war das sicherlich nicht. Tatsächlich ist das bei uns, also bei the native web, ein wenig anders. Wir arbeiten seit unserer Gründung im Jahr 2012 vollständig remote – zu 100 Prozent. Das heißt, bei uns gab es de facto noch nie etwas anderes als Homeoffice.

Sowohl meine Kolleginnen und Kollegen als auch ich schätzen die Vorteile dieser Arbeitsweise sehr: Homeoffice bietet uns allen eine viel höhere Flexibilität im Alltag. Man kann zwischendurch einkaufen gehen, man kann einen Spaziergang machen oder mit dem Hund rausgehen, man kann bei den Hausaufgaben helfen, als Familie gemeinsam zu Mittag essen, man spart sich die Zeit, die sonst für das Pendeln draufgeht, und vieles mehr. Kurz gesagt: Man hat eine ganz andere Lebensqualität.

Aber das Arbeiten von zu Hause aus hat nicht nur Vorteile. Es kann schnell zur sozialen Isolation führen. Es kann dazu führen, dass man, wenn es an Selbstdisziplin und Eigenverantwortung mangelt, den Job vernachlässigt. Es kann zu Konflikten in der Partnerschaft führen, weil man zwar körperlich, aber nicht gedanklich zu Hause ist. Es kann zu Schwierigkeiten kommen, wenn das Privatleben und die beruflichen Anforderungen miteinander kollidieren. Kurz gesagt: Homeoffice ist nicht zwangsläufig ein Zuckerschlecken, sondern kann auch sehr anstrengend werden.

Nicht jede Branche ist gleich

Hinzu kommt, dass Homeoffice natürlich nicht für jede Branche gleichermaßen geeignet ist: Was in der Softwareentwicklung sehr gut funktionieren kann, wird in IT-Berufen, die auf Spezialhardware wie Roboter oder Ähnliches angewiesen sind, schon schwieriger. Und über Berufe außerhalb der IT müssen wir an dieser Stelle gar nicht erst sprechen: Es ist zum Beispiel völlig illusorisch anzunehmen, dass jemand in der Gastronomie oder in der Pflege von zu Hause arbeiten könnte. Im Gegenteil, dort ist die physische Präsenz oft unerlässlich. Daher beziehe ich mich im Folgenden ausschließlich auf die IT-Branche, und alle Aussagen, die ich treffe, sollten in diesem Kontext verstanden werden.

Und damit kommen wir zu einem Punkt, der seit etwa zwei Jahren immer wieder heiß diskutiert wird: nämlich die Pflicht, ins Büro zurückzukehren. Das ist ja etwas, was vor allem die größeren Tech-Konzerne gerne fordern. Wobei, um fair zu bleiben, nicht nur die Großen betroffen sind: Solche Forderungen gibt es auch im kleineren Rahmen, nur führt das dann eben nicht zu so vielen Schlagzeilen. Ein krasses Negativbeispiel sind Elon Musk und Tesla. Im Sommer 2022 stellte Musk den Tesla-Mitarbeiterinnen und -Mitarbeitern ein Ultimatum [4]: Entweder sie kehren ins Büro zurück oder sie kündigen. Wenn man sich ansieht, wie Musk generell mit seinen Angestellten umgeht, wird schnell klar, dass ihm völlig egal ist, wer jemand ist oder welche Aufgabe jemand im Unternehmen übernimmt: Wer nicht zurückkommt, wird eben entlassen, immerhin hatte man ja die Wahl. Sinngemäß: "Dein Problem, wenn Du Dich (aus seiner Sicht) falsch entschieden hast."

Warum wird die Rückkehr überhaupt gefordert?

Nun ist es vielleicht nicht so, dass jedes Unternehmen, das die Rückkehr ins Büro fordert, direkt so hart vorgeht. Aber immer wieder hört man von Unternehmen, in denen das Thema "zu Hause arbeiten versus im Büro anwesend sein" für Spannungen sorgt. Für mich stellt sich dabei die Frage: Warum fordern so viele Unternehmen die Rückkehr ins Büro? Ich habe dazu meine eigene Theorie. Natürlich weiß ich nicht, ob sie zutrifft, und ich will auch nicht jedem Unternehmen pauschal unterstellen, dass es so ist. Aber ich kenne genug Firmen, bei denen ich mir gut vorstellen kann, dass meine Theorie ziemlich genau die Gründe trifft, warum die Rückkehr ins Büro gefordert wird.

Meine Theorie lautet: Es geht um fehlende Kontrolle. Viele Führungskräfte, die ich im Laufe der Zeit kennengelernt habe, denken: Wenn jemand nicht vor Ort ist, kann man sie oder ihn auch nicht kontrollieren. Und wenn jemand nicht vor Ort ist, woher soll man dann wissen, ob diese Person auch wirklich arbeitet? Und nur um das klarzustellen: Ich will hier nicht alle Führungskräfte über einen Kamm scheren. Es gibt auch viele fähige und gute Vorgesetzte, aber es gibt eben auch schwarze Schafe.

Persönlich halte ich von dieser Argumentation übrigens überhaupt nichts. Die bloße Tatsache, dass jemand im Büro körperlich anwesend ist, bedeutet noch lange nicht, dass diese Person tatsächlich arbeitet. Man kann, und das sage ich aus eigener Erfahrung, auch sehr intensiv im Internet surfen, an privatem Code arbeiten, Spiele spielen und so weiter, und dabei so tun, als sei man schwer beschäftigt. Wer das Ganze noch auf die Spitze treiben will, kann sich mit zwei oder drei Kolleginnen und Kollegen einen Konferenzraum buchen. Denn wer im Konferenzraum wild diskutiert, muss ja arbeiten, oder? Dass hinter verschlossener Tür vielleicht lediglich die Bundesliga-Ergebnisse vom Wochenende besprochen werden, darauf kommt natürlich niemand.

Vertrauen und Kontrolle

Der Punkt ist: Körperliche Anwesenheit und tatsächliches Arbeiten sind zwei völlig unterschiedliche Dinge. Und wenn ein Unternehmen Zweifel daran hat, dass jemand arbeitet, nur weil die Person nicht physisch präsent ist, dann ist das aus meiner Sicht kein Problem von "Homeoffice ja oder nein", sondern von fehlendem Vertrauen. Und wenn es eigentlich um fehlendes Vertrauen geht, dann liegt das tatsächliche Problem sehr viel tiefer.

Wenn man den Menschen, mit denen man zusammenarbeitet, nicht vertrauen kann, wird das auch nicht besser, wenn sie vor Ort sind. Dann hat man lediglich die Illusion von Kontrolle. Aber fehlendes Vertrauen ist ein gravierendes, fundamentales Problem für die Zusammenarbeit. Und ich glaube, und das ist meine Theorie, dass die meisten Unternehmen, die so vehement die Rückkehr ins Büro fordern, ein großes Vertrauensproblem in ihrer Unternehmenskultur haben. Es ist aber so viel einfacher, die Symptome zu bekämpfen, indem man fordert, die Leute sollen doch bitte zurück ins Büro kommen, als sich mit den eigentlichen Ursachen auseinanderzusetzen und zu fragen, warum das Vertrauen eigentlich fehlt.

Das Problem dabei ist, dass man Vertrauen nicht anordnen kann. Ich kann nicht befehlen, dass plötzlich Vertrauen herrscht. Es gibt keine Technologie und kein Tool, das mir dabei wirklich helfen kann. Vertrauen muss gegeben werden, es kann nicht eingefordert werden. Und ich weiß, dass es Menschen gibt, die anderen mit einem großen Vertrauensvorschuss begegnen, und andere, die sagen, dass man sich Vertrauen erst verdienen muss. Beide Ansichten sind für mich in Ordnung, aber es müssen eben beide Seiten (das Unternehmen und die Mitarbeiterinnen und Mitarbeiter) ihren Beitrag leisten, damit langfristig eine vertrauensvolle Zusammenarbeit möglich ist.

Wie entsteht Vertrauen?

Was schafft denn Vertrauen? Aus meiner Sicht als einer der Geschäftsführer von the native web gibt es einen zentralen Punkt, den ich immens wichtig finde und der auch essenziell für unsere Unternehmenskultur ist: Vertrauen entsteht vor allem dann, wenn man sich gehört und wertgeschätzt fühlt. Wenn man merkt, dass das Gegenüber die eigenen Anliegen ernst nimmt und sich auch ernsthaft bemüht, Verbesserungen vorzunehmen, zu unterstützen und zu helfen.

Deswegen sage ich jeder neuen Mitarbeiterin und jedem neuen Mitarbeiter am ersten Tag, dass sie oder er alles, was merkwürdig, ineffizient oder unlogisch erscheint, jederzeit offen ansprechen kann. Nur so besteht die Chance, dass Dinge verbessert werden, die bislang vielleicht niemandem aufgefallen sind oder die niemand hinterfragt hat. Natürlich kann es sein, dass einer neuen Mitarbeiterin oder einem neuen Mitarbeiter etwas auffällt, das einen nicht sofort ersichtlichen tieferen Sinn hat. Aber auch das ist nicht schlimm: Wird es angesprochen, gibt es im Zweifelsfall eine gute Erklärung, warum die Dinge so sind, wie sie sind. Es gibt also entweder einen Lerneffekt (was gut ist) oder es führt zu einer Verbesserung (was ebenfalls gut ist).

Und das gilt nicht nur für technische und organisatorische Prozesse, sondern auch für alles andere. Ich möchte, dass meine Kolleginnen und Kollegen jederzeit zu mir kommen und sagen können:

"Hey Golo, mich bedrückt etwas."

oder:

"Mich beschäftigt etwas."

Natürlich mache auch ich Fehler, aber ich bemühe mich zumindest stets, auf solche Anliegen einzugehen, einen Rat zu geben oder etwas zu verändern. Außerdem frage ich oft auch von mir aus nach, wenn ich den Eindruck habe, dass jemand nicht so gut gelaunt ist wie sonst oder ich anderweitig das Gefühl habe, dass etwas nicht stimmt. Ich spreche die Person dann im Einzelgespräch an und frage, ob alles in Ordnung ist. Oft stellt sich heraus, dass alles okay ist, manchmal jedoch entsteht ein wertvolles Gespräch. Für mich ist es wichtig, auf Augenhöhe und mit Respekt miteinander umzugehen, denn das schafft eine vertrauensvolle Atmosphäre. Und das ist etwas, was wir bei the native web meiner Meinung nach ganz gut hinbekommen.

Selbstdisziplin und Eigenverantwortung

Allerdings reicht Vertrauen allein nicht aus, damit Remote-Arbeit gut funktioniert. Es braucht noch etwas anderes. Und das habe ich vorhin schon kurz erwähnt, als ich über die Vor- und Nachteile des Homeoffice gesprochen habe, nämlich Selbstdisziplin und Eigenverantwortung. Gerade weil die physische Komponente im Homeoffice fehlt, ist es wichtig, dass man sich selbst organisiert und Verantwortung übernimmt.

Wenn ich zum Beispiel an einem Problem festhänge, kann ich nicht einfach zur Kollegin oder zum Kollegen am Nachbartisch gehen und um Hilfe bitten. Ich bin erst einmal auf mich allein gestellt. Natürlich kann ich versuchen, jemanden zu erreichen, aber je nachdem, womit die anderen gerade beschäftigt sind, klappt das nicht immer sofort. Dann darf ich mich jedoch nicht einfach zurücklehnen und stundenlang nichts tun, sondern muss konstruktiv nach einer Lösung suchen. Als Vorgesetzter ist mir persönlich dabei aber gar nicht so wichtig, ob die Lösung am Ende klappt. Mir ist vielmehr die Initiative wichtig. Es ist völlig in Ordnung, wenn mir dann jemand sagt:

"Ich habe dies und das und jenes ausprobiert, aber es hat aus diesen und jenen Gründen nicht funktioniert."

Dann weiß ich nämlich: Die Person hat sich bemüht. Und das zeigt mir, dass mein Gegenüber die Arbeit ernst nimmt, auch wenn es in dieser Situation vielleicht einfacher gewesen wäre, nichts zu tun. Und das wiederum weiß ich zu schätzen.

Insofern ist das mit dem Vertrauen eine gegenseitige Angelegenheit: Meine Kolleginnen und Kollegen müssen mir vertrauen können und ich muss ihnen vertrauen können. Das ist jedoch der Punkt, der in vielen Unternehmen fehlt: gegenseitiges Vertrauen, das auf Respekt, Menschlichkeit und auf einem Umgang auf Augenhöhe basiert. Wenn dieses Vertrauen aber gegeben ist, dann spielt es keine Rolle, ob man remote oder vor Ort arbeitet. Wenn es jedoch fehlt, dann hilft es auch nicht, die Leute zurück ins Büro zu zwingen. Dann liegt das Problem viel tiefer, denn die Teamzusammenstellung oder die Arbeitskultur passt irgendwo nicht.

Management als Entenmama

Dieses Vertrauen und dieser gegenseitige Respekt sind die Basis für so vieles im Unternehmensalltag. Ein Beispiel: Wir bei the native web kommunizieren viel schriftlich über Slack (also asynchron). Und es kommt vor, dass ich am Wochenende oder mitten in der Nacht eine Idee habe und diese in Slack schreibe. Nun gilt aber: Nur weil ich am Wochenende schreibe, erwarte ich von meinen Kolleginnen und Kollegen keine sofortige Antwort. Es ist völlig in Ordnung, wenn ich erst am Montagmorgen eine Antwort bekomme. Nichts ist jemals so dringend, dass ich jemanden am Feierabend, am Wochenende oder gar im Urlaub stören würde. Und das Interessante dabei: Gerade weil wir diese Grenzen respektieren, bekomme ich oft sogar am Wochenende oder abends noch eine Antwort, obwohl ich explizit geschrieben habe, dass es nicht eilig ist. Das Paradoxe ist also: Weil ich nichts fordere, wird viel eher gegeben. Und das schätze ich sehr.

Der Punkt ist aber: Mir ist jedes Mal, wenn ich dann doch schon vor Montagmorgen eine Antwort bekomme, klar, dass das keine Selbstverständlichkeit ist, dass das etwas Besonderes ist, das ich wertzuschätzen weiß und wofür ich dankbar bin. Und das äußere ich dann auch. Denn mir ist wichtig, das zu respektieren. Und eigentlich sollte all das überhaupt nicht erwähnenswert sein, aber leider sieht die Praxis in vielen Unternehmen anders aus.

Meine Rolle als Vorgesetzter sehe ich dabei nicht darin, das Team anzuführen, wie das in vielen Unternehmen der Fall ist. Ich sehe meine Aufgabe eher darin, das Team zu schützen und auf mein Team aufzupassen. Ich bin also weniger der Löwe, der mit Gebrüll vorneweg rennt und einen auf "Big Boss" macht, sondern vielmehr bin ich die Entenmama, die aufpasst, dass keinem ihrer Küken etwas passiert. "Fürsorge" ist, denke ich, hier das passende Wort. Es ist vielleicht nicht die verbreitetste Art von Management, aber es ist zumindest meine.

Und aus genau dieser Perspektive heraus hatten wir übrigens auch sehr lange keine Zeiterfassung. Wir haben immer mit Vertrauensarbeitszeit gearbeitet, und bei uns hat noch niemals jemand Überstunden gemacht. Das ist in zwölf Jahren noch kein einziges Mal vorgekommen. Natürlich kommt es vor, dass man mal ein oder zwei Stunden länger macht, weil man noch etwas fertigstellen möchte, aber: Ich sehe das eher wie eine Einladung zum Essen unter Freunden. Mal zahlt der eine, mal der andere, aber am Ende gleicht sich das aus. Genauso deshalb ist es auch völlig in Ordnung, wenn jemand mal früher Schluss macht. Es wird auch wieder Tage geben, an denen es länger dauert, und solange sich das ausgleicht, und beide Seiten fair miteinander umgehen, ist das okay.

Deshalb bin ich auch kein Freund des EuGH-Urteils zur verpflichtenden Zeiterfassung, weil es die Falschen trifft: Unternehmen wie wir, die schon vorher freiwillig darauf geachtet haben, dass niemand zu viel arbeitet, müssen sich nun mit zusätzlicher Bürokratie herumschlagen. Diejenigen, die ihre Mitarbeitenden knechten und ausbeuten wollen, werden trotzdem Mittel und Wege finden, das auch weiterhin zu tun. Aber sich aufzuregen, bringt an der Stelle leider nichts.

Zum Thema Tools und Werkzeuge

Nun habe ich Slack bereits mehrfach erwähnt. Es ist für uns das wichtigste Kommunikationsmittel, weil wir darüber schreiben, telefonieren und Videokonferenzen abhalten können. Aber das Wichtigste ist nicht das Tool an sich, sondern die Asynchronität. So kann jeder konzentriert arbeiten und wird nicht ständig unterbrochen. Aber ohne Selbstdisziplin und Eigenverantwortung von allen Beteiligten funktioniert asynchrone Kommunikation nicht.

Wir bei the native web sind ein Beispiel dafür, wie Homeoffice als dauerhaftes Modell gut funktionieren kann. Das Entscheidende dabei ist nicht, dass wir gerade Slack verwenden oder dass wir eine elektronische Zeiterfassung nutzen. Das Wichtige ist, dass es uns seit zwölf Jahren gelingt, die richtigen Menschen zusammenzubringen und eine vertrauensvolle Zusammenarbeit zu schaffen. Und das ist meiner Meinung nach der eigentliche Schlüssel, den man braucht, damit Homeoffice im großen Stil funktionieren kann. Denn wenn dieses Vertrauen nicht gegeben ist, dann wird es schwierig, und zwar völlig unabhängig davon, ob man remote oder vor Ort arbeitet.

Wenn Sie mich nun fragen, wie die Zukunft der Remote-Arbeit in der IT-Branche aussieht, muss ich ehrlich sagen: Ich weiß es nicht. Einerseits sehe ich großes Potenzial, das Ganze noch viel weiter auszubauen. Andererseits bin ich mir unsicher, ob allzu viele Unternehmen bereit sein werden, diesen Weg zu gehen und ein Stück ihrer (vermeintlichen) Kontrolle abzugeben. Vertrauen ist etwas, das aktiv gepflegt werden muss. Es passiert nicht einfach so. Man muss die richtigen Menschen zusammenbringen, die entsprechende Kultur etablieren und selbst mit gutem Beispiel vorangehen. Was die Politik sich dazu ausdenkt oder welche Technologien morgen in Mode sind, spielt dabei letztlich keine Rolle. Es ist am Ende immer eine Frage der Menschen. Deshalb weiß ich auch nicht, wie sich die Branche als Ganzes entwickeln wird, weil es keine Frage der Branche ist, sondern eine Frage, die jedes Team für sich selbst beantworten muss.

URL dieses Artikels:
https://www.heise.de/-9868729

Links in diesem Artikel:
[1] https://www.thenativeweb.io/
[2] https://www.youtube.com/live/sORcUbCOnBw
[3] https://www.heise.de/Datenschutzerklaerung-der-Heise-Medien-GmbH-Co-KG-4860.html
[4] https://www.heise.de/news/Elon-Musk-an-seine-Tesla-Fuehrungskraefte-Schluss-mit-Homeoffice-oder-Kuendigung-7129308.html
[5] mailto:rme@ix.de

Copyright © 2024 Heise Medien

Adblock test (Why?)

CrowView Note – ein "Notebook" nicht nur für SBC-Entwickler

Es schaut aus wie ein Notebook, besitzt aber keine CPU. Das CrowView Note benutzt stattdessen SBCs wie Raspberry Pi, Nvidia Jetson Nano als Schaltzentrale.

Wer den Tastatur-PC Raspberry Pi 400 [1] erworben hat, muss selbst für einen Bildschirm und eine Maus sorgen. Das Produkt bietet eine Tastatur mit integriertem Raspberry Pi 4 und Anschlussmöglichkeiten für eine Maus und einen Bildschirm. Sollte bald ein Raspberry Pi 500 erscheinen, dürfte es sich bezüglich seiner Spezifikation ähnlich wie der Vorgänger präsentieren.

Elecrow erweitert das Konzept des Raspberry Pi 400 um einen Bildschirm und ein Trackpad. Das Produkt CrowView Note kommt als Notebook mit Bildschirm und Tastatur inklusive Touchpad, aber ohne eigenen Prozessor daher. Zu diesem Zweck dient stattdessen ein über eine Brücke anschließbarer Raspberry Pi oder Nvidia Jetson Nano. Die Aufgaben des Mainboards übernehmen also SBCs (Single Board Computers). Man kann auch ältere Raspberry Pis anschließen, etwa über Kabel. Ob sich weitere SBCs mit dem Notebook vertragen, habe ich nicht getestet. Die Chance dafür dürfte hoch sein. Escrow gibt jedenfalls an, folgende Hardware zu unterstützen:

• Raspberry Pi 5, 4B, 3B, 3B+, Zero
• Rock Pi
• Beaglebone
• LattePanda V1
• Nvidia Jetson Nano
• Orange Pi 4B
• Banana Pi M5

Aktuell läuft eine Kickstarter-Kampagne zum CrowView Note [2], später kommt das Gerät in den regulären Handel.

Über eine Brücke musst du gehen

Möglicherweise bringt der Hersteller auch noch weitere Bridges (kleine Boards zum Anschluss von SBCs) auf den Markt, sollten viele Kunden das wünschen. Die Bridges beziehungsweise Adapterboards für Raspberry Pi werden in die linke Seite und in die Frontseite des CrowView Note eingesteckt und erlauben den bequemen Anschluss des jeweiligen SBC ganz ohne Kabel. Möglich ist auch die Verbindung eines Smartphones oder Tablets mit dem CrowView Note. Darüber hinaus kann das Gerät als externer 14-Zoll-Monitor für Geräte jeder Art über ein Mini-HDMI-Kabel oder USB-C-Kabel fungieren. Wer die Bridge – zwei kleine Boards – für den Raspberry Pi 4 oder 5 mit einem Gehäuse einsetzen möchte, muss darauf achten, dass das Gehäuse Zugriff auf die vorderen und linken Anschlüsse gewährleistet. Sollte dies nicht der Fall sein, kann man eins der vielen Gehäusemodelle für 3D-Drucker entsprechend modifizieren. Die Bridges sind übrigens nicht im Lieferumfang enthalten, sondern separat erhältlich. Pro Board beziehungsweise Brücke verlangt der Hersteller einen Obolus von 5 Euro.

Zusätzlich lässt sich das Quasi-Notebook mit diversen Spielekonsolen kombinieren.

Natürlich ist das CrowView Note nicht die einzige Alternative, um mit SBCs zu arbeiten.

• Alternativ lässt sich auch remote auf Boards zugreifen (zum Beispiel über ssh), um so mit Host/Target-Entwicklung zu arbeiten, aber dadurch sinkt in der Regel die Produktivität.
• Andererseits könnten Nutzer KVM-Switches einsetzen, damit mehrere SBCs und Computer sich Bildschirm, Tastatur und Maus teilen, was sich aber eher für stationäre Installationen eignet. Zusätzlich gewünschte Mobilität erfordert in diesem Fall das Mitnehmen von externem Bildschirm, Tastatur und Maus.
• Der SBC lässt sich auch zum Standalone-Computer aufrüsten. Das kostet allerdings Geld und Platz.

Da das hier vorgestellte Notebook, wie erwähnt, Bildschirm, Tastatur und Trackpad bereits mitbringt, dürfte diese Variante jedoch die bequemste sein – speziell, wenn Mobilität gewünscht ist.

Spezifikation

Das getestete CrowView Note verfügt über einen 14-Zoll-Monitor mit IPS-Panel und Full-HD-Auflösung (1920 × 1080 Pixel). Als abgedeckten Farbraum gibt der Hersteller 100 % sRGB an; als maximale Helligkeit 300 cd/m². Die Bildwiederholrate beträgt 60 Hz, mit Support für variable Refreshraten (VRR). Auf der linken Seite lassen sich die oben erwähnten Bridges für SBCs anschließen, alternativ auch über Kabel oder Adapter. Auf der rechten Seite stehen ein Anschluss für das Netzteil, ein Kopfhörerausgang sowie eine USB-C- und eine USB-A-Schnittstelle zur Verfügung. Eine USB-Schnittstelle unterstützt Power Delivery (PD) für das Aufladen externer Geräte mit 5V/5A. Zudem liefert Elecrow ein 12V/4A-Netzteil mit. Stereo-Lautsprecher sind ebenso wie ein Mikrofon im CrowView Note integriert.

Es existieren also zusammengefasst folgende Schnittstellen:

Links:

• USB 2.0 Typ A
• USB Typ C (nur Stromversorgung, keine Datenverbindung)
• Mini-HDMI-Anschluss

Rechts:

• USB 2.0 Typ A
• USB Typ C (Displayport-Alt-Modus, Stromversorgung)
• Kopfhörereingang
• Netzsteckereingang 3,5 mm, Gleichstrom/DC

Ein eingebauter Akku bietet 5000 mAh Ladekapazität. Ohne eingeschalteten Bildschirm benötigt das Gerät rund zwei Watt, ansonsten acht Watt Leistung. Die Arbeitszeit hängt natürlich vom Leistungsbedarf des verwendeten SBC ab; bei einem Raspberry Pi 5 sind es bis zu drei Stunden. Wer das Gerät lediglich als externen Monitor nutzt, dürfte mit einer Batterieladung bei einer Laufzeit um 5 Stunden landen. Als positiv empfand ich das geringe Gewicht (1147 g) und die angenehme Größe des CrowView (33,4 cm × 22,2 cm × 1,75 cm), womit man es leicht transportieren kann. Das CrowView Note lässt sich bis zu 180 Grad aufklappen.

Dass das CrowView Note überwiegend aus Kunststoff gefertigt ist, wirkt sich auf die Qualität des Gehäuses nur marginal aus. Es macht einen recht robusten Eindruck. Anders ausgedrückt: Es tut, was es soll.

Neben den offensichtlichen Einsatzgebieten wie Office, Gaming und Entertainment bietet sich auch der Einsatz für Programmierung an, nicht nur für Embedded-Software. Wer Audio hören und seine Umwelt beschallen möchte, kann dies über die zwei eingebauten Stereo-Lautsprecher tun. Natürlich lässt sich davon kein Klang erwarten, der einem hochpreisigen Hi-Fi-System Konkurrenz machen kann. Speziell die schwachen Bässe fallen auf. Als externes Display lässt sich das Produkt genauso nutzen wie als Standalone-Gerät für SBCs.

Bedienung

Der Bildschirm ist matt und lässt sich gut zum Arbeiten verwenden. Bei sehr hellem Tageslicht kommt er zwar an seine Grenzen, leichtet aber im Regelfall ausreichend hell. Die Tastatur ist aus meiner subjektiven Perspektive gut bedienbar. Zum Anschluss von Endgeräten oder SBCs an das Notebook kann man Mini-HDMI oder einen USB-C-Eingang nutzen.

Das Trackpad des Review-Modells ließ wegen fehlenden Druckpunkts kein Drag-and-Drop oder das Scrollen von Bildschirminhalten zu. Laut Aussage des Herstellers sei dies lediglich ein Problem des Vorserien-Prototyps, das bei den ausgelieferten Geräten nicht mehr auftreten soll.

Ein kleiner Hinweis in Sachen Tastatur: Auf dem getesteten Vorserien-Testgerät befindet sich eine US-Tastatur. Die hilfsbereite Mitarbeiterin Annie Xie von Escrow hat während des Tests mitgeteilt, dass Elcrow das Gerät künftig auch mit deutscher Tastatur ausliefern will.

Wer auf das OSD (On-Screen-Display) zugreifen will, um Display-Einstellungen anzupassen, kann dies über Funktionstasten bewerkstelligen. Eine dieser Funktionstasten erlaubt das Umschalten zwischen verschiedenen Geräten. Das ist zum Beispiel wichtig, wenn ein SBC über Mini-HDMI angeschlossen ist und ein weiteres externes Gerät wie ein Smartphone über USB-C/DP (DisplayPort). Insofern verhält sich das CrowView Note wie ein KVM-Switch.

Softwareentwicklung mit und für SBCs

Entwickler von Embedded-Software oder auch anderer Anwendungen für SBCs wie dem Raspberry Pi profitieren vom CrowView Note. Das ist nicht nur dessen Mobilität geschuldet, sondern auch der Tatsache, dass dieses Gerät es auf bequeme Art ermöglicht, diverse SBCs anzuschließen und damit zu experimentieren. Beim Entwickeln, Testen und Debuggen erweist es sich als Vorteil, direkt mit Entwicklungs- und Testwerkzeugen über grafische Bedienoberflächen auf dem SBC arbeiten zu können, zum Beispiel mit Visual Studio Code und den Add-ons PlatformIO oder TinyGo.

Für das mobile Arbeiten mit dem CrowView Note dient einfach ein Smartphone, Tablet oder anderes mobiles Gerät als WLAN-Access-Point für den Netzwerkzugriff. Wer den Raspberry Pi 400 zu schätzen gelernt hat, dürfte sich leicht mit dem CrowView Note anfreunden, zumal dieser zusätzlich Bildschirm und Trackpad mitbringt. Bis auf den SBC und die Bridge bedarf es keinerlei weiterer Hardware. Insgesamt lassen sich alle benötigten Gerätschaften leicht verstauen und transportieren.

Fazit

Das Produkt CrowView Note ist ein sehr preisgünstiges Gerät, das SBC-Nutzern mit Mobilitätsanforderungen eine geeignete Lösung verschafft, sich aber auch gut für den stationären Betrieb eignet. Die Idee, ein Notebookgehäuse inklusive Tastatur, Monitor und Maus mit einem SBC zu kombinieren, ist innovativ und bietet einige Vorteile, die das CrowView Note gut ausspielen kann. Der anvisierte Verkaufspreis von etwa 169 Euro ist auf jeden Fall gerechtfertigt.

Wer das Gerät erwerben möchte, kann dafür die noch laufende Kickstarter-Kampagne [3] nutzen. Der Preis beträgt 118 Euro (Early Bird) beziehungsweise 127 Euro (KickStarter-Preis). Nach Ende der Kampagne schlägt das Produkt mit rund 40 Euro mehr zu Buche (169 USD / Euro).

URL dieses Artikels:
https://www.heise.de/-9861699

Links in diesem Artikel:
[1] https://www.heise.de/tests/Raspberry-Pi-400-im-Test-Kleiner-Computer-fuer-Einsteiger-und-Bastler-4967904.html
[2] https://www.kickstarter.com/projects/elecrow/crowview-note-empowering-your-device-as-a-laptop/description
[3] https://www.kickstarter.com/projects/elecrow/crowview-note-empowering-your-device-as-a-laptop?lang=de
[4] mailto:rme@ix.de

Copyright © 2024 Heise Medien

Adblock test (Why?)

Neu in .NET 8.0 [38]: Containerdateien per dotnet publish erstellen

Es ist nun möglich, .NET-Anwendungen in eine Containerdatei zu veröffentlichen – ohne Dockerfile und ohne Bereitstellung in Docker.

Seit .NET 7.0 kann man bereits mit dotnet publish einen Docker-Container erstellen, ohne dass man dafür zuvor ein Dockerfile (eine zusätzliche Textdatei) bereitstellen muss.

Ein mit .NET 7.0 per Option PublishProfile=DefaultContainer erstellter Docker-Container wurde automatisch in Docker als aktiver Container bereitgestellt.

In .NET 8.0 gibt dazu noch eine Zusatzoption: -ContainerArchiveOutputPath. Diese erlaubt es, eine Container-Datei (tar.gz) zu erstellen, ohne sie direkt als aktiven Container bereitzustellen:

dotnet publish -p PublishProfile=DefaultContainer\
 -p ContainerArchiveOutputPath=t:\meinblazorimage.tar.gz\
 -p:ContainerBaseImage=mcr.microsoft.com/dotnet/aspnet:8.0-alpine

Folgender Code zeigt das komplette Beispiel:

function New-TempDirectory {
    $parent = [System.IO.Path]::GetTempPath()
    [string] $name = [System.Guid]::NewGuid()
    New-Item -ItemType Directory -Path (Join-Path $parent $name)
}
 
docker --version
 
# Tempordner erzeugen und dahin wechseln
New-TempDirectory | cd
 
# Projekt anlegen (hier: Blazor SSR)
dotnet new blazor -n BlazorImContainer
 
# In den Ordner wechseln
cd .\BlazorImContainer\
 
#region Programmcode in Startseite austauschen mit Informationen über Umgebung, .NET- und OS-Version sowie Prozess
$indexpage = @'
@page "/"
<PageTitle>Index</PageTitle>
<h1>Liebe Leser*innen,</h1>
<p>diese Blazor Web App (Blazor Static SSR) läuft  
@if (System.Environment.GetEnvironmentVariable("DOTNET_RUNNING_IN_CONTAINER")=="true")
{ <text><b>im Container </b></text> }
else
{ <text>nicht im Container </text> }!</p>
<p>
.NET-Version: @System.Runtime.InteropServices.RuntimeInformation.FrameworkDescription<br>
Betriebssystem: @System.Runtime.InteropServices.RuntimeInformation.OSDescription<br>
Prozess: @System.Diagnostics.Process.GetCurrentProcess().ProcessName<br>
Prozessidentität: @System.Environment.UserDomainName\@System.Environment.UserName<br>
IsPrivilegedProcess: @System.Environment.IsPrivilegedProcess</p>
<hr>
Umgebungsvariablen:
<ul>
@foreach(System.Collections.DictionaryEntry e in System.Environment.GetEnvironmentVariables())
{
   <li>@e.Key: @e.Value</li>
}
</ul>
'@
$indexpage | Set-Content "components/pages/home.razor"
#endregion
 
# Container-Build-Paket hinzufügen (neu seit .NET 7.0, wird nicht mehr explizit gebraucht in .NET 8.0!!!)
#dotnet add package Microsoft.NET.Build.Containers --prerelease
 
# Veröffentlichen als Containerdatei (neu seit .NET 8.0)
dotnet publish -p PublishProfile=DefaultContainer -p ContainerArchiveOutputPath=t:\meinblazorimage.tar.gz -p:ContainerBaseImage=mcr.microsoft.com/dotnet/aspnet:8.0-alpine
# dann irgendwann: Laden in Docker
docker load --input t:\meinblazorimage.tar.gz
 
# Das ging schon in .NET 7.0
# Veröffentlichen als Container, alle MSBuild-Properties nach PublishProfile=DefaultContainer sind optional
#dotnet publish --os linux --arch x64 -c Release -p:PublishProfile=DefaultContainer -p:ContainerImageName=meinblazorimage #-p:ContainerBaseImage=mcr.microsoft.com/dotnet/aspnet:7.0-alpine
 
# Start des Containers (in getrennten Prozess, weil sonst dieser hier blockiert ist)
Start-Process powershell { docker run -it --rm -p 5000:8080 blazorimcontainer }
 
# optionaler Aufruf des Browsers zur Kontrolle
Start-Process "http://localhost:5000"

URL dieses Artikels:
https://www.heise.de/-9867463

Links in diesem Artikel:
[1] https://net.bettercode.eu/?wt_mc=intern.academy.dpunkt.konf_dpunkt_bcc_net.empfehlung-ho.link.link
[2] https://net.bettercode.eu/index.php?wt_mc=intern.academy.dpunkt.konf_dpunkt_bcc_net.empfehlung-ho.link.link#programm
[3] https://net.bettercode.eu/tickets.php?wt_mc=intern.academy.dpunkt.konf_dpunkt_bcc_net.empfehlung-ho.link.link
[4] mailto:rme@ix.de

Copyright © 2024 Heise Medien

Adblock test (Why?)

Nur Mut! – Endlich raus aus der Scrum-Hölle

Viele Entwicklerinnen und Entwickler leiden unter Scrum, doch kaum jemand wehrt sich gegen dessen Einsatz im Unternehmen. Woran liegt das?

Vor zwei Wochen habe ich einen Blogpost veröffentlicht, der die Frage behandelte, warum niemand mehr agil arbeiten möchte [1]. Und was soll ich sagen: Der Blogpost hat anscheinend einen Nerv getroffen. Das zugehörige Video auf YouTube [2] erreichte innerhalb der ersten 24 Stunden fast 19.000 Aufrufe. Das ist gut und gerne das fünf- bis zehnfache dessen, was wir normalerweise erwarten. Anders als sonst nahmen die Aufrufe am zweiten Tag nicht ab – im Gegenteil, sie stiegen weiter an. Inzwischen sind wir bei über 80.000 Aufrufen, und wenn wir in ein paar Tagen wieder nachsehen, werden wir voraussichtlich die Marke von 100.000 Aufrufen überschritten haben. Doch das ist noch nicht alles: Wir haben für das Video auch über 2.000 Likes und mehr als 400 Kommentare erhalten.

Auch der eingangs erwähnte Blogpost kann sich sehen lassen, mit inzwischen mehr als 600 Kommentaren. Kurz gesagt: Wir sind überwältigt. Damit hätten weder meine Kolleginnen und Kollegen noch ich selbst bei diesem Thema gerechnet, zumal es nicht das erste Mal war, dass wir Scrum & Co. kritisiert haben. Die Resonanz war dieses Mal jedoch einfach gigantisch, und dafür möchte ich mich als allererstes ganz herzlich bedanken!

Eine Woche Pause für 1.000 Kommentare

Wir haben uns überlegt, dass es aufgrund des hohen Anklangs sinnvoll wäre, noch einen zweiten Teil des Blogposts zu schreiben. Dafür war es uns aber wichtig, alle Kommentare (also insgesamt über 1.000 Stück) zu lesen, um ein umfassendes Bild aller Meinungen zu erhalten. Irgendwann habe ich dann auch aufgehört, auf die Kommentare zu antworten, das war zeitlich einfach nicht mehr machbar, aber ich habe sie zumindest tatsächlich alle gelesen. Das ist auch der Grund, warum vergangene Woche kein Blogpost und kein Video veröffentlicht wurden: Wir waren einfach noch nicht so weit, und es kamen täglich jede Menge weitere Kommentare hinzu, sodass wir uns entschieden haben, noch eine Woche abzuwarten. Heute, rund zwei Wochen später, ist es nun aber so weit, und hier ist nun der besagte zweite Teil.

Wenn man sich diese über 1.000 Kommentare anschaut, fällt auf, dass die meisten in eine bestimmte Richtung gehen. Die Mehrheit der Kommentare stammt von Entwicklerinnen und Entwicklern, die beklagen, dass Scrum vom Management zweckentfremdet wird, um mehr Kontrolle auszuüben. Scrum wird also nicht so eingesetzt, dass sich ein Team damit selbst organisiert, wie es bei agilen Methoden eigentlich vorgesehen ist, sondern es wird als Projektmanagement-Werkzeug verwendet, dem alles andere untergeordnet wird.

Statt "Individuals and Interactions over Processes and Tools [4]" (wie es im agilen Manifest formuliert ist) passiert genau das Gegenteil: Scrum dominiert als Prozess alles. Dadurch wird Agilität im Keim erstickt, weil sie offensichtlich nicht gewünscht ist. Die traurige Wahrheit ist, dass in vielen Unternehmen nicht einmal Fake Agile vorherrscht, sondern eine schlimmere Variante: Dark Agile. Dabei geht es nur darum, auf dem Papier gut auszusehen, während Scrum in Wirklichkeit als Kontroll- und Steuerungsinstrument missbraucht wird. Genau das habe ich im letzten Blogpost als die schlimmste Variante beschrieben, wie man Agilität falsch leben kann.

Scrum ist (k)ein Problem

Auffällig war auch, dass sich praktisch alle Beschwerden auf Scrum bezogen haben. Kaum jemand kritisierte Extreme Programming (XP) oder Kanban. Es ging immer nur um Scrum. Das führt uns zu dem, was ich im letzten Blogpost als den "agil-industriellen Komplex" bezeichnet habe, nämlich die Geldmacherei mit Zertifikaten und dergleichen. Nur sieht das Ganze in der Realität offenbar noch schlimmer aus, als ich es auf Basis meiner eigenen Erfahrung angenommen habe.

Fairerweise muss man jedoch sagen, dass Scrum oft nicht das eigentliche Problem ist. Viele Kommentatoren wiesen darauf hin, dass die Ursache tiefer liegt, nämlich bei einem Management, das ohne Realitätsbezug agiert und dem Kunden das Blaue vom Himmel verspricht, um mehr Umsatz und Gewinn zu machen. Dass dafür ausgerechnet Scrum herangezogen wird, verwundert wenig: Mit XP würde das nämlich nicht funktionieren, weil XP sich nicht um den organisatorischen Rahmen kümmert, sondern um den Entwicklungsalltag. XP bietet konkrete Best Practices, um Qualität und Effizienz zu steigern.

Deswegen finde ich persönlich XP auch weitaus sympathischer als Scrum: Es ist konkret, praxisorientiert und nicht so ein Pseudo-Blabla für Möchtegern-Manager. Dennoch kann man Scrum nur bedingt die Schuld geben. Denn wenn das Management keine Kontrolle abgeben will, wird es mit jeder Methode schwierig, positive Veränderungen herbeizuführen. Mit Scrum lässt sich das nur eben besonders gut verschleiern.

Viel Leid, aber kaum Gegenwehr

Etwas anderes ist uns aber auch noch aufgefallen: Viele Entwicklerinnen und Entwickler klagen über ihre Situation, aber kaum jemand unternimmt etwas dagegen. Wenn man genauer hinschaut, merkt man jedoch rasch, dass viele schlicht aufgegeben haben. Der Mut und die Kraft, sich gegen das Management oder die Prozesse zu wehren, sind einfach nicht mehr vorhanden.

Das finde ich persönlich sehr traurig. Softwareentwicklung kann so ein kreatives und schönes Feld sein, aber wenn das durch Kontrollsucht und Gier kaputt gemacht wird, ist das wirklich schlimm. Aber genau darüber müssen wir heute einmal sprechen: Was können Sie machen, wenn Ihnen auffällt, dass in Ihrem Unternehmen etwas schiefläuft, weil Scrum zwar auf dem Papier verwendet wird, sich aber alles nach dem genauen Gegenteil von Agilität anfühlt?

Bevor Sie jetzt sagen

"Das hat doch alles keinen Sinn, es ändert sich ohnehin nichts!"

lassen Sie mich eins sagen: Natürlich kann ich Ihnen nicht garantieren, dass sich etwas ändern wird, wenn Sie versuchen, das Thema anzugehen. Aber ich kann Ihnen mit Gewissheit sagen, dass sich rein gar nichts ändern wird, wenn Sie es nicht zumindest versuchen. Anders gesagt: Wenn Sie den Kopf in den Sand stecken, haben Sie schon verloren, bevor das Rennen überhaupt begonnen hat.

Zum Thema Management

Ich kann nachvollziehen, dass es oft leichter ist, den Mund zu halten, insbesondere wenn Sie denken, dass Ihre Geschäftsführerin oder Ihr Geschäftsführer entgegengesetzter Meinung ist. Aber es gibt einen wichtigen Punkt: Nicht jeder Manager oder jede Managerin ist gleich. Sicherlich setzen manche Scrum durchaus bewusst so ein, wie es in den Kommentaren beschrieben wurde, aber andere wissen vielleicht gar nicht, dass es besser laufen könnte, oder ahnen nicht, wie unzufrieden Sie und Ihre Kolleginnen und Kollegen sind. Das werden Sie nur herausfinden, wenn Sie es versuchen.

Und übrigens: Auch ich bin Geschäftsführer und Manager, aber wir bei the native web [5] machen trotzdem kein Scrum. Tatsächlich bin ich sogar derjenige bei uns, der sich mit Abstand am stärksten dagegen wehrt. Anstelle von Scrum haben wir einen eigenen agilen Prozess entwickelt, der für uns gut funktioniert und sehr anders abläuft als Scrum, aber dennoch auf den Prinzipien des agilen Manifests basiert.

Es ist dabei aber wichtig zu verstehen, dass nicht jeder Prozess automatisch zu jedem Team passt. Der richtige Prozess hängt immer von den jeweiligen Umständen ab, und was heute sinnvoll ist, kann übermorgen schon nicht mehr passend sein. Deshalb sollte man den Status quo regelmäßig hinterfragen. Das ist daher übrigens auch eine der ersten Sachen, die ich neuen Kolleginnen und Kollegen bei uns sage:

"Wenn dir bei uns etwas auffällt, sprich das bitte sofort offen und ehrlich an. Entweder gibt es eine gute Begründung, warum wir etwas so handhaben, oder wir überlegen, ob wir etwas ändern sollten."

Denn, ganz im Sinn des agilen Manifests: Prozesse und Werkzeuge sollen die Menschen unterstützen, nicht umgekehrt. Deshalb stelle ich unseren Prozess auch nicht als Allheilmittel dar – denn er funktioniert für uns, aber das heißt nicht, dass er für Sie und Ihr Team genauso gut passt. Das hängt einfach zu sehr von den individuellen Anforderungen ab.

Konkrete Schritte ergreifen?

Aber werden wir konkret: Angenommen, Sie sind der Meinung, dass der Prozess in Ihrem Unternehmen ineffizient oder bürokratisch ist, dass er wenig agil ist und Sie aber gerne agil arbeiten würden. Vielleicht haben Sie das Gefühl, dass es oft nur darum geht, dass jemand in der Hierarchie über Ihnen auf dem Laufenden gehalten wird, und die typischen Scrum-Artefakte wie Sprints und Dailys sind verzerrt. Beispielsweise dauern Ihre Sprints zwei Monate, Sie haben mehrere Product Owner, aber keinen Scrum Master, das Daily ist ein klassisches Statusmeeting, und die Retrospektive läuft immer nach dem gleichen Schema ("was läuft gut, was läuft schlecht, was ändern wir") ab. Und dann wird auch noch in Stunden und Minuten geschätzt, statt in Story Points. Falls Ihnen das bekannt vorkommt, habe ich noch eine passende Videoempfehlung [6] für Sie.

Zusammenfassend lässt sich also sagen, dass Sie überzeugt sind, dass sich etwas ändern muss. Die gute Nachricht ist: Sie sind wahrscheinlich nicht allein. Die schlechte: Genauso wie die anderen schweigen Sie höchstwahrscheinlich. Warum? Nun, ganz einfach: Die meisten haben schlicht und ergreifend Angst. Denn obwohl oft gesagt wird, dass man sich den Job in der Entwicklung praktisch aussuchen könne, möchte trotzdem niemand negativ auffallen und deshalb womöglich gar den Job verlieren. Viele geben das nicht gerne zu, aber es ist die Wahrheit: Die meisten haben schlichtweg Angst.

Allerdings ist das kein Grund, sich zu schämen. Angst davor zu haben, aus einer sicheren Gruppe auszubrechen und sich als Einzelkämpfer gegen das System zu stellen, ist völlig normal. Wenig überraschend ging mir das früher genauso. Auch ich wollte nicht derjenige sein, der ständig schlechte Nachrichten überbringt, und auch ich hatte kein Interesse daran, meinen Job zu verlieren. Also habe ich mich (viel zu) oft zurückgehalten.

Was es braucht, ist Mut

Das Problem dabei: All das führt zu einem Dilemma. Denn Sie wissen, dass es richtig wäre, etwas zu sagen, Dinge zu hinterfragen und vielleicht Verbesserungsvorschläge zu machen, aber die Angst hält Sie zurück. Das führt zu Unzufriedenheit, und dann passiert es vielleicht eines Tages, dass eine Kollegin genau das ausspricht, was Sie schon lange stört. Doch anstatt ihr beizuspringen, schweigen Sie – weil Sie nicht negativ auffallen wollen. Und vielleicht verlässt diese Kollegin nach ein paar Monaten das Unternehmen, man weiß nicht so genau, ob freiwillig oder nicht, aber noch Jahre später erinnern Sie sich gut an sie und denken:

"Eigentlich hätte ich damals den Mund aufmachen müssen."

Wie das immer so ist mit dem Wörtchen "eigentlich". Das bedeutet: Sie brauchen Mut. Genauso wie man bei einer heiklen Situation auf der Straße Zivilcourage braucht, braucht man Mut, um das Richtige zu tun. Natürlich kann es sein, dass Ihre Kritik Ihnen so negativ ausgelegt wird, dass Sie Ihren Job verlieren. Aber fragen Sie sich einmal selbst, ob Sie wirklich dauerhaft in einem Unternehmen arbeiten wollen, das Ihre Meinung so wenig wertschätzt und respektiert? Und was ist, wenn Sie tatsächlich nicht die einzige Person sind, die so denkt? Es ist unwahrscheinlich, dass ein Unternehmen ein ganzes Team entlassen würde, nur weil mehrere Mitarbeitende die Prozesse hinterfragen.

Sachlichkeit steht Ihnen gut

Wichtig ist auch, zu versuchen, die Perspektive des Managements zu verstehen. Ich würde nämlich unterstellen, dass viele Managerinnen und Manager ihren Job grundsätzlich gerne gut machen möchten und daher grundsätzlich ein offenes Ohr für Ihr Anliegen haben sollten, wenn es denn richtig formuliert wird. Deshalb sollten Sie signalisieren, dass es Ihnen um eine gemeinsame Verbesserung der Situation geht. Versuchen Sie, das Management nicht zu konfrontieren, sondern nach Lösungen zu suchen, die alle Beteiligten mittragen können. Denn wenn es Ihnen gelingt, sachlich und mit guten Argumenten zu überzeugen, erhöhen sich Ihre Chancen, ernst genommen zu werden.

Sachlichkeit ist dabei das oberste Gebot. Bereiten Sie sich gut vor, haben Sie Argumente und Fakten parat und überlegen Sie, wie Sie möglichen Einwänden begegnen können. Wenn Sie sachlich bleiben, werden Sie als professionell wahrgenommen, und das erhöht die Wahrscheinlichkeit, dass Ihre Vorschläge ernst genommen werden. Besonders hilfreich kann es dabei sein, mit konkreten Zahlen zu argumentieren. Wenn Sie belegen können, wie viel Zeit oder Geld durch ineffiziente Prozesse verloren geht und wie Ihre Vorschläge diese verbessern könnten, wird es schwieriger, Ihre Argumente abzulehnen. Die implizite Annahme ist: Zahlen lügen nicht – und das ist für das Management oft ein entscheidendes Kriterium.

Wählen Sie außerdem auch den richtigen Zeitpunkt, um das Thema anzusprechen. Überraschende, ad-hoc vorgebrachte Kritik wird weniger erfolgreich sein als ein geplantes Gespräch. Vielleicht wäre eine Retrospektive der richtige Ort, um das Thema anzusprechen.

Erfolgsaussichten

Letztlich kann ich Ihnen aber natürlich nicht garantieren, dass Ihre Bemühungen erfolgreich sein werden. Manchmal muss man auch kleine Schritte gehen und sich mit Kompromissen zufriedengeben. Wenn Sie jedoch nichts tun, wird sich – wie anfangs schon erwähnt – garantiert nichts ändern. Resignieren Sie also nicht. Und falls Sie wirklich an den Punkt kommen, wo Sie das Gefühl haben, dass es sich nicht mehr lohnt zu kämpfen, dann bleiben Ihnen immer noch zwei Optionen: Zum einen können Sie dann immer noch versuchen, sich mit der Situation zu arrangieren und das Beste daraus zu machen. Doch wenn auch das nicht klappt, dann bleibt Ihnen letztlich nur noch die Option, das Unternehmen zu verlassen und sich ein Umfeld zu suchen, das besser zu Ihnen passt.

Falls Sie jetzt denken

"Golo, ich hätte mir insgesamt konkretere Tipps gewünscht"

dann verstehe ich das. Aber leider gibt es keine allgemeingültigen Lösungen, weil so viel von den jeweiligen Umständen abhängt. Deshalb lautet meine Hauptbotschaft: Seien Sie mutig! Versuchen Sie, Missstände anzugehen, indem Sie sie offen und ehrlich ansprechen. Suchen Sie sich Gleichgesinnte und versuchen Sie, eine Lösung zu finden, die alle – einschließlich des Managements – mittragen können. Bleiben Sie sachlich und bereiten Sie sich vor. Tun Sie alles in Ihrer Macht Stehende, um einen besseren Prozess zu etablieren.

Das Einzige, was Sie nicht tun sollten, ist, sich nur zu beklagen. Denn das garantiert, dass sich nichts ändern wird.

URL dieses Artikels:
https://www.heise.de/-9860999

Links in diesem Artikel:
[1] https://www.heise.de/blog/Scrum-XP-Co-warum-keiner-mehr-agil-arbeiten-will-9846824.html
[2] https://www.youtube.com/watch?v=iQK620MY_48
[3] https://www.heise.de/Datenschutzerklaerung-der-Heise-Medien-GmbH-Co-KG-4860.html
[4] https://agilemanifesto.org/
[5] https://www.thenativeweb.io/
[6] https://www.youtube.com/watch?v=CdnP30NEKqk
[7] mailto:who@heise.de

Copyright © 2024 Heise Medien

Adblock test (Why?)

Entwickler-Community-Konferenz am 27. und 28.09.2024 in Essen

Die iterate=>RUHR ist eine zweitägige Community-Konferenz mit Vorträgen zu .NET, KI, agilen Arbeitsweisen, Softwarearchitektur und -qualität.

Die iterate=>RUHR [1] ist eine zweitägige, vom Just Community e.V. veranstaltete Entwicklerkonferenz in Essen mit ehrenamtlichen Vorträgen zu .NET, KI, agilen Arbeitsweisen, Softwarearchitektur und -qualität. Die Konferenz richtet sich an .NET-Entwicklerinnen und -Entwickler sowie Personen, die interessiert sind an sauberem Code, effizientem Arbeiten und modernen Methoden.

Eine Anmeldung [2] ist jeweils gesondert für die Workshops (ab 149 Euro) und die Konferenz (ab 69 Euro) möglich, oder preisgünstig als Kombi-Buchung (ab 199 Euro). Mit dem Rabattcode ITR-ITV-10-P erhalten interessierte Blogleserinnen und -leser 10 Prozent Nachlass auf das Ticket.

Das Programm:

Freitag, 27.09.2024, gibt es Workshops [3] zu folgenden Themen:

• Azure OpenAI für .NET Entwickler
• Mit Flow Design flüssig zu Clean Code
• Softwarearchitektur
• Zwiebeln schälen – Onion, Hexagonal und andere Pattern

Samstag, 28.09.2024, Konferenztag mit deutschlandweit bekannten Sprechern [4] zu folgenden Themen [5]:

• KI-nderzimmer-Nostalgie: Menschliche Sprache, LLMs – und der 42 Jahre alte C64
• Das Beste in .NET 9.0 und C# 13.0
• AI Everywhere
• Fakt vs. Meinung: Wie man am besten Software entwickelt?
• gRPC: Contract First mit High Speed
• Einstieg ins Prompt Engineering für Devs: Dein Kickstart mit ChatGPT, OpenAI & GitHub Copilot
• Mehr Flow durch Mob-Programming
• Deep Dive: Entity Framework Core-Performance
• IODA Architektur: Viel zu lernen du noch hast
• .NET-Anwendungen richtig konfigurieren
• Microsoft Semantic Kernel: Entwicklung eigener KI-Agenten mit C#
• Software Design: Patterns, Principles and More
• OpenTelemetry: Monitoring next Level
• Azure Messaging Services: Eine Anleitung zur effektiven Nutzung von Azure Messaging Services
• Wer viel misst, misst Mist! Scrum, Kanban und die lieben Metriken

Weitere Informationen zur Konferenz finden sich auf der iterate=>RUHR [6]-Website und das Anmeldungsformular ist unter it-visions.de [7] verfügbar.

URL dieses Artikels:
https://www.heise.de/-9861829

Links in diesem Artikel:
[1] https://iterate.ruhr/
[2] https://it-visions.de/Apps/IterateRuhr/Anmeldung
[3] https://iterate.ruhr/workshops/
[4] https://iterate.ruhr/speaker/
[5] https://iterate.ruhr/sessions/
[6] https://iterate.ruhr/
[7] https://it-visions.de/Apps/IterateRuhr/Anmeldung
[8] mailto:map@ix.de

Copyright © 2024 Heise Medien

Adblock test (Why?)

FreshRSS 1.24.3

• Milestone

This is a quality-focussed release for the 1.24.x series meant to provide a good product to people blocked on PHP 7.4, while we will increase the requirements to PHP 8.1+ from the next release.

A few highlights ✨:

• Last version supporting PHP 7.4 before requiring PHP 8.1+
• Last version supporting PostgreSQL 9.5 before requiring PostgreSQL 10+
• Last version supporting MariaDB 5.5 before requiring MariaDB 10.0.5+
• Last version supporting MySQL 5.5.3 before requiring MySQL 8+
• Many bug and regression fixes

This release has been made by @Alkarex, @math-GH and newcomer @pando85

Full changelog:

• Bug fixing
  • Fix mark-as-read from user query #6738
  • Fix regression for shortcut to move between categories #6741
  • Fix feed title option #6771
  • Fix XPath for HTML documents with broken root (used by CSS selectors to fetch full content) #6774
  • Fix UI regression in Mapco/Ansum themes #6740
  • Fix minor style bug with some themes #6746
  • Fix export of OPML information for date format of JSON and HTML+XPath feeds #6779
• Security
  • OpenID Connect better definition of session parameters #6730
• Compatibility
  • Last version supporting PHP 7.4
• Misc.
  • Use charset for JSON requests from the UI #6710
  • Use .html extension for the local cache of full content pages instead of .spc #6724
  • Update dev dependencies #6739, #6758,
    #6759, #6760

Neu in .NET 8.0 [37]: Zusammenfassung aller Build-Artefakte in ein Verzeichnis

Entwicklerinnen und Entwickler können nun die Ordner /bin, /obj und /publish unter einem Ordner zusammenfassen.

Eine neue Einstellung in .NET 8.0 ermöglicht die Zusammenfassung der bisherigen Ordner /bin, /obj und /publish unterhalb eines gemeinsamen Oberordners, standardmäßig /artifacts.

Das wird durch das Hinzufügen eines Eintrags in der Datei Directory.Build.props erreicht:

<ArtifactsPath>$(MSBuildThisFileDirectory)artifacts</ArtifactsPath>

Diese Datei kann man per Kommandozeilenbefehl anlegen:

dotnet new buildprops --use-artifacts

Hinweis: In Preview 3 hieß dieser neue Ordner standardmäßig noch /.artifacts (mit führendem Punkt), seit Preview 4 nur /artifacts (ohne Punkt). Da Microsoft inzwischen zu der Erkenntnis gelangt ist, dass in den meisten .gitignore-Dateien für .NET "artifacts" schon ausgeschlossen ist, verwendet man nun die neue Schreibweise ohne Punkt.

Während man in Preview 3 das neue Ausgabeverzeichnis noch per Projektdateieintrag aktivieren konnte (<UseArtifactsOutput>true</UseArtifactsOutput>) braucht man nun zwingend eine eigenständige Datei Directory.Build.props mit diesem Inhalt im Projekt oder auf Projektmappenebene.

URL dieses Artikels:
https://www.heise.de/-9840689

Links in diesem Artikel:
[1] https://www.heise.de/blog/Neu-in-NET-8-0-1-Start-der-neuen-Blogserie-9574680.html
[2] https://www.heise.de/blog/Neu-in-NET-8-0-2-Neue-Anwendungsarten-9581213.html
[3] https://www.heise.de/blog/Neu-in-NET-8-0-3-Primaerkonstruktoren-in-C-12-0-9581346.html
[4] https://www.heise.de/blog/Neu-in-NET-8-0-4-Collection-Expressions-in-C-12-0-9581392.html
[5] https://www.heise.de/blog/Neu-in-NET-8-0-5-Typaliasse-in-C-12-0-9594693.html
[6] https://www.heise.de/blog/Neu-in-NET-8-0-6-ref-readonly-in-C-12-0-9602188.html
[7] https://www.heise.de/blog/Neu-in-NET-8-0-7-Optionale-Parameter-in-Lambda-Ausdruecken-in-C-12-0-9609780.html
[8] https://www.heise.de/blog/Neu-in-NET-8-0-8-Verbesserungen-fuer-nameof-in-C-12-0-9616685.html
[9] https://www.heise.de/blog/Neu-in-NET-8-0-9-Neue-und-erweiterte-Datenannotationen-9623061.html
[10] https://www.heise.de/blog/Neu-in-NET-8-0-10-Plattformneutrale-Abfrage-der-Privilegien-9630577.html
[11] https://www.heise.de/blog/Neu-in-NET-8-0-11-Neue-Zufallsfunktionen-9637003.html
[12] https://www.heise.de/blog/Neu-in-NET-8-0-12-Eingefrorene-Objektmengen-9643310.html
[13] https://www.heise.de/blog/Neu-in-NET-8-0-12-Leistung-von-FrozenSet-9649523.html
[14] https://www.heise.de/blog/Neu-in-NET-8-0-14-Neue-Waechtermethoden-fuer-Parameter-9656153.html
[15] https://www.heise.de/blog/Neu-in-NET-8-0-15-Geschluesselte-Dienste-bei-der-Dependency-Injection-9662004.html
[16] https://www.heise.de/blog/Neu-in-NET-8-0-16-Neue-Methoden-fuer-IP-Adressen-9670497.html
[17] https://www.heise.de/blog/Neu-in-NET-8-0-17-Zeitabstraktion-fuer-Tests-mit-Zeitangaben-9675891.html
[18] https://www.heise.de/blog/Neu-in-NET-8-0-18-Ein-Zeitraffer-mit-eigenem-FakeTimeProvider-9683197.html
[19] https://www.heise.de/blog/Neu-in-NET-8-0-19-Razor-HTML-Rendering-in-beliebigen-NET-Anwendungen-9691146.html
[20] https://www.heise.de/blog/Neu-in-NET-8-0-20-Neue-Code-Analyzer-fuer-NET-Basisklassen-9706875.html
[21] https://www.heise.de/blog/Neu-in-NET-8-0-20-Neue-Code-Analyzer-fuer-ASP-NET-Core-9710151.html
[22] https://www.heise.de/blog/Neu-in-NET-8-0-22-Neues-Steuerelement-OpenFolderDialog-fuer-WPF-9722901.html
[23] https://www.heise.de/blog/Neu-in-NET-8-0-23-Verbesserungen-fuer-ZipFile-zur-Arbeit-mit-Dateiarchiven-9722920.html
[24] https://www.heise.de/blog/Neu-in-NET-8-0-24-HTTPS-Proxies-bei-HttpClient-9722968.html
[25] https://www.heise.de/blog/Neu-in-NET-8-0-25-Resilienz-im-HTTP-Client-9763586.html
[26] https://www.heise.de/blog/Neu-in-NET-8-0-26-Anpassung-der-Resilienz-im-HTTP-Client-9773126.html
[27] https://www.heise.de/blog/Neu-in-NET-8-0-27-Konfigurierbare-Namenskonventionen-in-System-Text-Json-8-0-9784360.html
[28] https://www.heise.de/blog/Neu-in-NET-8-0-28-Erweiterung-fuer-die-Deserialisierung-von-JSON-Objekten-9790704.html
[29] https://www.heise.de/blog/Neu-in-NET-8-0-29-Verbesserungen-fuer-den-JSON-Source-Generator-9798297.html
[30] https://www.heise.de/blog/Neu-in-NET-8-0-30-Neue-Datentypen-in-System-Text-Json-8-0-9808793.html
[31] https://www.heise.de/blog/Neu-in-NET-8-0-31-Erweiterte-Serialisierung-in-System-Text-Json-8-0-9814260.html
[32] https://www.heise.de/blog/Neu-in-NET-8-0-32-Weitere-Neuerungen-in-System-Text-Json-8-0-9821053.html
[33] https://www.heise.de/blog/Neu-in-NET-8-0-33-Erweiterung-des-AOT-Compilers-9829857.html
[34] https://www.heise.de/blog/Neu-in-NET-8-0-34-Verbesserte-Ausgaben-beim-Kompilieren-9837144.html
[35] https://net.bettercode.eu/
[36] https://net.bettercode.eu/index.php#programm
[37] https://net.bettercode.eu/tickets.php
[38] mailto:rme@ix.de

Copyright © 2024 Heise Medien

Adblock test (Why?)

Neu in .NET 8.0 [36]: Andere Grundeinstellung bei dotnet publish und dotnet pack

Die Kommandozeilenbefehle dotnet publish und dotnet pack erstellen nun standardmäßig ein Release-Build.

Die Befehle dotnet publish und dotnet pack führten vor .NET 8.0 im Standard eine Debug-Kompilierung durch und man musste immer explizit angeben, dass man eine Release-Kompilierung wünscht.

Beide Befehle führen nun in .NET 8.0 im Standard eine Release- statt einer Debug-Kompilierung durch.

Die Debug-Kompilierung bleibt weiterhin möglich und ist auf Wunsch nutzbar durch

dotnet publish -c debug

beziehungsweise

dotnet pack -c debug

URL dieses Artikels:
https://www.heise.de/-9840333

Links in diesem Artikel:
[1] https://www.heise.de/blog/Neu-in-NET-8-0-1-Start-der-neuen-Blogserie-9574680.html
[2] https://www.heise.de/blog/Neu-in-NET-8-0-2-Neue-Anwendungsarten-9581213.html
[3] https://www.heise.de/blog/Neu-in-NET-8-0-3-Primaerkonstruktoren-in-C-12-0-9581346.html
[4] https://www.heise.de/blog/Neu-in-NET-8-0-4-Collection-Expressions-in-C-12-0-9581392.html
[5] https://www.heise.de/blog/Neu-in-NET-8-0-5-Typaliasse-in-C-12-0-9594693.html
[6] https://www.heise.de/blog/Neu-in-NET-8-0-6-ref-readonly-in-C-12-0-9602188.html
[7] https://www.heise.de/blog/Neu-in-NET-8-0-7-Optionale-Parameter-in-Lambda-Ausdruecken-in-C-12-0-9609780.html
[8] https://www.heise.de/blog/Neu-in-NET-8-0-8-Verbesserungen-fuer-nameof-in-C-12-0-9616685.html
[9] https://www.heise.de/blog/Neu-in-NET-8-0-9-Neue-und-erweiterte-Datenannotationen-9623061.html
[10] https://www.heise.de/blog/Neu-in-NET-8-0-10-Plattformneutrale-Abfrage-der-Privilegien-9630577.html
[11] https://www.heise.de/blog/Neu-in-NET-8-0-11-Neue-Zufallsfunktionen-9637003.html
[12] https://www.heise.de/blog/Neu-in-NET-8-0-12-Eingefrorene-Objektmengen-9643310.html
[13] https://www.heise.de/blog/Neu-in-NET-8-0-12-Leistung-von-FrozenSet-9649523.html
[14] https://www.heise.de/blog/Neu-in-NET-8-0-14-Neue-Waechtermethoden-fuer-Parameter-9656153.html
[15] https://www.heise.de/blog/Neu-in-NET-8-0-15-Geschluesselte-Dienste-bei-der-Dependency-Injection-9662004.html
[16] https://www.heise.de/blog/Neu-in-NET-8-0-16-Neue-Methoden-fuer-IP-Adressen-9670497.html
[17] https://www.heise.de/blog/Neu-in-NET-8-0-17-Zeitabstraktion-fuer-Tests-mit-Zeitangaben-9675891.html
[18] https://www.heise.de/blog/Neu-in-NET-8-0-18-Ein-Zeitraffer-mit-eigenem-FakeTimeProvider-9683197.html
[19] https://www.heise.de/blog/Neu-in-NET-8-0-19-Razor-HTML-Rendering-in-beliebigen-NET-Anwendungen-9691146.html
[20] https://www.heise.de/blog/Neu-in-NET-8-0-20-Neue-Code-Analyzer-fuer-NET-Basisklassen-9706875.html
[21] https://www.heise.de/blog/Neu-in-NET-8-0-20-Neue-Code-Analyzer-fuer-ASP-NET-Core-9710151.html
[22] https://www.heise.de/blog/Neu-in-NET-8-0-22-Neues-Steuerelement-OpenFolderDialog-fuer-WPF-9722901.html
[23] https://www.heise.de/blog/Neu-in-NET-8-0-23-Verbesserungen-fuer-ZipFile-zur-Arbeit-mit-Dateiarchiven-9722920.html
[24] https://www.heise.de/blog/Neu-in-NET-8-0-24-HTTPS-Proxies-bei-HttpClient-9722968.html
[25] https://www.heise.de/blog/Neu-in-NET-8-0-25-Resilienz-im-HTTP-Client-9763586.html
[26] https://www.heise.de/blog/Neu-in-NET-8-0-26-Anpassung-der-Resilienz-im-HTTP-Client-9773126.html
[27] https://www.heise.de/blog/Neu-in-NET-8-0-27-Konfigurierbare-Namenskonventionen-in-System-Text-Json-8-0-9784360.html
[28] https://www.heise.de/blog/Neu-in-NET-8-0-28-Erweiterung-fuer-die-Deserialisierung-von-JSON-Objekten-9790704.html
[29] https://www.heise.de/blog/Neu-in-NET-8-0-29-Verbesserungen-fuer-den-JSON-Source-Generator-9798297.html
[30] https://www.heise.de/blog/Neu-in-NET-8-0-30-Neue-Datentypen-in-System-Text-Json-8-0-9808793.html
[31] https://www.heise.de/blog/Neu-in-NET-8-0-31-Erweiterte-Serialisierung-in-System-Text-Json-8-0-9814260.html
[32] https://www.heise.de/blog/Neu-in-NET-8-0-32-Weitere-Neuerungen-in-System-Text-Json-8-0-9821053.html
[33] https://www.heise.de/blog/Neu-in-NET-8-0-33-Erweiterung-des-AOT-Compilers-9829857.html
[34] https://www.heise.de/blog/Neu-in-NET-8-0-34-Verbesserte-Ausgaben-beim-Kompilieren-9837144.html
[35] mailto:rme@ix.de

Copyright © 2024 Heise Medien

Adblock test (Why?)

Scrum, XP & Co. – warum keiner mehr agil arbeiten will

Die Hochphase agiler Methoden wie Scrum und Extreme Programming scheint vorbei zu sein – ja, es scheint sogar einen Gegentrend zu geben. Wie kommt das?

Ich bin mir nicht sicher, ob es derzeit ein allgemeines Thema ist oder ob es gerade einfach nur verstärkt in meiner eigenen Bubble auftaucht, aber ich habe immer mehr den Eindruck, dass Agilität zunehmend infrage gestellt wird. Sei es durch die dotnetpro, die in ihrer August-Ausgabe einen Leitartikel mit dem Titel "Ist Agilität tot? [1]" veröffentlicht hat. Sei es durch eine Studie aus dem Juni, die behauptet, dass agile Softwareprojekte mit einer um 268 Prozent höheren Wahrscheinlichkeit scheitern [2] würden, oder durch YouTube-Videos mit Titeln wie "It’s time to move on from Agile Software Development (it’s not working) [3]".

Egal, wohin man blickt: Agilität scheint auf einmal nicht mehr en vogue zu sein, sie hat offenbar ihren Zenit überschritten. Doch woran liegt das? Warum ist eine Methodik, die einst angetreten ist, alles besser zu machen und die über Jahre hinweg sehr beliebt war, plötzlich so verpönt?

Agile Methoden – ein Entwicklungsprozess von 1957?!

Vielleicht sollte man zunächst die Frage stellen: Was bedeutet agil überhaupt? Was steckt hinter diesem Begriff, woher kommt er, und wie lautet seine Definition? Beschäftigt man sich damit, stellt man als erstes (und vielleicht auch etwas überrascht) fest, dass vieles von dem, was heutzutage typischerweise mit Agilität assoziiert wird, gar nicht so neu ist, wie man zunächst meint. Tatsächlich reicht nämlich beispielsweise die wichtige Erkenntnis, dass Software eher iterativ und inkrementell entwickelt werden sollte, bis ins Jahr 1957 zurück [4], als IBM erkannte, dass dies der richtige Ansatz ist. In den 1970er-Jahren entstanden dann ergänzend dazu noch das sogenannte "evolutionäre Projektmanagement" und die "adaptive Software-Entwicklung" – beides also ebenfalls schon recht früh.

Formalisiert wurde das Ganze dann schließlich im Februar 2001 unter dem Schlagwort der Agilität im Rahmen des Agilen Manifests [6]. Damals trafen sich zahlreiche Größen der Softwareentwicklung in Utah, um gemeinsam einige Erkenntnisse als Leitsätze für die Zukunft festzuhalten. Mit dabei waren unter anderem die bekannten Entwickler Kent Beck und Ron Jeffries, Ken Schwaber und Jeff Sutherland (bekannt von Scrum), Dave Thomas und Andrew Hunt (bekannt für Ihr Buch "The Pragmatic Programmer"), sowie Martin Fowler und Robert C. Martin. Insgesamt also eine ganze Reihe bedeutender Persönlichkeiten.

Die vier Leitsätze des Agilen Manifests

Sie formulierten vier Leitsätze, die beschreiben, was sie im Laufe der Zeit und in zahlreichen Projekten schätzen gelernt haben. Der erste Punkt besagt, dass Prozesse und Werkzeuge die Menschen und die Interaktion zwischen ihnen fördern sollen und dass sich die Prozesse und Werkzeuge daher an die Bedürfnisse der Menschen anzupassen haben, nicht umgekehrt. Der zweite Punkt betont, dass es wichtiger ist, am Ende des Tages eine funktionierende Software zu haben, die ein reales Problem löst, als eine umfassende Dokumentation zu erstellen.

Der dritte Punkt fordert, in enger Abstimmung mit dem Kunden zu arbeiten, statt jede Kleinigkeit im Vorfeld auszuhandeln und vertraglich festzulegen. Der vierte und letzte Punkt hebt hervor, dass es wichtiger ist, sich auf Veränderungen einzulassen und das Vorgehen entsprechend anzupassen, statt strikt einem Plan zu folgen. Wichtig ist, dass die weniger relevanten Punkte dabei nicht unwichtig sind – sie sind nur nicht so wichtig wie die anderen. Es ist also schon durchaus sinnvoll, einen Plan zu haben, aber man sollte nicht stur an ihm festhalten, wenn sich die äußeren Bedingungen geändert haben, sondern flexibel auf diese reagieren und den Plan adaptieren.

Das ist, kurz zusammengefasst, im Wesentlichen das Agile Manifest.

Was bedeutet das nun?

Das erste Problem tritt auf, wenn man einem Team sagt:

"Wir ersetzen jetzt das V-Modell durch agiles Arbeiten."

Zunächst finden das alle toll, aber letztlich weiß niemand, was sich nun konkret ändern soll, weil niemand genau weiß, was agil denn nun konkret überhaupt bedeutet. Denn selbst wenn man das Agile Manifest zur Hand nimmt, bleibt vieles vage. Was genau bedeutet der erste Punkt, "Individuals and Interactions over Processes and Tools", denn nun für die tagtägliche Praxis?

Es gibt zahlreiche Interpretationsmöglichkeiten, und welche davon die richtige ist, lässt sich schwer beantworten. Deshalb sind im Lauf der Zeit verschiedene Interpretationen entstanden, die dessen vier Grundregeln unterschiedlich auslegen. Um diese Interpretationen auseinanderhalten zu können, haben sie jeweils eigene Namen erhalten. Inhaltlich unterscheiden sie sich in ihren Ansätzen deutlich.

Extreme Programming (XP) [7] richtet sich zum Beispiel an Entwicklerinnen und Entwickler und deren Alltag. Um diesen Alltag agiler zu gestalten, führt XP Praktiken wie Test-Driven Development, einen Build-Server. Code-Reviews und Pair-Programming ein. Also alles sehr konkret auf die tatsächliche Entwicklung bezogen. Im Gegensatz dazu bewegt sich Scrum [8] eher auf einer organisatorischen Meta-Ebene, die sich mit Prozessen und Koordination befasst, während der konkrete Entwicklungsalltag kaum eine Rolle spielt. Trotzdem lässt sich nicht sagen, dass Scrum an sich besser oder schlechter sei als XP.

Der Aufstieg der agilen Methoden

Natürlich gibt es neben diesen beiden agilen Methoden auch noch andere, wie Feature-Driven Development (FDD) oder Kanban [9], und am Ende des Tages ist keine dieser Methoden die einzig wahre. Sie unterscheiden sich eben in ihren Absichten und damit auch in ihrer Interpretation. Viele Teams haben im Laufe der Zeit verschiedene agile Methoden kombiniert, wie zum Beispiel Scrum und Kanban zu Scrumban oder Scrum und XP, auch wenn es dafür bis heute keinen schicken Namen gibt. Es gibt Praktiken, die sich bewährt haben und für bestimmte Arten von Projekten passen, und andere, für die das weniger gilt. Doch das hängt letztlich immer stark davon ab, was man erreichen möchte.

Und bis hierhin ist die Geschichte auch ein großer Erfolg: Die agilen Methoden, allen voran Scrum, haben praktisch die Welt erobert. Ich weiß nicht, wie viele Unternehmen ihren Teams Scrum oder eine andere agile Methode verordnet haben, aber man kann sagen, dass agile Methoden im Verlauf von zwei Jahrzehnten das V-Modell und so ziemlich jeden anderen Softwareentwicklungsansatz abgelöst haben. Wenn ein Team heutzutage bewusst auf eine agile Methode verzichtet, wirkt das oft (zumindest auf den ersten Blick) seltsam und veraltet.

Zumindest war das bis vor Kurzem so. Aber, wie ich eingangs erwähnte, scheint in den letzten Jahren etwas schiefgelaufen zu sein. Immer weniger Unternehmen scheinen noch Interesse an agilen Methoden zu haben, und immer häufiger wird die Agilität als Ganzes infrage gestellt. Da frage ich mich: Wie konnte das passieren? Was ist schiefgelaufen? Aus meiner Sicht gibt es im Wesentlichen drei Punkte, an denen Agilität scheitert und die immer wieder kritisiert werden.

Agilität als Cargo-Kult

Punkt Nummer eins ist, dass agile Methoden, welche auch immer verwendet werden, angeblich nicht die versprochene Verbesserung gebracht hätten. Das ist tatsächlich etwas, was ich schon oft gesehen habe: Ein Unternehmen führt zum Beispiel Scrum ein, aber es funktioniert nicht richtig. Wenn man jedoch genauer hinschaut, stellt man häufig fest, dass das, was da gemacht wird, gar kein echtes Scrum ist. Stattdessen wird etwas praktiziert, das zwar pro forma so aussieht wie Scrum, aber völlig am Ziel vorbeigeht.

Formal werden also alle Anforderungen erfüllt, und dennoch ist das Team so weit weg von einem agilen Prozess, wie man sich das nur vorstellen kann. Leider ist das tatsächlich nicht selten. Da werden dann Sprints geplant, bei denen der Product Owner den konkreten Inhalt vorgibt, und das Entwicklungsteam darf diesen Umfang nur abnicken – egal wie unrealistisch die Vorgabe auch sein mag. Sprints dauern dann drei Monate. Retrospektiven behandeln alles, nur nicht, wie es den Teammitgliedern geht. Und das Daily dauert anderthalb Stunden, weil es zu einem klassischen Statusmeeting verkommt [10]. Geht man die Liste der Scrum-Kriterien oberflächlich durch, wird man alle Elemente wiederfinden – aber jeder einzelne Punkt wird nicht so umgesetzt, wie es für den erfolgreichen Einsatz von Scrum erforderlich wäre.

In einem solchen Szenario ist es natürlich kein Wunder, dass das Ganze am Ende nicht das hält, was ursprünglich versprochen wurde. Die Frage ist: Warum passiert so etwas? Wohlwollend könnte man sagen, das jeweilige Team wusste es vielleicht nicht besser und ist eventuell über kurz oder lang wieder in alte Verhaltensmuster zurückgefallen. Vielleicht hatte das Team auch keine gute Anleitung und Unterstützung, aber es hat sich zumindest nach bestem Wissen und Gewissen bemüht.

Für dieses pseudo-agile Vorgehen gibt es sogar einen Begriff: Man nennt das Ganze Fake-Agile. Ich persönlich würde es vielleicht auch als Cargo-Kult [11] bezeichnen, aber im Grunde meinen beide Begriffe dasselbe: Nur weil man etwas tut, das wie die richtige Umsetzung aussieht, bedeutet das noch lange nicht, dass man auch tatsächlich das Richtige macht.

Agilität als Deckmantel einer Hidden-Agenda

Punkt Nummer zwei ist zumindest in weiten Teilen praktisch dasselbe wie Punkt Nummer eins, nur mit einem anderen Hintergrund. Während ich bei Fake-Agile den meisten Teams unterstelle, dass sie es einfach nicht besser hinbekommen haben, gibt es auch jene Teams, in denen Agilität bewusst falsch praktiziert wird. Das ist dann nicht mehr Fake-Agile, sondern wird als Dark-Agile bezeichnet. Hier wird unter dem Deckmantel von Scrum, XP & Co. eine bewusst nicht-agile Vorgehensweise angewendet, meistens, um eine andere Agenda durchzusetzen, also eine irgendwie geartete Hidden-Agenda.

Das kann bedeuten, die Kontrolle über die Mitarbeiterinnen und Mitarbeiter erhöhen zu wollen, oder ein Team bewusst gegen die Wand laufen zu lassen, um dann zu sagen, dass die Methode nicht gut oder das Team ungeeignet sei, oder Ähnliches. In jedem Fall wird das Team als Bauernopfer für ein ganz anderes Vorhaben benutzt, das mit Agilität nichts zu tun hat. Das ist aus naheliegenden Gründen der viel schlimmere Fall, weil hier mit Menschen gespielt wird, mit deren Hoffnungen, Erwartungen und Engagement. Dark-Agile ist daher als sehr negativ zu bewerten.

Egal, ob es sich um Fake- oder Dark-Agile handelt: Beides trägt natürlich nicht dazu bei, das Vertrauen in agile Vorgehensweisen zu stärken. Im Gegenteil, das Vertrauen sinkt eher, und es ist am Ende leicht zu sagen:

"Tja, das habe ich euch ja gleich gesagt. Ich schlage vor, wir machen es jetzt mal anders."

Wer also eine Veränderung weg von der Agilität will, der oder dem spielen Fake- und Dark-Agile ideal in die Hände. Im einen Fall lässt man dem Schicksal seinen Lauf und greift nicht rettend ein, im anderen Fall fördert man das Ganze sogar noch. Das Ergebnis ist letztlich dasselbe: Die Agilität steht schlecht da.

Der agil-industrielle Komplex

Hinzu kommt noch ein weiterer Aspekt, der agile Methoden aus einer ganz anderen Richtung diskreditiert: Der, wie ich ihn in Anlehnung an die Rüstungsindustrie gerne nenne, agil-industrielle Komplex. Gemeint ist die extreme Kommerzialisierung der Agilität, was vor allem Scrum betrifft. Das Problem ist, dass Organisationen wie Scrum.org oder die Scrum Alliance damit begonnen haben, Zertifikate auszustellen, Workshops zu veranstalten und Train-the-Trainer-Konzepte zu entwickeln – alles nur mit dem Ziel, eine komplette Business-Maschinerie rund um eine agile Methode aufzubauen.

Und ganz ehrlich: Den ganzen Kram braucht niemand, um agil arbeiten zu können, am allerwenigsten Zertifikate [12]. Allerdings benötigt diese Erkenntnis Zeit, und in der Zwischenzeit wurde sich bereits an zahllosen Entwicklerinnen, Entwicklern, Managerinnen und Managern eine goldene Nase verdient. Und natürlich möchte ich hier nicht alle Agile-Coaches oder Beratungsunternehmen über einen Kamm scheren, aber gerade in diesem Bereich gibt es auffallend viele schwarze Schafe.

Damit sind wir dann auch schnell bei Agilität als vermeintlichem Allheilmittel, als angepriesenem Wundermittel, als Schlangenöl. Egal, was Sie vorhaben: Mit Scrum (oder einer anderen agilen Methode) wird es auf jeden Fall besser. Und natürlich zeigt Ihnen gegen viel Geld auch sehr gerne jemand, wie das funktioniert. Wenn es dann nicht funktioniert, haben Sie sich einfach nicht ausreichend bemüht. Vielleicht brauchen Sie noch einen weiteren Workshop oder ein weiteres Zertifikat. Und so entsteht nach und nach ein Geschäftsmodell, das sich selbst befeuert: Wenn Sie Ihr Zertifikat bestehen, ist das super, aber leider läuft es nach ein paar Jahren ab, und Sie müssen es erneuern. Es hat sich zwar inhaltlich nichts geändert, aber Sie sind auf der sicheren Seite, wenn Ihr Zertifikat aktuell bleibt. Dass Sie dafür wieder Geld bezahlen müssen, das kann man ja unter den Tisch fallen lassen. Aber hey, Sie haben wieder ein Zertifikat, das Sie an die Wand hängen können! Ist das nicht toll?

Was bedeutet das nun zusammengenommen?

Was ist nun das Fazit? Ich glaube ehrlich gesagt, dass Scrum seine Hochzeit tatsächlich hinter sich hat. Und ich glaube auch, dass Scrum, wenn man mal ehrlich ist, gar nicht so gut und so übermäßig gelungen ist, wie oft angenommen oder dargestellt. Damit sage ich nicht, dass Scrum per se schlecht sei oder dass es keine Projekte gäbe, die sich für Scrum eignen würden, aber ich bin der festen Überzeugung, dass Scrum deutlich überbewertet ist.

Dass Scrum und Agilität heute oft gleichgesetzt werden, ist problematisch. Denn XP zum Beispiel halte ich nach wie vor für eine fantastische Arbeitsweise. Ja, vielleicht muss man das eine oder andere modernisieren, immerhin ist XP auch schon über 20 Jahre alt, aber XP halte ich persönlich für wesentlich gelungener als Scrum. Auch Kanban finde ich wesentlich gelungener als Scrum. Tatsächlich bin ich ein großer Freund von Kanban in der Verbindung mit XP, wobei ich auch dort ein paar Anpassungen vornehmen würde. Deshalb haben wir bei meinem Unternehmen, the native web [13], eine eigene Entwicklungsmethode entworfen, die zwar an Kanban und XP angelehnt ist, aber doch ein bisschen anders funktioniert.

Und ich weiß, dass jetzt viele sagen werden:

„Ja, aber damit machst du doch genau das, was du bei Scrum kritisiert hast: Du machst Kanban und XP auch nicht mehr wie im Lehrbuch.“

Und das stimmt. Aber ich habe vorhin auch nicht gesagt, dass man agile Methoden nicht adaptieren dürfe, sondern nur, dass man ein anderes Ergebnis erzielt, wenn man die Vorgehensweise ändert. Solange die Veränderung das Ergebnis verbessert, ist sie legitim. Das Problem ist nur, dass dreimonatige Sprints, fehlende Reviews und Pro-Forma-Retrospektiven das Ergebnis eher verschlechtern. Und dann war die Anpassung eben eine eher schlechte Idee. Man sollte also mit einem gewissen Augenmerk auf das Ergebnis an die Anpassung des Prozesses herangehen. Wenn man das kann, funktioniert es auch. Wenn nicht, sollte man es lieber lassen.

Ist Agilität tot?

Langer Rede, kurzer Sinn: Ich glaube nicht, dass Agilität tot ist. Ich glaube auch nicht, dass Projekte, die einem agilen Prozess folgen, mit einer 268 Prozent höheren Wahrscheinlichkeit scheitern. Und ich glaube vor allem auch nicht, dass es Zeit ist, sich von agiler Entwicklung an sich zu verabschieden.

Ich glaube aber, dass man, wenn man agil arbeiten möchte, es dann auch richtig tun sollte. Dafür braucht man nicht zwingend Scrum, die Scrum Alliance, Scrum.org, einen zertifizierten Coach oder Ähnliches. Was man braucht, ist das Agile Manifest und jemanden, die oder der einen agilen Prozess auf dieser Basis aufbauen und betreuen kann, und die oder der wirklich versteht, was Agilität im Kern bedeutet.

URL dieses Artikels:
https://www.heise.de/-9846824

Links in diesem Artikel:
[1] https://www.dotnetpro.de/planung/agile/agilitaet-tot-2926271.html
[2] https://www.heise.de/blog/Agilitaet-fuehrt-zu-268-Prozent-mehr-Fehlschlaegen-kann-das-sein-9810522.html
[3] https://www.youtube.com/watch?v=gSVBWvoNJ-s
[4] https://www.youtube.com/watch?v=CxiPpf-Dejw
[5] https://www.heise.de/Datenschutzerklaerung-der-Heise-Medien-GmbH-Co-KG-4860.html
[6] https://agilemanifesto.org/
[7] https://www.youtube.com/watch?v=uyLhrO1rEyc
[8] https://www.youtube.com/watch?v=8RE68Fzjkuk
[9] https://www.youtube.com/watch?v=1JOSm5tUQmE
[10] https://www.youtube.com/watch?v=CdnP30NEKqk
[11] https://de.wikipedia.org/wiki/Cargo-Kult
[12] https://www.youtube.com/watch?v=GRZQLc1xkoo
[13] https://www.thenativeweb.io/
[14] mailto:who@heise.de

Copyright © 2024 Heise Medien

Adblock test (Why?)

FreshRSS 1.24.2

• Milestone

This is a quality-focussed release for the 1.24.x series meant to provide a good product to people blocked on PHP 7.4, while we will increase the requirements to PHP 8.1+ from the next 1.25.x series.

A few highlights ✨:

• New global option to automatically add articles to favourites
• New option to share articles from the article title line
• Add core extensions, shipped by default: UserCSS and UserJS
• Security: Force log out of users when they are disabled
• Many bug and regression fixes

This release has been made by @Alkarex, @ColonelMoutarde, @den13501, @hkcomori, @math-GH
and newcomers @dservian, @crisukbot, @TomW1605

Full changelog:

• Features
  • New global option to automatically add articles to favourites #6648
  • New possibility to share a user query in JSON GReader format #6655
  • New fields image and description for user query share #6541
  • Show article first words when an article title is empty #6240
  • New option to share articles from the article title line #6395
  • Improve JSON Dot Notation module to access more string-friendly types #6631
  • Improve detection of image types for enclosures not providing a type #6653
  • Add sharing to archive.is #6650
• Security
  • Force log out of users when they are disabled #6612
  • Increase default values for OpenID Connect OIDCSessionMaxDuration and OIDCSessionInactivityTimeout #6642
  • Add default API CORS HTTP headers to shareable user queries #6659
• Bug fixing
  • Fix parentheses for complex OR Boolean search expressions #6672
  • Fix keep max unread #6632
  • Fix regression in mark as read upon gone #6663
  • Fix regression on mark duplicate titles as read for modified articles #6664
  • Fix regression for Fever API, remove dependency to Exif extension #6624
  • Fix muted feeds for WebSub #6671
  • Fix performance / deadlock of PostgreSQL and MySQL / MariaDB during schema updates #6692
  • Fix HTTP cache of main page (regression since 1.18.0) #6719
  • Fix HTTP cache of shareable user queries #6718
  • Fix HTTP cache for feeds with modified Last-Modified when content is not modified #6723
• Extensions
  • Add core extensions, shipped by default: UserCSS and UserJS #6267
    • Replaces CustomCSS and CustomCS extensions
  • Strong type array parameter helper #6661
• CLI
  • Add quiet option to cli/db-backup.php #6593
• Compatibility
  • Initial support for PHP 8.4+ #6615
    • With upstream contributions php/php-src#14873, PhpGt/CssXPath#227
  • Fix SQLite on FreeBSD due to DQS #6701, #6702
• Deployment
  • Docker default image (Debian 12 Bookworm) updated to PHP 8.2.20 and Apache 2.4.61
  • Docker alternative image updated to Alpine 3.20 with PHP 8.3.10 and Apache 2.4.62 #5383
  • Docker: Alpine dev image freshrss/freshrss:newest updated to PHP 8.4.0beta3 and Apache 2.4.62 #5764
• UI
  • Default dark mode to auto #5582
  • New option to control action icons position in reading view #6297
  • Sticky buttons at the bottom of settings #6304
  • Various UI and style improvements #6446, #6485,
    #6651
• I18n
  • Czech: use correct ISO 639-1 code cs (and not cz, which is the country) #6514
  • Improve Japanese #6564
  • Improve Spanish #6634
  • Improve Traditional Chinese #6691
• Misc.
  • Pass PHPStan Level 9 #6544
  • Migrate to ESLint 9 #6685
  • Minor update of PHPCS whitespace / formatting rules #6666
  • Markdownlint no-trailing-spaces #6668
  • Removed sharing with Blogotext #6225
  • Code improvements #6043
  • Update dev dependencies #6606, #6614,
    #6679, #6681, #6682,
    #6683, #6684

Neu in .NET 8.0 [35]: Sicherheitswarnungen vor NuGet-Paketen

Visual Studio und die .NET-Kommandozeilenwerkzeuge können nun vor Paketen mit Sicherheitslücken warnen.

Bei der Paketverwaltung können die Paketverwaltungsbefehle

dotnet add package 

und

dotnet restore

sowie die Übersetzungsbefehle

dotnet build

und

msbuild

nun Sicherheitswarnungen beim Verwenden von NuGet-Paketen mit Sicherheitslücken ausgeben (siehe Abbildungen).

Wählbar ist, ab welchem Schweregrad man Meldungen erhält, zum Beispiel

<PropertyGroup>
  <NuGetAuditLevel>moderate</NuGetAuditLevel>
</PropertyGroup>

Die hier einstellbaren Level sind low, moderate, high und critical.

Entwickler und Entwicklerinnen können alle NuGet-Sicherheitswarnungen mit der Projekteinstellung

<PropertyGroup>
  <NuGetAudit>false</NuGetAudit>
</PropertyGroup>

unterbinden. Seit .NET SDK 8.0.400 und Visual Studio 17.11 kann man alternativ auch nur einzelne Warnungen unterdrücken mit <NuGetAuditSuppress>:

<ItemGroup>
  <NuGetAuditSuppress Include="https://github.com/advisories/GHSA-98g6-xh36-x2p7" />
</ItemGroup>

Dieses Tag unterdrückt diese Warnung:

Warning NU1903: Package 'System.Data.SqlClient' 4.8.5 has a known high severity vulnerability, https://github.com/advisories/GHSA-98g6-xh36-x2p7 [35]

Man sieht die Warnung auch in Visual Studio:

• Solution Explorer
• Paketreferenzen
• Nuget Package Manager GUI
• Build-Ausgabe
• Error List

Tipp: Die Sicherheitswarnungen erhält man auch in Projekten mit .NET 5.0, 6.0 und 7.0, sofern man das .NET 8.0 SDK verwendet.

URL dieses Artikels:
https://www.heise.de/-9840301

Links in diesem Artikel:
[1] https://www.heise.de/blog/Neu-in-NET-8-0-1-Start-der-neuen-Blogserie-9574680.html
[2] https://www.heise.de/blog/Neu-in-NET-8-0-2-Neue-Anwendungsarten-9581213.html
[3] https://www.heise.de/blog/Neu-in-NET-8-0-3-Primaerkonstruktoren-in-C-12-0-9581346.html
[4] https://www.heise.de/blog/Neu-in-NET-8-0-4-Collection-Expressions-in-C-12-0-9581392.html
[5] https://www.heise.de/blog/Neu-in-NET-8-0-5-Typaliasse-in-C-12-0-9594693.html
[6] https://www.heise.de/blog/Neu-in-NET-8-0-6-ref-readonly-in-C-12-0-9602188.html
[7] https://www.heise.de/blog/Neu-in-NET-8-0-7-Optionale-Parameter-in-Lambda-Ausdruecken-in-C-12-0-9609780.html
[8] https://www.heise.de/blog/Neu-in-NET-8-0-8-Verbesserungen-fuer-nameof-in-C-12-0-9616685.html
[9] https://www.heise.de/blog/Neu-in-NET-8-0-9-Neue-und-erweiterte-Datenannotationen-9623061.html
[10] https://www.heise.de/blog/Neu-in-NET-8-0-10-Plattformneutrale-Abfrage-der-Privilegien-9630577.html
[11] https://www.heise.de/blog/Neu-in-NET-8-0-11-Neue-Zufallsfunktionen-9637003.html
[12] https://www.heise.de/blog/Neu-in-NET-8-0-12-Eingefrorene-Objektmengen-9643310.html
[13] https://www.heise.de/blog/Neu-in-NET-8-0-12-Leistung-von-FrozenSet-9649523.html
[14] https://www.heise.de/blog/Neu-in-NET-8-0-14-Neue-Waechtermethoden-fuer-Parameter-9656153.html
[15] https://www.heise.de/blog/Neu-in-NET-8-0-15-Geschluesselte-Dienste-bei-der-Dependency-Injection-9662004.html
[16] https://www.heise.de/blog/Neu-in-NET-8-0-16-Neue-Methoden-fuer-IP-Adressen-9670497.html
[17] https://www.heise.de/blog/Neu-in-NET-8-0-17-Zeitabstraktion-fuer-Tests-mit-Zeitangaben-9675891.html
[18] https://www.heise.de/blog/Neu-in-NET-8-0-18-Ein-Zeitraffer-mit-eigenem-FakeTimeProvider-9683197.html
[19] https://www.heise.de/blog/Neu-in-NET-8-0-19-Razor-HTML-Rendering-in-beliebigen-NET-Anwendungen-9691146.html
[20] https://www.heise.de/blog/Neu-in-NET-8-0-20-Neue-Code-Analyzer-fuer-NET-Basisklassen-9706875.html
[21] https://www.heise.de/blog/Neu-in-NET-8-0-20-Neue-Code-Analyzer-fuer-ASP-NET-Core-9710151.html
[22] https://www.heise.de/blog/Neu-in-NET-8-0-22-Neues-Steuerelement-OpenFolderDialog-fuer-WPF-9722901.html
[23] https://www.heise.de/blog/Neu-in-NET-8-0-23-Verbesserungen-fuer-ZipFile-zur-Arbeit-mit-Dateiarchiven-9722920.html
[24] https://www.heise.de/blog/Neu-in-NET-8-0-24-HTTPS-Proxies-bei-HttpClient-9722968.html
[25] https://www.heise.de/blog/Neu-in-NET-8-0-25-Resilienz-im-HTTP-Client-9763586.html
[26] https://www.heise.de/blog/Neu-in-NET-8-0-26-Anpassung-der-Resilienz-im-HTTP-Client-9773126.html
[27] https://www.heise.de/blog/Neu-in-NET-8-0-27-Konfigurierbare-Namenskonventionen-in-System-Text-Json-8-0-9784360.html
[28] https://www.heise.de/blog/Neu-in-NET-8-0-28-Erweiterung-fuer-die-Deserialisierung-von-JSON-Objekten-9790704.html
[29] https://www.heise.de/blog/Neu-in-NET-8-0-29-Verbesserungen-fuer-den-JSON-Source-Generator-9798297.html
[30] https://www.heise.de/blog/Neu-in-NET-8-0-30-Neue-Datentypen-in-System-Text-Json-8-0-9808793.html
[31] https://www.heise.de/blog/Neu-in-NET-8-0-31-Erweiterte-Serialisierung-in-System-Text-Json-8-0-9814260.html
[32] https://www.heise.de/blog/Neu-in-NET-8-0-32-Weitere-Neuerungen-in-System-Text-Json-8-0-9821053.html
[33] https://www.heise.de/blog/Neu-in-NET-8-0-33-Erweiterung-des-AOT-Compilers-9829857.html
[34] https://www.heise.de/blog/Neu-in-NET-8-0-34-Verbesserte-Ausgaben-beim-Kompilieren-9837144.html
[35] https://github.com/advisories/GHSA-98g6-xh36-x2p7
[36] https://net.bettercode.eu/
[37] https://net.bettercode.eu/index.php#programm
[38] https://net.bettercode.eu/tickets.php
[39] mailto:rme@ix.de

Copyright © 2024 Heise Medien

Adblock test (Why?)

Node.js + TypeScript = Nie wieder JavaScript

Wer mit Node.js entwickelt, schreibt JavaScript – oder muss umständlich TypeScript konfigurieren. Doch beides hat nun bald ein Ende.

"Nie wieder JavaScript!"

Diesen Satz habe ich in den vergangenen fünfzehn Jahren, in denen ich mit Node.js gearbeitet habe, immer wieder gehört. Die Liste der Vorwürfe war lang: JavaScript sei keine richtige Programmiersprache. JavaScript sei nicht für komplexe Projekte im Enterprise-Bereich geeignet. JavaScript sei dies nicht, JavaScript sei jenes nicht. Natürlich trifft man in fünfzehn Jahren auch auf einige, die JavaScript mögen, aber die Mehrheit der Entwicklerinnen und Entwickler lehnt JavaScript rundheraus ab. Viele schreiben es nur aus Notwendigkeit, nicht aber aus Überzeugung. JavaScript sei seltsam [1], das ist eine immer noch weitverbreitete Meinung. Wenn auch Sie dieser Meinung sind, dann habe ich heute eine richtig gute Neuigkeit für Sie: Es ist vorbei, Sie werden nie wieder JavaScript schreiben müssen!

Vielleicht sagen Sie jetzt:

"Naja, eigentlich stimmt das so nicht ganz, denn auch heute schon muss ich JavaScript nicht zwingend schreiben. Schließlich gibt es TypeScript."

Und das ist richtig. Seit Microsoft vor zwölf Jahren TypeScript auf den Markt gebracht hat, ist es praktisch zur De-facto-Sprache in der modernen Webentwicklung geworden. Und das ist kein Zufall, denn TypeScript macht vieles richtig: Angefangen beim sehr guten und durchdachten optionalen statischen Typsystem bis hin zum ebenfalls sehr zuverlässigen Compiler. TypeScript können viele Entwicklerinnen und Entwickler nicht mehr aus ihrem Arbeitsalltag wegdenken. Wäre da nicht das Tooling, denn wo Licht ist, ist bekanntermaßen auch Schatten.

Ich weiß aus eigener Erfahrung, dass es Lustigeres gibt, als ein Node.js-Projekt mit TypeScript aufzusetzen. Es ist nämlich nicht damit getan, TypeScript zu installieren und zu konfigurieren, sondern es soll schließlich auch das ganze Drumherum mit TypeScript funktionieren: von der Codeformatierung über das Linting bis hin zu den Tests. Bis alle Bausteine so konfiguriert sind, dass alles zueinander passt und miteinander harmoniert, vergeht viel Zeit.

Warum unterstützt Node.js TypeScript nicht nativ?

Da werde ich sicherlich nicht der Einzige sein, der sich in den vergangenen zwölf Jahren immer wieder gefragt hat, warum eigentlich Node.js nicht TypeScript nativ unterstützt. Warum muss man als Entwicklerin oder als Entwickler im Node-Universum immer diesen extrem lästigen Eiertanz aufführen, bis TypeScript endlich so läuft, wie es das soll? Wäre es nicht viel einfacher, wenn Node.js TypeScript von Haus aus unterstützen würde? Dann könnte man sich den ganzen Compiler sparen, die Tests würden automatisch mit TypeScript funktionieren, und das ganze sonstige Tooling wäre vermutlich schnell umgestellt. Denn wenn TypeScript erst einmal im Fundament richtig funktionieren würde, würde der Rest wohl rasch folgen. Also: Wäre es nicht fantastisch, wenn Node.js TypeScript nativ unterstützen würde? Wäre das nicht ein riesiger Schritt nach vorn?

Und damit kommen wir zu der versprochenen großen Neuigkeit: Seit Anfang Juli 2024 enthält Node.js native Unterstützung für TypeScript!

Weil viele jetzt wahrscheinlich neugierig sind, wie das funktioniert und vor allem auch, wie gut das funktioniert, habe ich ein paar Antworten. Zuerst einmal: Die Unterstützung für TypeScript ist aktuell noch experimentell, sie ist nur in den Nightly Builds vorhanden, und man muss beim Starten von Node.js ein passendes Flag angeben, nämlich --experimental-strip-types. Das Ganze wird sicherlich bald in einem regulären Release enthalten sein und vielleicht sogar in Node.js 23, das uns voraussichtlich im Oktober erwartet.

Wie das Type-Stripping funktioniert

Die Implementierung ist zunächst ganz simpel: Die Typ-Annotationen im Code werden zur Laufzeit schlicht und ergreifend verworfen. Das heißt, es findet keinerlei Typenprüfung statt. Das war eine bewusste Entscheidung des Node-Teams. Wenn Sie die Typenprüfung haben wollen, brauchen Sie weiterhin den TypeScript-Compiler. Das ist bei Node.js in Zukunft also genauso wie bei Deno und Bun [3]. Tatsächlich ist das kein Zufall, denn unter der Haube verwendet Node.js für das Type-Stripping denselben Mechanismus wie Deno.

Dieses Type-Stripping ist dabei übrigens wörtlich zu nehmen: Es wird nämlich nicht der Code transformiert, sondern nur die Typ-Annotationen entfernt. Alles, was theoretisch von TypeScript nach JavaScript transformiert werden müsste, um zu funktionieren, wird daher aktuell nicht funktionieren. Dazu zählen etwa Features wie Enums oder Namespaces. Das heißt, zum jetzigen Zeitpunkt ist noch keine volle Unterstützung für TypeScript gegeben. Aber man darf nicht vergessen, dass wir derzeit noch über einen sehr frühen Entwicklungsstand sprechen, und dass sich im Laufe der Zeit noch einiges ändern kann. Dazu komme ich aber gleich noch.

Technisch basiert das Ganze auf dem npm-Modul @swc/wasm-typescript [4]. SWC ist dabei der Speedy Web Compiler [5], in Rust geschrieben und dementsprechend schnell. Das besagte npm-Modul enthält den TypeScript-Parser von SWC, aber nicht (wie man das vielleicht erwarten würde) als Rust-Code, sondern als WebAssembly-Code. Auf diesem Weg kann Node.js das Ganze einfach ausführen, ohne dass Rust auf dem jeweiligen System installiert sein müsste. Das finde ich persönlich sehr schlau gelöst. Und genau derselbe Mechanismus steckt übrigens auch in Deno.

Der Weg in die Zukunft

Für die erste Version muss man mit einigen Einschränkungen leben wie der fehlenden Unterstützung für einige Sprachmerkmale. Dateien müssen außerdem zwingend die Dateiendung .ts tragen, sie dürfen nicht als .js benannt sein. Darüber hinaus wird TypeScript nur im Code Ihres eigenen Projekts unterstützt, nicht aber im node_modules-Verzeichnis. Man wollte verhindern, dass Entwicklerinnen und Entwickler npm-Module nur noch als reine TypeScript-Anwendung veröffentlichen, was die Abwärtskompatibilität zunichtemachen würde. Also muss beim Veröffentlichen von Modulen weiterhin kompiliert werden. Spannend finde ich übrigens, dass auch nach dem Type-Stripping Fehler zur Laufzeit mit den richtigen Zeilen- und Spaltennummern im Quellcode angegeben werden können. Das könnte darauf hindeuten, dass sogar Sourcemaps unterstützt werden – tatsächlich ist die Lösung aber weitaus einfacher: Beim Type-Stripping werden die Typannotationen nämlich einfach mit Leerzeichen überschrieben, sodass alle Positionen im Quellcode erhalten bleiben.

Auf absehbare Zeit soll das Type-Stripping dann von Node.js entkoppelt werden, sodass man nicht auf eine spezifische Node-Version mit einer spezifischen TypeScript-Version angewiesen ist. Man will zu einem Modell kommen wie mit npm, das bei Node.js mitgeliefert wird, sich aber unabhängig aktualisieren lässt. Eine Herausforderung ist, dass man TypeScript pro Projekt installieren möchte und nicht global systemweit. Wie das gelöst werden soll, ist noch offen. Es gibt zwar bereits ein npm-Modul namens amaro [6], das als Wrapper um @swc/wasm-typescript fungiert. In der Dokumentation dieses Moduls heißt es aktuell jedoch noch, dass man es global installieren solle. Das steckt also alles noch in den Kinderschuhen und wird noch seine Zeit brauchen.

Wenn dann irgendwann dafür eine Lösung gefunden ist, folgen die Schritte drei und vier der Roadmap: Zunächst wird dabei die Performance verbessert und die Kommunikation zwischen Node und dem TypeScript-Compiler effizienter gestaltet. In Schritt vier geht es dann schließlich um neue Features. Frühestens dann ist damit zu rechnen, dass weitere Sprachmerkmale von TypeScript unterstützt werden, die über das reine Type-Stripping hinausgehen. Ein Feature, das dann ebenfalls dazugehören soll, ist die Unterstützung der tsconfig.json. Ich finde es überraschend, dass ausgerechnet das noch so lange auf sich warten lassen wird. Aber gut: Es ist, wie es ist.

Verhaltene Freude

Insgesamt muss ich zugeben, dass ich positiv überrascht bin, dass dieses Feature nun grundsätzlich Einzug in Node.js findet. Deno und Bun hatten in den letzten Jahren einen deutlichen Vorsprung, der jetzt zunehmend kleiner wird. Ich habe an den letzten Versionen von Node.js stets viel zu kritisieren gehabt, aber das ist ein großer Schritt in die richtige Richtung. Auch wenn ich vielleicht nicht mit allen Details glücklich bin, ist das grundsätzlich dennoch ein hervorragender Schritt. Ich hoffe nur, dass das Thema nicht genauso versumpft wie andere, etwa die Single Executable Applications [7], die mit Node 19.7 eingeführt wurden. Oder die Verwendung der V8-eigenen Sandbox, um die Sicherheit bei heruntergeladenen Modulen zu verbessern [8], was in Anlehnung an das Sandbox-basierte Sicherheitsmodell von Deno erfolgte. Seit Node 20 ist daran jedoch ebenfalls nichts mehr passiert.

Deshalb bin ich zwar positiv überrascht, aber meine Begeisterung hält sich derzeit noch in Grenzen, weil ich skeptisch bin, wie viel von der angekündigten Roadmap tatsächlich umgesetzt werden wird und vor allem, wann. Denn es ist schön, wenn Deno und Bun dafür sorgen, dass wieder mehr frischer Wind in Node.js hineinkommt. Allerdings ist das nur solange schön, wie die Features auch tatsächlich fertig umgesetzt werden und nicht als angefangene Baustellen liegenbleiben. Da bin ich noch etwas verhalten. Aber: Die Zukunft wird zeigen, was das Node-Team zum Beispiel im Oktober in Version 23 veröffentlichen wird. Bis dahin müssen wir uns gedulden und uns überraschen lassen.

URL dieses Artikels:
https://www.heise.de/-9826686

Links in diesem Artikel:
[1] https://www.youtube.com/watch?v=VNYIYqqaOcc
[2] https://www.heise.de/Datenschutzerklaerung-der-Heise-Medien-GmbH-Co-KG-4860.html
[3] https://www.youtube.com/watch?v=WLklm8JQbjo
[4] https://www.npmjs.com/package/@swc/wasm-typescript
[5] https://swc.rs/
[6] https://www.npmjs.com/package/amaro
[7] https://www.youtube.com/watch?v=6ThplMUASJA
[8] https://www.youtube.com/watch?v=T4XakaNaMPU
[9] mailto:rme@ix.de

Copyright © 2024 Heise Medien

Adblock test (Why?)

Neu in .NET 8.0 [34]: Verbesserte Ausgaben beim Kompilieren

Der neue Terminal Logger erzeugt übersichtlichere Ausgaben, aber der alte lässt sich auf Wunsch weiterhin verwenden.

Das .NET 8.0 SDK liefert seit Preview 4 einige deutliche Verbesserungen der Konsolenausgaben des Übersetzungswerkzeugs MSBuild (siehe Abbildungen 1 und 2). In Verbindung mit dem modernen Windows Terminal [1] sind die Ausgaben nun besser strukturiert.

Target Framework und Übersetzungsergebnis werden in den Farben Cyan, Grün und Rot hervorgehoben. Bei jedem Ausführungsschritt sieht man die aktuelle Dauer in Sekunden.

Dazu müssen Entwickler und Entwicklerinnen beim Übersetzen mit dotnet build oder msbuild zusätzlich den Parameter /tl (die Buchstaben stehen für den neuen "Terminal Logger") angeben:

dotnet build /tl
# beziehungsweise
msbuild /tl

Die Option prüft dann automatisch, ob das verwendete Konsolenfenster die neuen Features unterstützt und fällt gegebenenfalls auf den alten "Console Logger" zurück.

Man kann mit /tl:on oder /tl:off die Verwendung des neuen beziehungsweise alten Loggers erzwingen.

URL dieses Artikels:
https://www.heise.de/-9837144

Links in diesem Artikel:
[1] https://www.heise.de/news/Windows-Terminal-Preview-1-21-bringt-einen-experimentellen-Notizblock-9715811.html
[2] https://www.heise.de/blog/Neu-in-NET-8-0-1-Start-der-neuen-Blogserie-9574680.html
[3] https://www.heise.de/blog/Neu-in-NET-8-0-2-Neue-Anwendungsarten-9581213.html
[4] https://www.heise.de/blog/Neu-in-NET-8-0-3-Primaerkonstruktoren-in-C-12-0-9581346.html
[5] https://www.heise.de/blog/Neu-in-NET-8-0-4-Collection-Expressions-in-C-12-0-9581392.html
[6] https://www.heise.de/blog/Neu-in-NET-8-0-5-Typaliasse-in-C-12-0-9594693.html
[7] https://www.heise.de/blog/Neu-in-NET-8-0-6-ref-readonly-in-C-12-0-9602188.html
[8] https://www.heise.de/blog/Neu-in-NET-8-0-7-Optionale-Parameter-in-Lambda-Ausdruecken-in-C-12-0-9609780.html
[9] https://www.heise.de/blog/Neu-in-NET-8-0-8-Verbesserungen-fuer-nameof-in-C-12-0-9616685.html
[10] https://www.heise.de/blog/Neu-in-NET-8-0-9-Neue-und-erweiterte-Datenannotationen-9623061.html
[11] https://www.heise.de/blog/Neu-in-NET-8-0-10-Plattformneutrale-Abfrage-der-Privilegien-9630577.html
[12] https://www.heise.de/blog/Neu-in-NET-8-0-11-Neue-Zufallsfunktionen-9637003.html
[13] https://www.heise.de/blog/Neu-in-NET-8-0-12-Eingefrorene-Objektmengen-9643310.html
[14] https://www.heise.de/blog/Neu-in-NET-8-0-12-Leistung-von-FrozenSet-9649523.html
[15] https://www.heise.de/blog/Neu-in-NET-8-0-14-Neue-Waechtermethoden-fuer-Parameter-9656153.html
[16] https://www.heise.de/blog/Neu-in-NET-8-0-15-Geschluesselte-Dienste-bei-der-Dependency-Injection-9662004.html
[17] https://www.heise.de/blog/Neu-in-NET-8-0-16-Neue-Methoden-fuer-IP-Adressen-9670497.html
[18] https://www.heise.de/blog/Neu-in-NET-8-0-17-Zeitabstraktion-fuer-Tests-mit-Zeitangaben-9675891.html
[19] https://www.heise.de/blog/Neu-in-NET-8-0-18-Ein-Zeitraffer-mit-eigenem-FakeTimeProvider-9683197.html
[20] https://www.heise.de/blog/Neu-in-NET-8-0-19-Razor-HTML-Rendering-in-beliebigen-NET-Anwendungen-9691146.html
[21] https://www.heise.de/blog/Neu-in-NET-8-0-20-Neue-Code-Analyzer-fuer-NET-Basisklassen-9706875.html
[22] https://www.heise.de/blog/Neu-in-NET-8-0-20-Neue-Code-Analyzer-fuer-ASP-NET-Core-9710151.html
[23] https://www.heise.de/blog/Neu-in-NET-8-0-22-Neues-Steuerelement-OpenFolderDialog-fuer-WPF-9722901.html
[24] https://www.heise.de/blog/Neu-in-NET-8-0-23-Verbesserungen-fuer-ZipFile-zur-Arbeit-mit-Dateiarchiven-9722920.html
[25] https://www.heise.de/blog/Neu-in-NET-8-0-24-HTTPS-Proxies-bei-HttpClient-9722968.html
[26] https://www.heise.de/blog/Neu-in-NET-8-0-25-Resilienz-im-HTTP-Client-9763586.html
[27] https://www.heise.de/blog/Neu-in-NET-8-0-26-Anpassung-der-Resilienz-im-HTTP-Client-9773126.html
[28] https://www.heise.de/blog/Neu-in-NET-8-0-27-Konfigurierbare-Namenskonventionen-in-System-Text-Json-8-0-9784360.html
[29] https://www.heise.de/blog/Neu-in-NET-8-0-28-Erweiterung-fuer-die-Deserialisierung-von-JSON-Objekten-9790704.html
[30] https://www.heise.de/blog/Neu-in-NET-8-0-29-Verbesserungen-fuer-den-JSON-Source-Generator-9798297.html
[31] https://www.heise.de/blog/Neu-in-NET-8-0-30-Neue-Datentypen-in-System-Text-Json-8-0-9808793.html
[32] https://www.heise.de/blog/Neu-in-NET-8-0-31-Erweiterte-Serialisierung-in-System-Text-Json-8-0-9814260.html
[33] https://www.heise.de/blog/Neu-in-NET-8-0-32-Weitere-Neuerungen-in-System-Text-Json-8-0-9821053.html
[34] https://www.heise.de/blog/Neu-in-NET-8-0-33-Erweiterung-des-AOT-Compilers-9829857.html
[35] https://www.heise.de/blog/Neu-in-NET-8-0-34-Verbesserte-Ausgaben-beim-Kompilieren-9837144.html
[36] https://net.bettercode.eu/
[37] https://net.bettercode.eu/index.php#programm
[38] https://net.bettercode.eu/tickets.php
[39] mailto:rme@ix.de

Copyright © 2024 Heise Medien

Adblock test (Why?)

Null Problemo: Bessere Null-Checks in Java mit JSpecify

Das Open-Source-Projekt JSpecify zielt auf einheitlichen Standard für Null-Annotationen in Java. Beteiligt sind Firmen wie Google, JetBrains und Microsoft.

Vor einem Jahr habe ich bereits über Null-Checks in Java [1] geschrieben. Nach wie vor ist es sinnvoll, Parameter von Methoden und Konstruktoren mit Annotationen bezüglich des Verhaltens von null (z.B. @NonNull) zu versehen. Mittlerweile ist der Support jedoch deutlich besser geworden, da vor Kurzem Version 1.0 von JSpecify [2] erschienen ist. Das möchte ich für ein Update zu dem Thema nutzen.

Breite Zusammenarbeit für JSpecify

JSpecify ist ein Open-Source-Projekt [3], in dem sich die bisherigen Anbieter von Null-Handling-Annotationen zusammengeschlossen haben, um endlich einen nutzbaren Standard zu definieren. Dazu gehören unter anderem Google, JetBrains, Meta, Microsoft und Oracle. JSpecify ist ein vollwertiges Modul im Java-Modulsystem, hat keine eigenen Abhängigkeiten und liefert mit gerade einmal vier Annotationen alles, was man in einem modernen Java-Projekt benötigt, um das Handling von null bei Parametern zu spezifizieren. Beispielcode, der die Annotationen nutzt, könnte wie folgt aussehen:

static @Nullable String emptyToNull(@NonNull String x) {
    return x.isEmpty() ? null : x;
}

static @NonNull String nullToEmpty(@Nullable String x) {
    return x == null ? "" : x;
}

Mehr Codebeispiele finden sich im User-Guide von JSpecify [4].

Das reine Anbringen der JSpecify-Annotation hat allerdings wenig Effekt. Der Compiler übersetzt weiterhin Code, der null an einen mit @NonNull-annotierten Parameter übergibt, und bei der Laufzeit löst der übersetzte Code nicht automatisch eine Exception aus.

Vorteile der Annotationen

Der Vorteil der Annotationen zeigt sich unter anderem im Zusammenspiel mit Entwicklungsumgebungen. IntelliJ kann die Annotations erkennen [5] und Warnungen oder Fehler bei Code anzeigen, der die Annotationen verletzt. Will man auf Nummer sicher gehen und Code mit solchen Problemen überhaupt nicht zulassen, kann man zusätzliche Hilfsmittel verwenden. Das von Uber entwickelte Open-Source-Tool NullAway [6] kann diese Annotationen zur Build-Zeit überprüfen und Fehler auszulösen, wenn die Definition der Annotationen nicht eingehalten wird. Fügt man das Ganze zu seinem Gradle- oder Maven-Build hinzu, erfolgt beim Kompilieren automatisch einen Fehler:

error: [NullAway] passing @Nullable parameter 'null' where @NonNull is required
   myMethod(null);
          ^

Mit dieser Toolchain kann man seinen Code um einiges robuster bekommen und NullPointerExceptions zur Laufzeit vermeiden.

Kein Allheilmittel

Muss man sich keine Gedanken mehr über NullPointerExceptions machen? So einfach ist es leider nicht. Diese Maßnahmen können nur den eigenen Code überprüfen. Hat man Abhängigkeiten, die keine solchen Annotationen nutzen, kann man nicht wissen, ob man diesen als Parameter null übergeben kann und welches Verhalten dies auslöst. Daher ist es weiterhin wichtig, an verschiedenen Stellen Variablen auf null zu überprüfen.

Wer Libraries oder Code entwickelt, der von anderen Projekten aufgerufen wird, kann nicht sicherstellen, dass Nutzer sich an die definierten Regeln halten und an einen mit @NonNull annotierten Parameter auch wirklich kein null übergeben. Daher ist es wichtig, immer Null-Checks durchzuführen, wenn man den Kontext des eigenen Codes verlässt – egal ob bei eigenen Abhängigkeiten oder bei einer öffentlichen API.

Dazu ist das aus dem OpenJDK stammende java.util.Objects.requireNonNull(obj, message) weiterhin das Mittel der Wahl. Um immer sinnvolle Exceptions zu erstellen, sollte man auf die Variante mit dem Message-Parameter setzen, da das System sonst eine NullPointerException ohne Message wirft. Das Ganze sieht für eine öffentliche API folgendermaßen aus:

public void setName(@NonNull String name) {
   this.name = Objects.requireNonNull(name, “name must not be null”);
}

Wer einem performancekritischen Umfeld arbeitet, sollte auf eigene Methoden für die Checks verzichten. Der JIT-Compiler behandelt Objects.requireNonNull(...) durch die Annotation @ForceInline besonders und fügt alle Aufrufe der Methode direkt in die aufrufende Methode ein (inline), um so Performance und Stack-Größe zu optimieren.

Nächste Schritte zu Best Practices und einem Standard

Es hat lange gedauert, bis die Java-Community den heutigen Stand erreicht hat und es eine saubere und sinnvolle Bibliothek mit Annotationen bezüglich Null-Handling gibt. Was als JSR305 [7] im Jahr 2006 gestartet und leider schnell wieder fallengelassen wurde, könnte sich nach vielen Problemen mit unterschiedlichsten Annotationen und Umsetzungen zu einem De-facto-Standard wie SLF4J (Simple Logging Facade for Java) entwickeln.

JSpecify geht hier ganz klar den richtigen Weg. Toll wäre es, wenn nun ein Tooling wie beispielsweise NullAway sich durchsetzt und mit einer einfachen Nutzung und Best Practices es quasi jedem Projekt ermöglicht, besser mit null umzugehen. Wer bisher die Annotationen und Tools wie NullAway noch nicht im Einsatz hat, sollte sie ausprobieren. Jetzt ist der richtige Moment, um damit zu starten.

Anmerkung: Parallel zum Schreiben dieses Beitrags ist im OpenJDK mit einem neuen JEP [8] ein besserer nativer Support angekündigt worden. Da es noch einige Zeit dauern wird, bis die im JEP diskutierten Features Einzug in eine LTS Version des OpenJDK haben werden, sind die hier beschriebenen Mittel und Tools weiterhin eine klare Empfehlung. Das JEP bietet aber genug Aspekte, um es zeitnah in einem Artikel genauer zu betrachten.

URL dieses Artikels:
https://www.heise.de/-9820606

Links in diesem Artikel:
[1] https://www.heise.de/blog/Programmiersprache-Java-Null-Fehler-mit-statischer-Analyse-aufspueren-7351944.html
[2] https://jspecify.dev/
[3] https://github.com/jspecify/jspecify
[4] https://jspecify.dev/docs/user-guide/
[5] https://www.jetbrains.com/help/idea/nullable-notnull-configuration.html
[6] https://github.com/uber/NullAway
[7] https://jcp.org/en/jsr/detail?id=305
[8] https://openjdk.org/jeps/8303099
[9] mailto:rme@ix.de

Copyright © 2024 Heise Medien

Adblock test (Why?)

OpenAI und Microsoft: Der Tragödie zweiter Teil

Wer dachte, dass nach dem Drama um Sam Altman im November 2023 Ruhe bei OpenAI eingekehrt ist, irrt. Das war erst der Anfang. Eine Analyse von Golo Roden.

Auf dem YouTube-Kanal [1] meines Unternehmens (the native web [2]) haben wir im November 2023 ein Video mit dem Titel "OpenAI + Microsoft: Alles inszeniert und manipuliert? [3]" veröffentlicht. Das war damals die Zeit, als der Vorstand von OpenAI Sam Altman unerwartet als CEO entließ, Microsoft ihm und mehreren seiner Gefolgsleute anbot, sie einzustellen und ein eigenes KI-Forschungslabor einzurichten, und Altman nur wenige Tage später wieder als CEO von OpenAI zurückkehrte, als wäre nichts geschehen.

Dieses Hin und Her gefiel insbesondere Microsoft nicht, da sie zu diesem Zeitpunkt bereits über 12 Milliarden Euro in OpenAI investiert hatten und selbstverständlich erwartet hätten, frühzeitig über Altmans Entlassung informiert zu werden. Doch das geschah offenbar nicht, und das Ergebnis war, dass sich (zumindest oberflächlich gesehen) letztlich nichts änderte – außer, dass Microsoft einen Sitz im Vorstand von OpenAI erhielt, wenn auch ohne Stimmrechte, als sogenannter "Board Observer".

Man hätte denken können, dass das Kindergartentheater um OpenAI damit abgeschlossen wr, doch weit gefehlt – tatsächlich war es nämlich erst der Anfang: Inzwischen hat die Angelegenheit nämlich in gewissem Sinne amüsante, zugleich aber auch besorgniserregende Entwicklungen genommen …

März 2024: Microsoft AI

Dieses Mal beginnt die Geschichte im März 2024: Microsoft entschließt sich, eine eigene Abteilung für Künstliche Intelligenz namens "Microsoft AI" zu gründen. Als Leiter dieser Abteilung engagieren sie Mustafa Suleyman, einen der Mitbegründer von DeepMind, jenem Unternehmen, das unter anderem AlphaGo entwickelt hat – die KI, die besser Go spielt als jeder Mensch. Eine nicht nur damals durchaus beachtliche Leistung im Bereich der Künstlichen Intelligenz.

DeepMind wird 2014 dann von Google gekauft, wo Suleyman bis 2019 tätig ist, bevor er aufgrund von Vorwürfen über unangemessenes Verhalten gegenüber Mitarbeitern das Unternehmen verlässt. Man sagt ihm nach, sein Führungsstil habe nicht den Standards entsprochen, die Google im Management erwarte. Das lässt viel Spielraum für Interpretationen, aber fest steht zumindest, dass Suleyman nun Microsoft AI leitet. Aus technischer Sicht ist er sicherlich sehr begabt, menschlich allerdings nicht unumstritten.

Unabhängig von seiner Person muss man sich jedoch vor Augen führen, dass Microsoft trotz ihrer Investitionen in OpenAI auf diesem Weg eine eigene KI-Abteilung aufbaut, was durchaus als Konkurrenz zu OpenAI gewertet werden könnte.

Juni 2024: Die WWDC von Apple

Springen wir vor in den Juni 2024: Apple veranstaltet wie jeden Sommer die World Wide Developers Conference (WWDC) und verkündet stolz, dass zukünftig KI-Funktionalitäten direkt in die Betriebssysteme iOS, iPadOS und macOS integriert werden. Siri soll erheblich verbessert werden, nicht nur in der Erkennung und Ausgabe von Sprache, sondern auch bei der Handschrifterkennung und der Kontextualisierung von Informationen.

Die Frage ist natürlich: Wie machen sie das? Hat Apple etwas Eigenes entwickelt? Und tatsächlich: Ja, Apple kündigt auf dieser WWDC auch einen neuen Dienst namens Apple Intelligence an, doch für die zuvor genannten Funktionen greift Apple (und das kommt überraschend) auf ChatGPT zurück [5]. Das heißt, plötzlich nutzt ein weiteres großes Tech-Unternehmen neben Microsoft die Dienste von OpenAI, was Microsoft sicherlich nicht erfreut haben dürfte. Insbesondere, wenn man bedenkt, dass Microsoft innerhalb weniger Jahre über 12 Milliarden Euro in OpenAI investiert hat.

Wer denkt, Apple habe ebenfalls eine beträchtliche Summe bezahlt, irrt sich: Die Kooperation mit OpenAI kostet Apple nämlich keinen einzigen Cent [6]. Das öffentlich genannte Argument dafür lautet, dass es sich um eine Win-Win-Situation handele, da OpenAI von der massiven Verbreitung auf Apple-Geräten ebenfalls profitieren würde. Ich will nicht so weit gehen zu behaupten, dass Microsoft damit 12 Milliarden Euro in den Sand gesetzt hätte, aber dass das ein harter Schlag ins Gesicht ist, darüber müssen wir sicherlich nicht diskutieren.

Juli 2024: Das Hin und Her im Vorstand von OpenAI

Aber es kommt noch besser: Drei Wochen nach der WWDC wird bekannt, dass auch Apple einen Sitz im Vorstand von OpenAI [7] erhält, ebenfalls als Board Observer, was Microsoft natürlich ebenfalls wenig gefallen haben dürfte. Die Person, die diesen Posten für Apple übernehmen soll, ist dabei übrigens niemand Geringeres als Phil Schiller, früherer Marketing-Chef von Apple und zuletzt Leiter des App-Stores.

Genau eine Woche später, am 10. Juli, gibt Microsoft dann überraschend seinen Sitz im Vorstand von OpenAI auf. Das wirkt auf den ersten Blick wie kindisches Verhalten, ist es aber nicht, denn am selben Tag gibt auch Apple überraschend seinen Sitz im Vorstand wieder auf [8] – wohlgemerkt nach gerade einmal einer Woche.

Da fragt man sich natürlich, was dieses Hin und Her soll: Was sind die Gründe dafür? Es wirkt durchaus seltsam, dass die Vertreter von Microsoft und Apple am selben Tag den Vorstand von OpenAI verlassen, wo Apple gerade erst eine Woche dort vertreten war. Dahinter steckt, wie man inzwischen weiß, die US-amerikanische Börsenaufsicht beziehungsweise die Kartellbehörde. Denn auch wenn es den Anschein hat, dass man in der Technologiebranche in den USA mehr oder weniger tun und lassen kann, was man will, hat doch alles seine Grenzen: Und die Behörden in den USA fangen an, unruhig zu werden, weil ihnen der Einfluss der großen Tech-Konzerne (in diesem Fall also von Microsoft und Apple) auf ein für die Zukunft der Menschheit potenziell relevantes Unternehmen wie OpenAI doch etwas zu weit geht.

Wer sich einmal näher mit der Geschichte von Microsoft im Hinblick auf das Kartellrecht beschäftigt hat, weiß, dass die USA da zumindest in der Vergangenheit sehr entspannt waren. Wenn also selbst die jetzt unruhig werden, dann hat das schon etwas zu bedeuten …

August 2024: Von Partnern zu Konkurrenten

Kommen wir nun zum 25. Juli 2024, also weitere zwei Wochen später. OpenAI kündigt an diesem Tag ein neues Produkt an, nämlich SearchGPT [9], eine Mischung aus Künstlicher Intelligenz und Suchmaschine, um zu demonstrieren, wie sie sich die Zukunft der Informationsbeschaffung vorstellen. Dieses Thema beschäftigt auch Google schon seit Längerem, und vermutlich arbeiten auch alle anderen Suchmaschinenbetreiber an einer sinnvollen und zielgerichteten Integration von Künstlicher Intelligenz und Suche.

OpenAI zeigt an diesem Tag jedoch noch gar nichts Konkretes, sondern veröffentlicht lediglich einen Blogpost und ein Video, in dem SearchGPT präsentiert wird. Es wird noch nicht einmal ein Prototyp gezeigt, sondern lediglich ein Video davon. Aktuell kann man sich bei OpenAI auf einer Warteliste eintragen [10], doch über kurz oder lang soll SearchGPT in ChatGPT integriert werden.

Diese Ankündigung, verbunden mit der gesamten Vorgeschichte, führt dann schließlich dazu, dass Microsoft am 1. August 2024 in ihrem neuen Jahresbericht plötzlich OpenAI als Konkurrenz in den Bereichen KI und Suche [11] aufführt. OpenAI reiht sich damit in eine illustre Gesellschaft zwischen Apple, Amazon, Google und Meta ein. Natürlich mag ich mich täuschen, aber mich beschleicht zunehmend das Gefühl, dass Microsoft die Richtung, in die sich OpenAI entwickelt, nicht mehr so recht gefällt.

OpenAI lässt es sich nicht nehmen, das Ganze prompt zu kommentieren und erklärt, Microsoft sei weiterhin ein wichtiger Partner, man sei die Partnerschaft von vornherein in dem Bewusstsein eingegangen, dass es zu Wettbewerb kommen könne, und so weiter – aber trotzdem bin ich da skeptisch.

Es geht immer nur ums Geld

Insgesamt erinnert mich die ganze Geschichte sehr an ein Drehbuch für ein paar Folgen "Gute Zeiten, schlechte Zeiten" (oder eine beliebige andere Soap). Auch dort gibt es regelmäßig absurde Dramen, mit viel Hin und Her, wer jetzt mit wem, und so weiter. Der einzige Unterschied ist, dass es hier nicht um eine seichte Fernsehserie geht, sondern um die weltweit mächtigsten Milliarden-Konzerne und eine der wichtigsten Zukunftstechnologien. Und ich weiß nicht, wie es Ihnen damit geht, aber mir persönlich behagt es überhaupt nicht, dass es bei diesem Hin und Her offensichtlich ausschließlich um finanzielle Interessen und Marktmacht geht, und dass es überhaupt nicht um die Frage geht, wie oder ob diese Technologie zum Wohl der Menschheit eingesetzt wird, ob sie in die richtige Richtung entwickelt wird, ob ethische Fragen berücksichtigt werden, und so weiter.

Natürlich kann man sagen, es sei auch nicht die Aufgabe von Konzernen, sich um derartige Fragen zu kümmern, aber dann muss man vielleicht auch sagen, dass das zwar richtig ist, solche Technologien dann aber vielleicht auch nicht in deren Hände gehören. Ich persönlich finde das äußerst bedenklich. Und das Schlimme daran ist, dass, als OpenAI vor fast zehn Jahren gegründet wurde, genau dies das Ziel war: Eine gemeinnützige Organisation zu schaffen, die sich mit der Entwicklung von Künstlicher Intelligenz und deren Vereinbarkeit mit dem Wohl und der Zukunft der gesamten Menschheit beschäftigt.

Davon ist heute nichts mehr übrig. Und es ist auch klar, warum: Die großen Konzerne, allen voran Microsoft, haben daran keinerlei Interesse. Am Ende des Tages geht es nämlich (wie immer) nur ums Geld. Microsoft ist die Moral dabei völlig egal, solange es eine Menge Geld zu verdienen gibt. Warum ich da nun speziell Microsoft anprangere? Ganz einfach: OpenAI erhielt als gemeinnützige Organisation kaum Forschungsgelder, auch nicht von Microsoft. Doch kaum wurde der finanziell orientierte Ableger von OpenAI gegründet, war Microsoft sofort mit Milliarden-Investitionen dabei. Das zeigt mehr als deutlich, worum es Microsoft ausschließlich geht.

Von der gemeinnützigen Organisation zum finanziell orientierten Unternehmen

Natürlich ist es völlig legitim, als Unternehmen Geld verdienen zu wollen, das ist ja sogar der Sinn eines Unternehmens. Aber man darf dabei meiner Meinung nach nicht über Leichen gehen. Und genau das werfe ich Microsoft vor: Ihnen ist alles egal, Hauptsache, ihr Stück vom Kuchen wird noch größer. Falls Sie übrigens noch einmal mehr über die Entstehungsgeschichte von OpenAI und den Wandel von einer gemeinnützigen Organisation hin zu einem finanziell ausgerichteten Unternehmen erfahren möchten, dann lege ich Ihnen das am Anfang erwähnte Video "OpenAI + Microsoft: Alles inszeniert und manipuliert? [12]" nahe.

Insofern ist es schon eine gewisse Ironie der Geschichte, dass die Kooperation von Apple und OpenAI nun ausgerechnet Microsoft auf die Füße fällt. Mein persönliches Mitleid hält sich da ehrlich gesagt sehr in Grenzen. Bitte verstehen Sie mich nicht falsch, ich halte Apple und auch die anderen großen Tech-Konzerne wie Amazon, Google, Meta, und so weiter, nicht für Heilige. Mir ist klar, dass sich all diese Unternehmen in vielen Situationen genauso verhalten, nur in diesem Fall ist es eben konkret Microsoft, deren Kartenhaus zusammenstürzt. Und irgendwie empfinde ich persönlich das nicht als ganz unverdient.

Was fehlt, ist ein unabhängiges Konsortium

Das wirklich Besorgniserregende ist jedoch, dass hier mit einer der wichtigsten Zukunftstechnologien gespielt wird, und das hinterlässt einfach kein gutes Gefühl, wenn das in den Händen von Konzernen liegt. Tatsächlich würde es mich allerdings auch nicht beruhigen, wenn es stattdessen Staaten wären, die beteiligt sind. Dann wären es eben diese, die damit spielen. Meiner Meinung nach gehört eine solche Technologie in die Hände eines unabhängigen, idealerweise internationalen Konsortiums, in die Hände einer Stiftung, oder einer ähnlichen Organisation.

Das fordere ich übrigens nicht zum ersten Mal: Ich habe in Bezug auf kritische, weltweite Infrastruktur schon des Öfteren darauf hingewiesen, beispielsweise beim Kauf von GitHub, was damals übrigens auch Microsoft war. Auch dort hätte ich es wesentlich lieber gesehen, wenn GitHub an eine Stiftung gegangen wäre, die Microsoft gerne hätte mitfinanzieren können – aber daran besteht offensichtlich kein Interesse.

Man muss natürlich auch die Frage stellen, wer so etwas überhaupt leisten könnte. Wer wäre ein internationales Konsortium, das unabhängig von Staaten und Konzernen agiert und das Wohl der gesamten Menschheit im Blick hat? Ich habe länger darüber nachgedacht, und mit viel gutem Willen fallen mir am ehesten die Vereinten Nationen ein, insbesondere die UNESCO, da sie sich mit Bildung, Wissenschaft und Kultur befassen. Aber so richtig passt das irgendwie nicht. Man könnte auch an das IEEE denken, denn dessen Zweck ist tatsächlich die "Förderung technologischer Innovationen zum Nutzen der Menschheit". Das Problem ist nur, dass sich das IEEE stark auf die technische Seite konzentriert, auf Standards und Ähnliches, und weniger auf die ethische Seite. Zumindest in der Theorie könnte man auch noch an das World Economic Forum (WEF) denken, aber offen gesagt: Das scheint mir doch sehr wirtschaftsgetrieben zu sein und weniger vom Ideal einer besseren Welt geleitet.

KI ist (gefühlt) weit weg

Doch selbst wenn eine dieser Organisationen zuständig wäre, sind sie alle zu weit vom Alltag eines durchschnittlichen Menschen entfernt. Wenn man einfach irgendjemanden auf der Straße nach ihrer oder seiner Meinung zum Thema Künstliche Intelligenz fragt, dann haben die meisten dazu tatsächlich überhaupt keine Meinung. Denn für die meisten Menschen ist Künstliche Intelligenz eine völlig abstrakte und sehr weit entfernte Entwicklung. Künstliche Intelligenz kommt im Leben der meisten Menschen nicht bewusst vor, und wir müssen uns hüten, uns Informatikerinnen und Informatiker da als das Maß der Dinge zu sehen.

Der Durchschnittsmensch ist am ehesten noch ein Konsument von Künstlicher Intelligenz, aber selbst das ist bei vielen Menschen noch lange nicht der Fall. Und trotzdem hat Künstliche Intelligenz sehr viel mehr Auswirkungen auf die meisten Menschen, als sie glauben: Das beginnt schon beim Konsum von Nachrichten, betrifft also ganz schnell beispielsweise den politischen Bereich. Es geht um die Frage, ob Sie bei Ihrer nächsten Bewerbung den Job bekommen oder nicht. Es betrifft unsere Kinder in der Schule und in den Hochschulen. Und, und, und.

Aber das meiste davon passiert eben unsichtbar. Und das wiederum wird sich nur ändern, wenn wir aufklären und bilden: Wenn Künstliche Intelligenz in der Bildung weder verteufelt noch kritiklos in den Himmel gelobt wird. Wenn es eine ernsthafte gesellschaftliche Auseinandersetzung mit den Folgen von Künstlicher Intelligenz auf breiter Basis gibt. Doch das hat schon bei den Themen Medienkonsum und Social Media nicht funktioniert, und das war noch Themen, die im Vergleich sehr viel greifbarer waren.

Eine gesellschaftliche Herausforderung

Hier haben wir meiner Meinung nach ein riesiges gesellschaftliches Problem, das immer größer wird: nämlich die Unwissenheit und die daraus resultierende Gleichgültigkeit gegenüber diesen Technologien. Solange die meisten Menschen glauben, dass Künstliche Intelligenz sie nicht zu interessieren braucht, weil sie sie vermeintlich nicht betrifft, wird niemand aufstehen und versuchen, die eingeschlagene Richtung zu verändern.

Übrigens: Auch wenn ich die aktuelle Umsetzung für unglaublich schlecht und innovationsfeindlich halte, ist die einzige Institution, die mir noch einfällt und die tatsächlich versucht, etwas in dieser Richtung zu bewegen, die EU: Der AI Act ist in seiner jetzigen Form für mein Empfinden eine ziemliche Katastrophe, aber zumindest versucht dort jemand, Regeln und Richtlinien aufzustellen. Allerdings ist das, wie so oft in der EU, nur reaktiv, nicht proaktiv. Denn viel mehr passiert in der EU nicht: Es gibt keine europäische KI-Forschung im großen Stil. Und wenn ich an andere europäische IT-Projekte denke, wie das Cloud-Projekt Gaia-X, dann habe ich da leider auch keine allzu große Hoffnung.

Für mein Empfinden klafft da eine große Lücke, um die sich dringend jemand kümmern müsste – und zwar jemand, der die gesamte Menschheit vertritt. Aber ich sehe aktuell nicht, wer das sein oder wie das funktionieren könnte. Doch wenn wir nicht immer mehr zu Spielbällen der Tech-Konzerne werden wollen, wenn wir wollen, dass unsere Kinder in einer selbstbestimmten Welt leben können, dann muss sich dringend etwas ändern.

Was ich persönlich dazu beitragen kann, ist, andere Entwicklerinnen und Entwickler immer wieder einmal auf dieses Thema aufmerksam zu machen, zum Beispiel mit Blogposts wie diesem, und zu hoffen, dass der Artikel Gehör findet und sich verbreitet. Insofern: Wenn Sie mir einen großen Gefallen tun wollen, teilen Sie diesen Blogpost, schicken Sie ihn an Menschen, die Sie kennen und bei denen Sie denken, dass das Ganze auf fruchtbaren Boden fällt, und tragen Sie dazu bei, die Botschaft in die Welt hinauszutragen.

URL dieses Artikels:
https://www.heise.de/-9829408

Links in diesem Artikel:
[1] https://www.youtube.com/@thenativeweb
[2] https://www.thenativeweb.io/
[3] https://www.youtube.com/watch?v=tOegaUmPe4c
[4] https://www.heise.de/Datenschutzerklaerung-der-Heise-Medien-GmbH-Co-KG-4860.html
[5] https://openai.com/index/openai-and-apple-announce-partnership/
[6] https://www.heise.de/news/Apple-und-OpenAI-Angeblich-fliesst-kein-Geld-fuer-ChatGPT-9764460.html
[7] https://www.heise.de/news/Phil-Schiller-als-Beobachter-im-Aufsichtsrat-OpenAI-bindet-Apple-naeher-an-sich-9787806.html
[8] https://www.heise.de/news/Kehrtwende-Apple-offenbar-doch-nicht-im-Aufsichtsrat-von-OpenAI-9796884.html
[9] https://openai.com/index/searchgpt-prototype/
[10] https://chatgpt.com/search
[11] https://www.heise.de/news/Microsoft-betrachtet-OpenAI-jetzt-als-Konkurrenten-bei-KI-und-Internet-Suche-9823628.html
[12] https://www.youtube.com/watch?v=tOegaUmPe4c
[13] mailto:rme@ix.de

Copyright © 2024 Heise Medien

Adblock test (Why?)

Neu in .NET 8.0 [33]: Erweiterung des AOT-Compilers

Der AOT-Compiler kann auch Webservices und Hintergrunddienste übersetzen, aber mit einigen Einschränkungen.

Mit .NET 7.0 liefert Microsoft erstmals einen Ahead-of-Timer-Compiler (AOT), der es erlaubt, .NET-Anwendungen komplett in Maschinencode ohne Just-in-Time-Kompilierung zur Laufzeit auszuliefern. Der "Native AOT" genannte Compiler konnte in .NET 7.0 jedoch nur Konsolenanwendungen übersetzen.

Seit .NET 8.0 sind nun zusätzlich auch folgende Anwendungsarten beim AOT-Compiler möglich:

• Hintergrunddienste (Worker Services)
• gRPC-Dienste
• WebAPIs mit Einschränkungen: Bei den WebAPIs ist lediglich das "Minimal WebAPI" genannte Modell möglich, mit JSON-Serialisierung via System.Text.Json im Source-Generator-Modus.

Weitere Einschränkungen zeigt folgende Abbildung:

Hinweis: Native AOT funktioniert weiterhin dort nicht, wo es am nötigsten wäre, um die Startzeit und den RAM-Bedarf zu verringern: Windows Forms und WPF.

Den Source Generator in System.Text.Json hat Microsoft ausgebaut, sodass er nun fast alle Konfigurationsoptionen wie der Reflection-basierte Modus kennt. Zudem funktioniert der Source-Generator jetzt zusammen mit den Init Only Properties aus C# 9.0 und den Required Properties aus C# 11.0. Den alten Reflection-Modus kann man durch eine Projekteinstellung komplett deaktivieren. Den Modus prüft die Bedingung

if (JsonSerializer.IsReflectionEnabledByDefault) { … }

Neue Native AOT-Option in Projektvorlagen

Neu in .NET 8.0 ist auch, dass es bei einigen Projektvorlagen nun direkt möglich ist, den AOT-Compiler mit der Kommandozeilenoption —aot oder mit einem Häkchen in Visual Studio zu aktivieren:

• Konsolenanwendung: dotnet new console –aot
• Worker Service: dotnet new worker –aot
• gRPC: dotnet new grpc –-aot

Bei der Projektvorlage für ASP.NET Core WebAPIs (Kurzname webapi) gibt es keine Option —aot und kein Häkchen in Visual Studio. Hier hat sich Microsoft entschlossen, eine eigene Projektvorlage zu bauen "ASP.NET Core WebAPI (native AOT)" mit Kurznamen webapiaot. Die verwendet auch nicht das bisher in der WebAPI-Projektvorlage übliche Beispiel mit Wetterdaten, sondern eine Aufgabenliste.

Unterschiede zum normalen Minimal WebAPI-Template sind:

• WebApplication.CreateSlimBuilder() statt CreateBuilder()
• JSON-Serialisierung via Source-Generator

Folgender Code liefert eine Aufgabenliste statt einer Wettervorhersage:

using System.Text.Json.Serialization;
 
namespace MinimalWebAPI_AOT;
public class Program
{
 public static void Main(string[] args)
 {
  var builder = WebApplication.CreateSlimBuilder(args);
 
  builder.Services.ConfigureHttpJsonOptions(options =>
  {
   options.SerializerOptions.TypeInfoResolverChain.Insert(0, AppJsonSerializerContext.Default);
  });
 
  var app = builder.Build();
 
  var sampleTodos = new Todo[] {
            new(1, "Walk the dog"),
            new(2, "Do the dishes", DateOnly.FromDateTime(DateTime.Now)),
            new(3, "Do the laundry", DateOnly.FromDateTime(DateTime.Now.AddDays(1))),
            new(4, "Clean the bathroom"),
            new(5, "Clean the car", DateOnly.FromDateTime(DateTime.Now.AddDays(2)))
        };
 
  var todosApi = app.MapGroup("/todos");
  todosApi.MapGet("/", () => sampleTodos);
  todosApi.MapGet("/{id}", (int id) =>
      sampleTodos.FirstOrDefault(a => a.Id == id) is { } todo
          ? Results.Ok(todo)
          : Results.NotFound());
 
  app.Run();
 }
}
 
public record Todo(int Id, string? Title, DateOnly? DueBy = null, bool IsComplete = false);
 
[JsonSerializable(typeof(Todo[]))]
internal partial class AppJsonSerializerContext : JsonSerializerContext
{
 
}

Hinweis: Alternativ kann man den Native AOT Compiler auch wie bisher nachträglich per Tag in der Projektdatei aktivieren:

<PublishAot>true</PublishAot>

und konfigurieren:

<IlcOptimizationPreference>Speed</IlcOptimizationPreference>

oder:

<IlcOptimizationPreference>Size</IlcOptimizationPreference>

Auch bei dotnet publish lässt sich Native AOT noch aktivieren:

dotnet publish -r win-x64 -c Release -p:PublishAOT=true

Warnungen bei inkompatiblem Code

Wer den AOT-Compiler für ein ASP.NET-Core-Projekt aktiviert, erhält seit .NET 8.0 Warnungen beim Aufruf von Methoden, die nicht kompatibel mit dem AOT-Compiler sind:

Native AOT für Apple-Betriebssysteme

Microsoft ermöglicht es seit .NET 8.0, .NET-Anwendungen für iOS, Mac Catalyst und tvOS mithilfe des neuen .NET-Native-AOT-Compilers zu kompilieren. Diese Möglichkeit gibt es sowohl für Apps, die auf diese Plattformen beschränkt sind (.NET for iOS), als auch für das .NET Multi-Platform App UI (.NET MAUI). Dadurch laufen die Anwendungen nicht mehr auf Mono, und die App-Pakete für ".NET for iOS" werden spürbar kompakter. Hingegen verzeichnen die App-Pakete für .NET MAUI eine Zunahme in ihrer Größe.

In einem Blogeintrag [2] bestätigt Microsoft, dass die Firma das Problem erkannt hat und aktiv an einer Lösung arbeitet, die zu einem Größenvorteil von etwa 30 Prozent führen soll.

Mögliche und nicht mögliche Operationen bei AOT

Datenbankzugriffe sind beim AOT-Compiler weiterhin nicht mit dem Objekt-Relationalen Mapper Entity Framework Core möglich, da dieser immer noch Laufzeitkompilierung verwendet. Gleiches gilt für den zweitwichtigsten OR-Mapper der .NET-Welt, den Micro-ORM Dapper [4]. In AOT-kompilierten Anwendungen können Entwicklerinnen und Entwickler derzeit nur DataReader, DataSet und Command-Objekte aus ADO.NET oder das GitHub-Projekt NanORM [5] verwenden.

Folgendes ist mit Native AOT auch in .NET 8.0 nicht möglich, selbst wenn man eine der oben aufgeführten Anwendungsarten erstellt:

• Laufzeitcodegenerierung (Reflection Emit)
• Dynamisches Nachladen von Assemblies (Add-Ins/Plug-Ins)
• Component Object Model (COM)
• Windows Runtime-APIs (WinRT)
• Windows Management Instrumentation (WMI)
• Zugriff auf Active Directory Services
• C++/CLI
• AOT mit WebAPIs in den Internet Information Services (IIS)
• Entity Framework Core
• Dapper
• JSON-Serialisierung mit JSON.NET (Newtonsoft JSON)
• AutoMapper und viele andere Drittanbieterbibliotheken

Möglich sind dagegen unter anderem

• Reguläre Ausdrücke
• Dateisystemzugriffe
• JSON-Serialisierung mit System.Text.Json
• NET
• NanORM
• Dependency Injection mit Microsoft Dependency Injection-Container (Microsoft.Extensions.DependencyInjection) und AutoFac

Performance von Native AOT

Für .NET 8.0 hat Microsoft Zahlen herausgegeben, welche Auswirkungen der Native-AOT-Compiler auf WebAPIs hat. Man sieht in der Grafik Folgendes:

• Die Größe des Kompilats, der RAM-Bedarf – insbesondere auf Linux – und die Startdauer werden wesentlich geringer.
• Die Ausführungsgeschwindigkeit sinkt aber leider auch etwas, denn der Native-AOT-kompilierte Code schafft weniger Requests per Second (RPS).

URL dieses Artikels:
https://www.heise.de/-9829857

Links in diesem Artikel:
[1] https://learn.microsoft.com/en-us/aspnet/core/fundamentals/native-aot?view=aspnetcore-8.0&tabs=netcore-cli
[2] https://devblogs.microsoft.com/dotnet/announcing-dotnet-8-preview-6/#support-for-targeting-ios-platforms-with-nativeaot
[3] https://devblogs.microsoft.com/dotnet/announcing-dotnet-8-preview-6/#support-for-targeting-ios-platforms-with-nativeaot
[4] https://github.com/DapperLib/Dapper
[5] https://github.com/DamianEdwards/Nanorm
[6] https://net.bettercode.eu/
[7] https://net.bettercode.eu/index.php#programm
[8] https://net.bettercode.eu/tickets.php
[9] mailto:rme@ix.de

Copyright © 2024 Heise Medien

Adblock test (Why?)

Was Softwareentwicklungsteams mit der Dunbar-Zahl und Primaten zu tun haben

Softwareentwicklungsteams sind soziale Systeme. Auch andere Primaten bilden solche sozialen Systeme. Was können wir von den anderen Primaten lernen?

Wie Menschen soziale Organisationen bilden, hat Auswirkungen auf unsere Branche: So gibt es die Frage, wie groß ein Team oder eine Firma zu sein hat. Als Orientierung dient oft die Dunbar-Zahl [1] von 150. Sie soll angeben, mit welcher Gruppengröße Menschen typischerweise noch gut zurechtkommen. Leider ist diese Darstellung schlicht falsch. Dunbars wissenschaftliche Publikation [2] sagt etwas völlig anderes.

Er untersuchte nicht menschliche Primaten, umgangssprachlich fälschlicherweise oft als "Affen" bezeichnet. Das Verhältnis des Volumens ihres Neocortex zum Rest des Gehirns hängt mit der Gruppengröße zusammen, die diese Primaten bilden. Aus diesen Daten extrapoliert Dunbar eine Gruppengröße für Menschen von 147,8. Wie in der Wissenschaft üblich, hat der Wert eine Streuung. Mit 95 % Wahrscheinlichkeit liegt der Wert im Bereich von 100,2 bis 231,1. Ein anderes Paper [3] ergibt völlig andere Bereiche für die Zahl mit 95-%-Konfidenzintervallen im Bereich 3,8 bis 292,0. Das Paper stellt noch einige andere Datenanalysen dar, die aber alle ein Konfidenzintervall von niedrigen einstelligen Werten bis hin zu einigen Hundert aufweisen. Wenn man dieses Paper betrachtet, hat die Zahl keinen praktischen Nutzen.

Aber Dunbar geht es auch nicht so sehr um die Zahl: In Gruppen nutzen Primaten gegenseitige Fellpflege (Grooming), um unter anderem Parasiten zu entfernen, aber auch um sozialen Zusammenhalt zu stärken. Dunbar stellt ein Verhältnis zwischen der Zeit her, die für Fellpflege notwendig ist, und der Größe der Gruppe der Primaten. Größere Gruppen benötigen mehr Fellpflege. Daraus, so Dunbar, würde sich für Menschen ein Zeitaufwand ergeben, der nicht darstellbar ist. Laut Dunbar haben Menschen daher Sprache entwickelt, um effizienter sozialen Zusammenhalt herzustellen. Sprache ist also nicht, wie andere Wissenschaftler und Wissenschaftlerinnen behaupten, zur Koordinierung beim Jagen oder Herstellen von Werkzeugen entstanden, sondern zur Pflege sozialer Beziehungen.

Mit anderen Worten: Dunbars zentrale These ist nicht die Größe der Gruppe, sondern dass menschliche Sprache sich zum Stärken sozialer Beziehungen entwickelt hat.

Die Dunbar-Zahl von 150 ist nur die extrapolierte maximale Größe von Menschengruppen, die Sprache als einen der gemeinsamen Fellpflege vergleichbaren Prozess nutzt. Er spricht von Clan / Village. Daneben nennt er noch andere Gruppen: Bands (Banden) mit 30 bis 50 Personen und Tribes (Stämme) mit 1000 bis 2000 Personen.

Dementsprechend diskutiert Dunbars Paper zahlreiche Beispiele für menschliche Gruppen sehr unterschiedlicher Größe. Gruppen mit einer Größe deutlich anders 150 gehören dann eben zu einer anderen Kategorie, so Dunbar. Seine These ist also definitiv nicht die Größe der Gruppen, sondern die Mechanismen der Gruppe, um sich selbst zu erhalten – und das schreibt er auch selbst so.

Besonders interessant: Dunbar sieht die Gruppen im Militär als eine Bestätigung seiner These, denn es soll dort auch Gruppen einer Größe von 100 bis 200 Menschen geben. Aber natürlich gibt es im Militär auch wesentlich kleinere Gruppen wie einen Trupp (2 bis 8 Soldaten bei der Bundeswehr) oder größere Gruppen wie ein Bataillon (300 bis 1200 Soldaten), die er dann nicht weiter betrachtet.

Zu dem Paper gibt es umfangreiche Kritik anderer Wissenschaftler, sodass praktisch jeder Teil des Papers umstritten ist. Beispielsweise gibt es bezüglich der Gruppengröße Hinweise auf Fission-/Fusion-Verhalten unter Primaten. Das sind Gruppen, zu denen Individuen hinzustoßen und sich dann wieder entfernen. Individuen können etwa an einem Ort gemeinsam schlafen, aber den Tag getrennt verbringen. Solche Gruppen sind also nur temporär. Spezies mit solchem Verhalten benötigen aber nur wenig Zeit für die gemeinsame Fellpflege und sind teilweise deutlich größer. Offensichtlich können Primaten also auch ohne komplexe menschliche Sprache große Gruppen bilden.

Warum ist die Dunbar-Zahl so interessant?

Für die Organisation von menschlichen Teams kann man also aus der Dunbar-Zahl nichts lernen. Dunbar selbst sagt ja, dass es menschliche Gruppen praktisch beliebiger Größe geben kann. Man muss für diese Aussage nicht einmal auf die umfangreiche Kritik zurückgreifen.

In den Kritiken finden sich noch weitere interessante Punkte. So ist es beispielsweise überhaupt nicht klar, warum die Anzahl Menschen, die ein Mensch in irgendeiner Form kennt, eine Gruppengröße beeinflusst. Wenn wir also nur eine bestimmte Anzahl Menschen kennen und mit ihnen regelmäßig sprechen, dann kann eine Gruppe dennoch deutlich größer sein. Es reicht ja, wenn man gemeinsam koordiniert handelt. Dank Sprache können Menschen sich auch in großen Dimensionen bis hin zu Nationen oder darüber hinaus koordinieren. Dass sich Menschen unterschiedlich gut kennen und vertrauen, sollte eigentlich jedem klar sein. Im Projektalltag nutzt man das auch aus. Statt einer Person eine Information direkt zu geben, bittet man eine dritte Person darum, weil das Vertrauensverhältnis zwischen diesen beiden Personen besser ist.

Grund für die Fehlinterpretation

Für mich ist die Fehlinterpretation der Dunbar-Zahl ein Hinweis auf ein grundlegendes Problem: Komplexes menschliches und soziales Verhalten wird simplifiziert. Am Ende steht eine Zahl mit der idealen Größe einer Gruppe. Das ist eine einfache Regel, an die man sich halten kann.

Eigentlich sollte die Intuition jedem etwas anderes sagen. Denn jeder weiß durch das eigene Leben, dass Menschen in unterschiedlichen Gruppen agieren können – im privaten und im beruflichen Kontext: die Firma, der Verein, die Nachbarschaft, die Freunde, die Familie. Die Gruppen sind unterschiedlich groß. Für besonders große Gruppen gibt es Hierarchien wie im Militär, aber auch in Unternehmen mit Team, Abteilungen, Standorten usw.

Diese Gruppen existieren oft nicht lange. Beispielsweise bei einem Training oder beim ersten Consulting-Termin müssen Trainer und Beraterinnen mit einer Gruppe zusammenarbeiten, die sie nie zuvor gesehen haben – und das funktioniert. Das ist sicher eine andere Gruppe, mit einer anderen Art von Beziehung als die eigene Familie, aber eine solche Gruppe hat auch andere Ziele.

Nun kann man argumentieren, dass unter anderem das Vertrauen erst mit der Zeit wächst. Aber auch Vertrauen kann schnell gebildet werden: Wird ein Patient ins Krankenhaus eingeliefert, wird er der behandelnden Ärzt:in im Extremfall sogar sein Leben anvertrauen, ohne die Person vorher jemals gesehen zu haben.

Sicher kann man Dunbars Forschung als Inspiration nutzen, um über Mechanismen für die Stärkung des Zusammenhalts von Gruppen nachzudenken. Dunbars These ist, dass Sprache nur entstanden ist, um sozialen Zusammenhalt zu stärken, und er präsentiert dazu Statistiken, wie viel Zeit mit dem Gespräch über soziale Beziehung und Gossip (Tratsch) verbracht wird. Maßnahmen zum Stärken des Zusammenhalts, beispielsweise durch ungezwungene Gespräche, können sinnvoll sein. Wo gibt es für ein Team ein solches Forum? Das müssen nicht erzwungene Team-Bondings sein, sondern ein regelmäßiges gemeinsames Mittagessen kann eine solche Funktion gut ausfüllen.

tl;dr

Die Dunbar-Zahl sagt nichts über die mögliche Größe von Teams oder Firmen aus. Sie können eine beliebige Größe haben und unterschiedlich strukturiert sein. Die Fehlinterpretation der Zahl deutet darauf hin, dass unsere Branche für Vereinfachungen anfällig ist, die der Intuition widersprechen. Teams benötigen einen Mechanismus, um einen sozialen Zusammenhalt herzustellen.

URL dieses Artikels:
https://www.heise.de/-9825599

Links in diesem Artikel:
[1] https://de.wikipedia.org/wiki/Dunbar-Zahl
[2] https://www.cambridge.org/core/journals/behavioral-and-brain-sciences/article/abs/coevolution-of-neocortical-size-group-size-and-language-in-humans/4290FF4D7362511136B9A15A96E74FEF
[3] https://royalsocietypublishing.org/doi/10.1098/rsbl.2021.0158
[4] mailto:rme@ix.de

Copyright © 2024 Heise Medien

Adblock test (Why?)