Moin.

Im gesellschaftlichen Diskurs geht es bei der Diversität um eine Vielfalt bestimmter Gruppenmerkmale. Als Beispiel für die Vielfalt der Arbeitswelt sei die „Charta der Vielfalt“ genannt: „Ziel der Charta der Vielfalt ist es, ein Arbeitsumfeld zu schaffen, in dem alle Beschäftigten die gleiche Wertschätzung und Förderung erfahren, unabhängig von Nationalität, ethnischer Herkunft, Religion oder Weltanschauung, sozialer Herkunft, Behinderung, Alter sowie sexueller Orientierung und Identität.“ (Wikipedia)

Nun gilt es als akzeptierte Wahrheit, dass diverse Teams besser geeignet sind, um komplexe Probleme zu lösen, die etwa in der Softwareentwicklung auftreten. Bedeutet das, ich sollte in meinem Entwicklerteam alle Weltreligionen und ein paar Nationalitäten vertreten haben?

Nach meiner Erfahrung sind das nicht die Diversitätsfaktoren, die den Unterschied machen. Es kommt auf etwas anderes an. Ein Artikel in Harvard Business Review unterstützt diese Meinung und spricht von „kognitiver Diversität“.

Worauf kommt es an, wenn man ein Team divers aufstellen will? Ohne Anspruch auf Allgemeingültigkeit kann ich folgende Faktoren nennen, bei denen Vielfalt innerhalb eines Teams nach meiner Beobachtung einen positiven Einfluss hat.

Alter und Geschlecht spielen eine Rolle. Einerseits glaube ich, dass Männer und Frauen Probleme tendenziell unterschiedlich angehen. Das ist gerade bei komplexen Aufgaben hilfreich. Genauso sorgt eine größere Altersbandbreite im Team dafür, dass die Teammitglieder sehr verschiedene fachliche Erfahrungen mitbringen.

Die Dauer der Firmenzugehörigkeit ist ebenfalls ein wichtiger Faktor. Es ist hilfreich, wenn der „alte Hase“, der sehr gut vernetzt ist, weiß, wen das Team bei einem Problem ansprechen kann. Auf der anderen Seite laufen die jungen Teammitglieder nicht so leicht Gefahr, ein Problem so anzugehen, „wie wir das immer schon gemacht haben“. Sie bringen neue Ansätze und Sichtweisen ins Team.

Eine große Vielfalt der Perspektiven kommt ins Team, wenn nicht alle Teammitglieder die gleichen Ausbildungen durchlaufen haben. Eine Gruppe von Informatikern wird ein Problem sehr wahrscheinlich mit den Mitteln lösen, die man im Informatikstudium gelernt hat. Kommen weitere Disziplinen hinzu, etwa Sozialwissenschaften, Physik, Philosophie oder Ingenieurwesen, steigt die Zahl der Lösungsansätze. Mein Lehrer im Mathe-Leistungskurs hat gerne eine Geschichte aus der Eigentümerversammlung in seinem Haus erzählt. Bis auf eine Person handelte es sich um Akademiker, ihn selbst eingeschlossen. Wenn im Haus ein Defekt auftrat, haben die Studierten in der Versammlung über ausgefeilte Lösungsansätze diskutiert. In der gleichen Zeit hat der einzige Nicht-Akademiker den Schaden einfach repariert. Diese Anekdote zeigt, dass Monokulturen in der Ausbildung von Teammitgliedern oft nicht zu schlagkräftigen Teams führen.

Auch unterschiedliche Muttersprachen erlebe ich im Team als Bereicherung. Das mag an der damit verbundenen Vielfalt der Kulturen liegen, in denen die Teammitglieder aufgewachsen sind, oder daran, dass Sprache das Denken formt.

Einen weiteren Faktor nenne ich in Anlehnung an ein bekanntes Buch: schnelles Denken, langsames Denken. Manchmal ist es wichtig, schnell voranzuschreiten, um beispielsweise mit einem frühen Prototypen einer Software schnell Nutzer-Feedback zu bekommen. Andererseits ist es hin und wieder gut, ein Problem von allen Seiten zu betrachten, um mit einer fundierten Lösung an die Öffentlichkeit zu gehen. Teams, in denen beide Ansätze durch unterschiedliche Personen vertreten sind, haben oft Konflikte. Wenn sie es aber gelernt haben, die Konflikte in der Sache auszutragen und nicht auf der persönlichen Ebene, ist es eine Stärke, mal einen Schnellschuss machen zu können und ein anderes Mal langsam und gewissenhaft zu arbeiten. Wichtig ist, dass sich die Vertreter der jeweiligen Fraktion im richtigen Moment zurücknehmen können.

Und, last, but not least, schätze ich Softwareteams, die in verschiedenen Programmierparadigmen (imperativ, OO, funktional, Logikprogrammierung) denken können. Zwar ist es oft keine Option, während der Produktentwicklung die Sprache zu wechseln oder eine weitere hinzuzufügen, jedoch erlauben einige Sprachen, mehrere Paradigmen zu verwenden. Als Beispiel sei die funktionale Programmierung genannt, die ehemals ausschließlich in funktionalen Sprachen zu finden war und in den vergangenen Jahren auch in objektorientierte Sprachen eingezogen ist.

Welche weiteren Faktoren von Diversität sind in Softwareteams hilfreich? Ich würde mich freuen, in den Kommentaren Eure Meinungen zu lesen.

Abschließend möchte ich auf eine Frage eingehen: Wie kann man die Diversität bei Bedarf erhöhen? Das ist eine Frage der Teamentwicklung. Doch ich habe noch nicht erlebt, dass eine HR-Abteilung die genannten Aspekte beim Recruiting berücksichtigt. Auch ein Teamleiter sucht bei einer Neueinstellung eher nach jemandem, „bei dem die Chemie stimmt“. Das ist nicht pauschal schlecht, doch sollte man sich im Klaren darüber sein, dass eine höhere Diversität damit vielleicht nicht erreicht wird.

Das Team kann selbst die Führung übernehmen und an der Vielfalt arbeiten. Während sich am Alter, Geschlecht oder der Muttersprache der Teammitglieder nichts ändern lässt, ist eine bewusste Weiterbildung in Richtung neuer Skills und Kompetenzen möglich. Den Ausgangspunkt kann ein Team zum Beispiel damit machen, die Diversität der Gruppe zu bestimmen und sichtbar zu machen. Das ist der erste wichtige Schritt, um abzuleiten, in welchen Bereichen man nachbessern sollte. Und wenn eine Neubesetzung einer Stelle ansteht, kann das Team Einfluss nehmen. Damit übernehmen die Teammitglieder einen Teil der Führungsverantwortung, die sonst häufig von niemandem ausgeübt wird.

Erst Lesen, dann Hören

Im Podcast Escape the Feature Factory greife ich ausgewählte Themen des Blogs auf und diskutiere sie mit einem Gast. Durch den Austausch lerne ich eine zweite Perspektive kennen. Wenn Du auch daran interessiert bist, findest Du den Podcast bei Spotify, Deezer, Amazon Music, und Apple Podcasts. Wenn Du die Themen, die ich im Blog anspreche, verbessern möchtest, komm’ in unsere Leadership-Community für Softwareentwicklung.

(rme)

224 betrügerische Android-Apps hat Google aus seinem Play Store entfernt. Sie waren insgesamt 38 Millionen Mal installiert, von Android-Nutzern in 228 Ländern, und lösten täglich 2,3 Milliarden betrügerische Werbeanzeigen aus, die nie jemand zu Gesicht bekam. Klassischer Werbebetrug, aber besonders gut versteckt. Dennoch aufgedeckt haben ihn Sicherheitsforscher der Firma Human. Sie nennen den Fall „SlopAds“, in Anspielung an „AI Slop“, was KI-generierte Medieninhalte geringer Qualität bezeichnet.

Die betrügerischen Anwendungen hatten meist KI-Bezug und enthielten, so wie sie im Play Store eingereicht und zum Download angeboten wurden, keine Malware-Funktion im engeren Sinne. Erst nach erfolgter Installation wurde eine verschlüsselte Konfiguration mittels Firebase Remote Config nachgeladen. Darin enthalten waren Hyperlinks: eine Liste über 300 betrügerischer Webseiten, die der Bereitstellung der fremden Reklame dienten; ein Link zum Download eines Javascripts, das den heimlichen Abruf der Reklame über Webview steuerte; und ein Link zu vier PNG-Bilddateien.

In diesen Bildern war, steganografisch, weiterer Code versteckt. Die Apps bauten daraus die eigentliche Schadroutine, die Human „FatModule“ nennt. Diese Software prüfte zunächst, auf welchem Wege der Nutzer an die App gelangt war. Wurde sie mittels Suche im Play Store gefunden und installiert, arbeitete sie nur wie angepriesen, die Schadroutine wurde dann nie scharfgeschaltet.

Wer auf Werbung hereinfiel, wurde für Werbedownloads missbraucht

Allerdings hatten die Werbebetrüger auch selbst Werbung geschaltet, nämlich für ihre Apps. Klickte ein Nutzer auf solche Reklame, landete auf diesem Weg in Googles Play Store und installierte die App, wurde deren Betrugsmodus aktiviert. Das sollte Sicherheitsforscher ausschließen, die sich eher im Play Store direkt bedienen, anstatt irgendwelche Reklame zu klicken.

Zusätzlich suchten die Apps nach Hinweisen auf mögliche Ausführung durch Sicherheitsforscher, etwa ein gerootetes Betriebssystem, einen Emulator oder Debugging-Werkzeuge. Nur wenn nichts dergleichen gefunden wurde, begannen die heimlichen Downloads von Werbung in einem versteckten Webview-Prozess. Selbst dann wurden die Abrufe über mehrere Weiterleitungen geschickt, um dem Werbeserver keine verdächtigen Referrer zu liefern.

Human hat Google informiert, dass die 224 bekannten Apps aus dem Play Store gelöscht wurden. Google Play wird jene Anwender, die solche Apps bereits installiert haben, zu deren Löschung von ihren Geräten auffordern.

Neuer Anlauf erwartet

Wie lange die Täter schon am Werk waren, ist nicht bekannt. Sie hatten es immerhin auf 38 Millionen Downloads gebracht. Und noch während der laufenden Untersuchung Humans sind weitere Apps hinzugekommen.

Die Forscher erwarten nicht, dass die Täter sich fortan redlichem Broterwerb widmen werden; wahrscheinlicher sei, dass sie bald neuen Anlauf nehmen, mit einer noch ausgefeilteren Werbebetrugsmasche. Opfer sind einerseits Werbetreibende, die für Werbung bezahlen, die nie ein Mensch würdigt, und andererseits die App-Nutzer, deren Bandbreite, Prozessorleistung und Akkuladung für systematischen Betrug vergeudet wird.

(ds)

Das Godot-Entwicklungsteam hat Version 4.5 der quelloffenen Game-Engine für 2D- und 3D-Spiele veröffentlicht. Das Update ermöglicht Screenreader-Support für Teile des UI-Editors, eine Live-Preview des GUI in mehreren Sprachen und neue optische Spieleeffekte.

Überarbeitete Optik per Stencil Buffer

Für neue optische Möglichkeiten lassen sich nun Stencil Buffer verwenden: Mit ihnen lässt sich beispielsweise im Spiel ein Loch in eine Wand bohren, um zu sehen, was sich auf der anderen Seite befindet. Stencil Buffer ähneln den bestehenden Depth Buffern, sind jedoch flexibler und bieten mehr Kontrolle. Wie das aussehen kann, demonstriert ein Video in der Ankündigung.

Neuerungen für Accessibility und Internationalisierung

Der Editor wird in Godot 4.5 barrierefreier: Screenreader können nun mit Control-Nodes umgehen und es sind Screenreader-Bindings vorhanden, um das Verhalten aller Node-Typen anzupassen. Das konnte das Godot-Team mithilfe des AccessKit umsetzen, einer Accessibility-Infrastruktur für UI-Toolkits.

Diese Änderungen sind derzeit als experimentell eingestuft und der Screenreader-Support für den Godot-Editor ist noch nicht vollständig. Er gilt derzeit lediglich für den Project Manager, Standard-UI-Nodes und den Inspector. In künftigen Updates soll die Accessibility weiter verbessert werden.

Auch an der Zugänglichkeit in verschiedenen Sprachen hat das Godot-Team gearbeitet: Das neue Feature „Internationalization Live Preview“ zeigt eine Echtzeitvorschau für Übersetzungen direkt im Editor-Viewport und soll das GUI-Testing in mehreren Sprachen vereinfachen.

Zudem ist es im Editor nun möglich, die Sprache ohne Neustart zu ändern. Das soll beispielsweise beim Entwickeln von Editor-Plug-ins hilfreich sein, um Übersetzungen zu testen.

Weitere Editor-Updates

Zu den weiteren Neuerungen im Editor zählt unter anderem ein „Mute“-Button. Beim Debuggen kann es vorkommen, dass Entwicklerinnen und Entwickler wieder und wieder die gleiche Spielemusik hören. Um das zu vermeiden, ohne den Ton komplett ausschalten zu müssen, hat das Godot-Team in der Game View eine neue Option eingeführt. Der Ton lässt sich dort nun per Klick auf ein Lautsprecher-Icon ausschalten:

Ein anderes Editor-Update betrifft die Ansicht: Auf HiDPI-Bildschirmen konnten die Standard-Steuerelemente und das Editor-UI bisher unscharf aussehen. Auch hier hat das Entwicklungsteam nachgebessert und das Rendering überarbeitet, um die Elemente auf allen Monitoren scharf darzustellen.

Weitere Details zu allen Neuerungen in Version 4.5 präsentiert die detaillierte Ankündigung auf der Godot-Website.

(mai)