Der Long-Arrow-Operator – das Stiefkind der Programmierer

Eine Kritik an der mangelhaften Umsetzung eines der Standard-Operatoren in allen gängigen Programmiersprachen.

Was ist der Long-Arrow-Operator?

Die Geschichte der Softwareentwicklung hat über die Jahrzehnte viele Programmiersprachen hervorgebracht, um eine gewisse Abstraktion und Convenience bei der Verwendung von Hardware zu erreichen. Niemand mag heute mehr in Assembler auf Bit-Ebene programmieren, selbst wenn das bis heute der einzige Weg ist, um die Vorgänge auf einem Computer unter Kontrolle zu behalten.

Intro

Es war ein entspannter Abend. Eine lange Arbeitswoche lag hinter uns. Mit einem Drink in der Hand blickten wir von unseren Liegestühlen auf der Dachterrasse des Flughafens nicht nur auf einen wunderschönen Sonnenuntergang, sondern auch zurück auf ein perfekt gelaufenes PI-Planning. Das Produkt, so die Vorhersage, wird wohl doch schneller marktreif als gedacht. Jetzt noch schnell in den Flieger und die ganzen Annehmlichkeiten der First Class genießen, um morgen früh erholt die Familie wiederzusehen.

Heutzutage ist Open Source der “geile Scheiß”. Sie ist an vielen Stellen im Einsatz und viele Firmen bauen teilweise ihr ganzes Geschäft auf Open Source auf. Wir haben in den letzten Monaten keine Kosten und Mühen gescheut und mit einigen Experten in der Branche gesprochen um ihre eigentliche Meinung zu Open Source zu sammeln. In den folgenden Abschnitten stellen wir die gesammelten Pro und Contra Argumente vor.

Contra

1. Das open in Open Source: Open Source brüstet sich oft damit “frei” zu sein. Nicht selten wird von Open Source Fans andere Software als “Nonfree” bezeichnet. Aber wenn man sie darauf anspricht rudern sie sehr schnell zurück - so meinen sie nicht frei wie in Freibier, sondern frei wie in Freiheit. Dass sie das so explizit sagen kann nur eine Sache bedeuten: In der Lizenz sind insgeheim riesige Kosten versteckt. Auch Open Source Entwickler sind nicht einfach nur gute Menschen, ihre Taktik ist einfach nur, mit kostenlosen Angeboten zu locken und im Nachhinein Milliarden von Euro zu erklagen, weil man eine Zeile in den Lizenz Vereinbarungen nicht gelesen hat.
2. Security: Ein weiterer Punkt der oft gebracht wird ist, dass Open Source inhärent sicherer ist als Closed Source, weil mehr Menschen den Code lesen können und Schwachstellen finden können. Das wäre ja ein cooler Ansatz, aber Hand aufs Herz - ich kenne keinen Entwickler und keine Entwicklerin, die jemals eine Open Source Library komplett durchgelesen hat, bevor er oder sie die Library verwendet hat. Das lässt sich gut am bekannten Heartbleed Bug zeigen, der seit über 2 Jahren in openSSL war, bevor er gefunden wurde. Zwei Jahre!
3. Fachfremdes Nicht-Wissen: Wenn man Software von einer Firma kauft, kann man sich beim Kauf informieren, ob der Hersteller überhaupt genug Wissen auf dem Bereich vorweisen kann. Dafür können, vor allem in sehr spezialisierten Bereichen wie Automotive, Medical, Aerospace und vielen mehr, Normenkonformitäten abgefragt werden. Bei Open Source ist das schon schwieriger. Woher weiß ich, ob die Entwickler einer beliebigen Open Source Library überhaupt Ahnung von ihrem Thema haben? Oft wird Open Source von Hobbyentwicklern entwickelt. Leuten, die eigentlich in komplett anderen Branchen tätig sind und daheim ein bisschen wild auf ihrer Tastatur herumhacken wollen. Keinerlei nachweisbare Fachkenntnis, keinerlei Garantie, dass irgendwas aus der Codebasis funktioniert oder korrekt ist.
4. Lebenszeit: Ein weiteres großes Problem an Open Source Software ist die Lebenszeit. Niemand weiß, wie lange die Software noch entwickelt oder unterstützt wird. Es kann passieren, dass die Entwickler von einem Tag auf den anderen ein Kind bekommen und dann keine Zeit mehr für die Software haben. Oder einfach das nächste Projekt anfangen und nie fertig machen. Oder einfach ohne Grund verschwinden. Jeder Entwickler weiß: Software ohne Updates ist ein Kochtopf für Probleme, der nur darauf wartet überzukochen. Also bleibt einem dann nur eine Möglichkeit: Die Open Source Library zu übernehmen und selbst zum Maintainer zu werden - und dann darf man sich über Wochen, Monaten, Jahren an schlecht geschriebenem Legacy Code (siehe Punkt 3) ärgern.

Pro

Viele Leser haben uns gefragt, ob der Artikel „Der Stack ist dein Freund“ [1] ernst gemeint sei. Wir als aufklärende Bildungsorganisation im Bereich IT sehen uns zur Wahrheit verpflichtet, und selbstverständlich werden unsere Empfehlungen inhaltlich mehrfach durch unsere Fachexperten geprüft.

Auf unserer Seite machte sich nach derartigem Feedback eher Enttäuschung breit - Enttäuschung darüber, wie wenig Softwareentwickler heute noch über die Abläufe im Computer wissen. Um unsere Empfehlungen zu untermauern, haben wir ein Benchmarking arrangiert, um die alternativen zu unserer Empfehlung zu bewerten.

Fast jeder Manager kennt es: Man bekommt ein neues Team, es ist eine Gruppe aus vielen Entwicklern. Man weiß nicht, welche der Entwickler gut sind, wem man Gehaltserhöhungen gibt (um eine Abwanderung in andere Firmen zu vermeiden) und wen man besser feuert um die Effizienz zu steigern. Auch Stefan Pallmer (Name von der Redaktion geändert) stand in seiner Karriere bereits mehrmals vor dieser Problematik und hat sich inzwischen zum Spezialisten auf dem Bereich entwickelt. In einem Interview hat er uns seine Top 5 Punkte gegeben um herauszufinden, welcher Entwickler wirklich etwas drauf hat (sogenannte 10x Entwickler) und welche Entwickler nur Kosten verursachen (sogenanntes Dead Weight). Indem er sich strikt an diese 5 Punkte gehalten hat, hat er bei einigen Firmen einen Wachstum im Gewinn von bis zu 20% erreichen können - das ist mehr als man durch die meisten anderen Methoden jemals erreichen kann!