Suchen

Randthemen aus dem ThoughtWorks Technology Radar

Makrotrends in der Technologiebranche 2020

Seite: 2/2

Firmen zum Thema

Es sieht nicht gut aus für Trunk-Based Development

Seit vielen Jahren setzen wir uns für das sogenannte Trunk-Based Development ein, weil wir es für den besten Weg halten Software zu schreiben. Hierbei checken die Entwickler mindestens einmal täglich ihre Code-Änderungen in eine von allen geteilte „Main Line“ in einem zentralen Repository ein – bei Git wird dieses „master“ genannt, bei Subversion „trunk“, woher auch der Name rührt.

Ich habe schon eine Menge Quelltextchaos gesehen und kann sagen: Mit Branches zu arbeiten ist weder kostenlos noch kostengünstig. Auch gekonntes Merging mit Tools wie Git erspart einem Team nicht die Probleme, die eine Entwicklung nach dem Muster „Continuous Isolation“ birgt. Wenn jemand auf Branches besteht, ist das häufig ein Anzeichen für tiefer liegende Probleme mit einem Team oder einer Systemarchitektur.

Diese Probleme sollten die Beteiligten aber lieber direkt lösen, anstatt den Quelltext mit Branches zu verwalten. Wenn Sie beispielsweise bestimmten Entwicklern nicht zutrauen, Quelltext direkt in Ihrem Projekt zu ändern und stattdessen Branches oder Pull-Requests für Code-Reviews verwenden, sollten Sie vielleicht zuerst einmal das Vertrauensverhältnis betrachten.

Sie sind unsicher, ob Sie eine Projektfrist einhalten können, und wollen mithilfe von Branches bestimmte Änderungen für ein Release herauspicken? Das kann nur nach hinten losgehen. Arbeiten Sie lieber an Ihren Schätzungen, der Priorisierung und dem Projektmanagement, anstatt das eigentliche Problem mit einer Praktik zur Verwaltung von Sourcecode notdürftig zu überdecken.

Leider werden Praktiken mit kurzlebigen Branches wie GitFlow immer populärer, ebenso die Nutzung von Pull-Requests für Governance-Aktivitäten wie Code Reviews. Unser ehemaliger Kollege Paul Hammant, Kopf und Betreiber von trunkbaseddevelopment.com, hat (hoffentlich widerwillig!) die kurzlebigen „Feature Branches“ als Empfehlung aufgenommen. Es stimmt uns ein wenig traurig, dass unsere Lieblingstechnik wohl das Nachsehen hat, wir hoffen aber, dass andere Teams mit ähnlichen Ansichten weiterhin die vernünftige Technik des Trunk-Based Development nutzen und weiterempfehlen.

Extended Reality (XR) wartet auf Apple

Bei der letzten Connect Conference von Facebook bestätigte Oculus, dass sie derzeit an einer Augmented-Reality-Brille arbeiten. Genaueres konnten sie aber noch nicht verkünden. Aktuellen Gerüchten zufolge wird Apple 2022 ein XR-Headset auf den Markt bringen, eine AR-Brille ist für 2023 geplant.

Wie bei vielen anderen Neuerungen, z. B. dem Smartphone und der Smartwatch, wird Apple vermutlich auch hier der Vorreiter bei der Entwicklung eines mitreißenden Erlebnisdesigns sein. Apple hat es schon immer gut verstanden, technische Fortschritte mit ausgezeichneten Benutzererlebnissen zu verbinden. Erst wenn dies gelingt, bringt Apple ein Produkt auf den Markt.

Lange mussten sämtliche App-Entwickler die Leitlinien für das Benutzerdesign von Apple lesen – vielleicht ist das sogar heute noch der Fall. Einen ähnlichen Sprung nach vorne erwarte ich, wenn Apple (endlich) in den Bereich AR einsteigt. Bis dahin wird AR eine Nischentechnologie bleiben, auch wenn uns ein paar schicke Demos und eingeschränkte Trainings zur Verfügung stehen.

Machine Learning – verstehen wir die Algorithmen wirklich?

Zu meinen Lieblingskanälen bei YouTube gehört Two Minute Papers. Der Wissenschaftler Károly Zsolnai-Fehér berichtet hier über verblüffende Fortschritte bei KI-Systemen. Kürzlich wurde darüber berichtet, wie künstliche Intelligenz (KI) eine menschliche Stimme anhand einer fünfsekündigen Aufzeichnung nachahmt, die physikalischen Grundlagen für Computerspiele erschließt (und zwar 30000-mal schneller als eine traditionelle physikalische Simulation) und Versteckspielen lernt – und dabei sogar bewusst Glitches ausnutzt.

In dem Kanal werden auf eindrucksvolle (und leicht beunruhigende) Weise die Fortschritte der schwachen KI dargestellt – meist anhand von Problemen, die sich gut in einem Video zeigen lassen. Machine Learning (ML) wird jedoch auch in vielen anderen Bereiche angewandt, z. B. bei Geschäftsentscheidungen, im medizinischen Bereich oder zur Beratung von Strafrichtern bei der Urteilsverhängung. Es ist also wichtig, dass wir wissen, wie ein KI- oder ML-System funktioniert.

Ein zentrales Problem besteht darin, dass wir zwar beschreiben können, was ein zugrunde liegender Algorithmus tut (zum Beispiel der Back-Propagation-Algorithmus, der beim Training von neuronalen Netzen Anwendung findet), aber nicht erklären können, was das Netz macht, sobald es trainiert wurde.

Im aktuellen Radar werden Tools wie What If und Techniken wie Ethical Bias Testing vorgestellt. Unserer Ansicht nach sollte die Erklärbarkeit ein zentrales Kriterium sein, wenn es um die Auswahl eines ML-Modells geht.

Mechanical Sympathy taucht wieder auf

Im Jahr 2012 enthielt unser Radar das Konzept „Mechanical Sympathy“, das auf der Arbeit des LMAX-Disruptor-Teams basierte. Damals, als viele Softwareanwendungen immer abstrakter geschrieben wurden, war Disruptor auf extrem hohe Leistung auf bestimmten Intel-Prozessoren ausgelegt. Das LMAX-Problem war nicht parallelisierbar – und somit eine hohe Leistung eines einzelnen CPU-Threads notwendig.

Nun scheint es, als feiere Mechanical Sympathy ein Comeback. Im letzten Radar nahmen wir Humio auf, ein Tool zur Aggregation von Log Dateien, das sowohl beim Aggregieren als auch beim Abfragen extrem schnell ist. In den aktuellen Radar haben wir GraalVM aufgenommen, eine leistungsstarke Virtual Machine.

Ironischerweise sind Fortschritte in der Softwarebranche zu einem Großteil darauf ausgerichtet, von Hardware loszukommen (Container, Kubernetes, Functions-as-a-Service, Cloud-Datenbanken usw.), während andere enorm von der ausführenden Hardware bestimmt werden. Es hängt wohl ganz vom Anwendungsfall ab.

Mike Mason
Mike Mason
(Bild: ThoughtWorks)

Aus Platzgründen sind hier nicht alle Trends aufgeführt, aber wer sich für Softwareentwicklung als Mannschaftssport oder den Schutz der Software-Lieferkette interessiert, kann einen Blick in den aktuellen Technology Radar werfen.

* Mike Mason ist Global Head of Technology bei ThoughtWorks.

(ID:46339624)