Suche
Aus dem Entwicklernähkästchen - Teil 3

Die schlimmsten Tech-Enttäuschungen des Jahres

Redaktion JAXenter
Enttäuschung

© Shutterstock / RomarioIen

2016 ist vieles nicht gut gelaufen, auch in der Tech-Welt nicht. Die JAXenter-Experten berichten von ihren persönlichen Enttäuschungen. Ganz vorne mit dabei: Java EE und Microservices. Aber auch das Internet der Dinge und Elektroautos bekommen Schelte ab.

Dein Flop: Was war für dich 2016 die größte Enttäuschung der Technologie-Welt?

Die JAXenter-Experten

arrasz_joachim_sw

Joachim Arrasz – Software- und Systemarchitekt bei synyx.

lukas-eder2

Lukas Eder – Gründer und Geschäftsführer von Data Geekery.

jonas_helming

Dr. Jonas Helming – Geschäftsführer der EclipseSource München GmbH.

kusalic_ivan

Ivan Kusalic – Senior Software Engineer bei HERE

loewenstein_bernhard_sw

Bernhard Löwenstein – Inhaber von Lion Enterprises

steve_naidamast

Steve Naidamast – Senior Software Engineer bei Black Falcon Software.

Dominik Obermaier

Dominik Obermaier – Geschäftsführer bei dc-square

spichale

Kai Spichale – IT-Berater bei innoQ.

dilger_martin

Martin Dilger – Effective Trainings & Consulting

schindler_uwe_sw

Uwe Schindler – Consultant bei SD DataSolutions und PMC-Mitglied im Apache-Lucene-Projekt

pirchner_florian_sw

Florian Pirchner – Selbstständiger Softwarearchitekt

FalkSippach-128px

Falk Sippach – Software-Entwickler bei der OIO Orientation in Objects GmbH.

thomas_kruse

Thomas Kruse – Architekt bei der trion development GmbH und Leiter der Java Usergroup Münster.

monschau

Andreas Monschau – IT Consultant bei Haeger Consulting

nicolai-parlog

Nicolai Parlog – freier Softwareentwickler

 

 

Joachim Arrasz: Oracles Entscheidungen, welche JSRs noch relevant sind. Java EE stirbt da gerade einen schnellen Tod.

Bei Java EE fällt es nicht schwer enttäuscht zu sein.

Lukas Eder: Bei Java EE fällt es nicht schwer, enttäuscht zu sein. Ich meine, wie kann es sein, dass es eine Java-Enterprise-Version gibt, die sich noch immer auf keinen verpflichtenden JSON-Standard geeinigt hat? Ich schätze, Java EE wird sich erst auf JSON-Standards einigen, wenn JSON gar nicht mehr relevant ist. Aber nicht, dass ich überrascht oder enttäuscht wäre. Ich bevorzuge es, nicht an Java-EE-Projekten zu arbeiten, da diese für gewöhnlich recht übertechnisiert sind.

Jonas Helming: Projekt Jigsaw oder das Java-Module-System! Auch wenn es zum aktuellen Stand der Entwicklung nicht mehr realistisch ist: Ich wünschte, Java 9 würde einfach ein “OSGi essential” umsetzen, das im Wesentlichen kompatibel ist, aber gegebenenfalls auf Dynamics verzichtet. OSGi funktioniert seit 15 Jahren, Jigsaw wird sei fünf Jahren verschoben!

Unsere Branche sucht im Grunde nach wie vor nach dem sprichwörtlichen Hammer, der jedes Problem zerschlägt.

Ivan Kusalic: Mich persönlich enttäuscht noch immer, dass viele technische Entscheidungen immer noch anhand von Hypes rund um bestimmte Technologien getroffen werden und nicht auf einem Verständnis dafür beruhen, wann der Einsatz dieser Technologien sinnvoll ist und welche Vor- und Nachteile sie mitbringen.

Unsere Branche sucht im Grunde nach wie vor nach dem sprichwörtlichen Hammer, der jedes Problem zerschlägt. Ein Hammer ist natürlich ziemlich nützlich. Manchmal braucht man aber doch auch andere Werkzeuge. Lass mich zwei Beispiele geben:

1. Viele Menschen haben weiterhin ein recht oberflächliches Bild von Microservices. Microservices sind keine Wunderwaffe, sondern ein Architekturstil, der seine Vor- und Nachteile hat. Ich finde an dieser falschen Sichtweise auf Microservices besonders spannend, dass diese zwar am Ende eine gute Lösung darstellen können, aber häufig eingesetzt werden, bevor Bedarf daran besteht. Dadurch entstehen unverhältnismäßig hohe Kosten.

2. Die Geschichte rund um Left-Pad. Dazu muss man wohl nichts mehr sagen.

Lesen Sie auch: Left Pad: Ein Entwickler, elf JavaScript-Zeilen, tausende defekte Anwendungen

Bernhard Löwenstein: Als Mustang-Fahrer kann ich mir diesen Seitenhieb natürlich nicht verkneifen: Elektroautos. Wenngleich solche Autos im Gegensatz zu meinem Ponycar recht leise sind, herrschte hier medienmäßig erneut viel Lärm um nichts. Mir ist natürlich klar, dass wir uns nach Alternativen für den Verbrennungsmotor umschauen müssen, allerdings kann ich den Hype nicht nachvollziehen.

Einerseits wird so getan, als wären Elektroautos besonders innovativ. Das sind sie eben nicht, denn bereits seitdem Autos fließbandmäßig gebaut werden, macht man sich bezüglich des Antriebs Gedanken. Wer das nicht glaubt, möge bitte das großartige “The Henry Ford”-Museum in Dearborn besuchen. Jetzt fehlt nur mehr, dass uns jemand weismachen will, dass den dampfbetriebenen Autos die Zukunft gehört und es für den Kauf solcher Fahrzeuge dann Förderungen vom Staat gibt.

Andererseits wird so getan, als stünde endlos Energie zur Verfügung und bekämen wir diese geschenkt. Ich möchte jedenfalls nicht, dass wir uns wieder verstärkt der Atomenergie hinwenden. Diesen Trend gibt es aber international! Solange wir nicht wissen, wie wir den Atommüll entsorgen können, ist das den zukünftigen Generationen gegenüber absolut verantwortungslos.

Zusammengefasst: Es ist gut, dass an Elektroautos geforscht wird, aber bitte werte Politiker und Journalisten, hört endlich mit der unreflektierten Wiedergabe von Marketinginfos auf.

Andreas Monschau: Ich bin eigentlich ohne Erwartungen in das Jahr 2016 reingegangen, nachdem 2015 bereits einige Enttäuschungen für mich bereithielt. Nicht völlig unerwartet waren meines Erachtens die Security-Probleme im IoT-Umfeld. Ich hoffe, da wurden einige Augen geöffnet.

Die größte Enttäuschung ist die zunehmend unberechenbare Natur der Microsoft-Entwicklungsumgebung.

Steve Naidamast: Wie ich in vielen meiner Veröffentlichungen über die letzten Jahre hinweg bereits geschrieben habe, sehe ich die größte Enttäuschung in der zunehmend unberechenbaren Natur der Microsoft-Entwicklungsumgebung. Alles Neue scheint aufgenommen und in Visual Studio implementiert zu werden.

Dadurch entfernt sich Microsoft von den eigenen Kernentwicklungskonzepten Schritt für Schritt. In diesem Sinne und durch den anhaltenden Support von ASP.NET MVC gefördert, wurden ebenso viele JavaScript-Frameworks zur Webentwicklung integriert.

Während die Java-Community über viele Jahre mit den MVC-Paradigma als Standard-Antwort für Webentwicklung gearbeitet hat, lag bei Microsoft das eigene Paradigma in ASP.NET WebForms, das, trotz nicht annähernd so tiefem Low-Level-Design, die Prämisse ease-of-use hat. WebForms wurde zu einem sehr ausgereiften Produkt weiterentwickelt und ist bis heute die machtvollste Art und Weise, Datenbank-intensive Webapplikationen in vernünftigen Zeitintervallen zu entwickeln. Natürlich hat es auch seine eigenen Probleme, aber die hat MVC genauso.

Dominik Obermaier: Eine der größten Enttäuschungen ist für mich nach wie vor, dass viele Java-basierten Big-Data-Technologien Zookeeper oder ähnliche zentrale Registries benötigen, um vernünftig zu funktionieren. Das macht die Applikationen weniger resilient gegenüber Ausfällen, und ein Deployment in redundant aufgebauten Rechenzentren ist damit fast unmöglich.

Kai Spichale: Mein Flop: MVC 1.0 wurde aus der Roadmap von Java EE 8 gestrichen. Das aktionsbasierte MVC-Framework wäre ein komplementärer Ansatz für JSF gewesen.

Nicolai Parlog: Schon seit zehn Jahren hintereinander: Die Arbeitsbedingungen in der IT-Hardware-Industrie (vor allem in Asien) sowie der Abbau und die Verarbeitung von Ressourcen dafür (vor allem in Afrika).

Es lohnt sich kaum mehr, sich die neuen JavaScript-Frameworks und Tools anzuschauen.

Martin Dilger: Die Kurzlebigkeit von Trends im JavaScript-Umfeld. Es lohnt sich kaum mehr, sich die neuen Frameworks und Tools anzuschauen, da sie schneller verschwinden als man sie einsetzen kann.

Uwe Schindler: Die ständige Verschiebung von Java 9!

Florian Pirchner: Bisher hatte ich noch nie mit JPA zu tun. Und JPA ist DIE Enttäuschung im Jahr 2016.

Ich war immer der Meinung, dass JPA logisch und “straight forward” ist. Doch in den letzten Wochen habe ich begriffen, dass JPA alles andere als logisch ist. Meine Erwartungshaltung war, dass JPA die Referenzen ähnlich handelt wie EMF (Eclipse Modeling Framework); was ja auch sehr intuitiv und ohne große Überraschungen ist. In meinem aktuellen Projekt stellten wir allerdings fest, dass es mit der Intuition in JPA nicht weit her ist!

Ein Beispiel: Ich habe eine @OneToMany zu einer Entity. Entity Foo hat viele Entity Bar. Und Entity Bar hat eine Backreference @ManyToOne (ContainerRef im Sinne von EMF) auf Foo. Beides sind CrossReferences und kein Containment!

Löscht man in JPA aber nun Foo, dann wird Bar mitgelöscht. Vollkommen unerwartet! Die einzige Lösung scheint zu sein, dass man eine Custom-Methode in Foo implementiert und mit @PreRemove annotiert. Darin muss man dann händisch die Backreference von Bar nach Foo löschen. Ansonsten wird Bar mitgelöscht oder es gibt “kryptische Exceptions”. JPA ist leider nichts, das man einfach so verwenden kann und das Ergebnis bekommt, das man erwartet.

Lesen Sie auch: 15 Tech-Trends für das Jahr 2017

Thomas Kruse: Ich habe mir viel vom neuen MacBook Pro versprochen, es war – und ist – eine herbe Enttäuschung. Als Entwicklerrechner werde ich beim Thinkpad mit Gnome Desktop bleiben.

Falk Sippach: Das Wirrwarr um Java EE und insbesondere das lange Schweigen von Oracle haben gezeigt, wie abhängig die Java-Welt von dem Software-Riesen ist. Denn als sich die Verantwortlichen endlich zu Wort gemeldet haben, wurden die Wünsche und Anregungen der Community mal wieder weitestgehend ignoriert.

Geschrieben von
Kommentare

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht.