Blogbeitrag DIY-Software Teaser

Autor-Facts

NameLinkedIn IconDavid Beuchert
PositionTech Lead E-Commerce
GitHubfilecage
3. Januar 2022

DIY-Software: Warum es der einzig wahre Weg ist und alle anderen falsch liegen

Ich habe vor ein paar Jahren in einem Panel auf der code.talks commerce in Berlin mal erzählt, dass wir nie auf Standardsoftware zurückgreifen und alles selbst entwickelt haben, was wir an Software bei uns einsetzen. Das war, genau wie meine provokative Überschrift, natürlich gelogen. Wenn ich aber die Entwicklung unserer Branche der letzten Jahre verfolge und das mit den Ansätzen vergleiche, wie wir als Team Lösungen angehen, dann stelle ich fest, dass es Differenzen zwischen uns und dem Rest der Welt gibt und dass diese Differenzen sich eher vergrößern als verkleinern.

Meine damalige Aussage trifft zwar auch nach wie vor nicht zu, aber irgendwie ist das auch eine Frage der Perspektive. In diesem Beitrag möchte ich unsere Perspektive gerne beleuchten und, obgleich der Tatsache, dass meine Headline lediglich Clickbait ist, dafür werben, öfter Software selbst zu bauen und seltener Bausteine zu verdrahten.

Erst mal auf die Semantik einigen

Was meine ich eigentlich damit, wenn ich sage, dass wir was anders machen als der Rest der Welt? Kein E-Commerce-Unternehmen, das eine annähernd ähnliche Größe hat wie wir, kann es sich leisten, ausschließlich ein Magento (oder halt Woocommerce oder weiß der Geier was) zu installieren und das mit Content zu füllen. Unsere Shops müssen leben und sich von anderen abgrenzen. Außerdem entwickeln unsere Kund:innen besondere Wünsche, denen wir nachkommen müssen. Das bedeutet, spätestens ab einer gewissen Größe hat man mindestens einen oder mehr Entwickler:innen, die exklusive Features bauen.

Andersrum geht es übrigens ebenfalls nicht: kein Unternehmen dieser Welt kann es sich leisten, alles in Eigenregie zu entwickeln. Wir verwenden Betriebssysteme, Programmiersprachen und deren Compiler/Interpreter, Webserver, Datenbanken und Tools zur Versionierung von Code, die alle nicht von uns entwickelt wurden. Hin und wieder entwickeln Companies ihre eigenen Programmiersprachen: Apple hat Swift, Google hat Go, Mozilla hat(te) Rust und JetBrains hat Kotlin. Ob sich das jeweils gelohnt hat, kann ich natürlich nicht sagen. Worauf ich hinaus will: Du und ich, wir sind simple Menschen, wir nutzen immer irgendwie fertige Software. Im Fall von Thomann ist das Software wie PHP, MySQL, git, node.js, nginx, etc. pp.

Den richtigen Weg für den richtigen Anwendungsfall finden

Es scheint bei dieser Thematik also mal wieder auf die passende Graustufen hinauszulaufen. Umso irritierender ist es, dass mich im Austausch mit firmenfremden Devs, CTOs und Leads nicht selten das Gefühl beschleicht, mich für unseren Weg der Eigenentwicklungen rechtfertigen zu müssen. Ich ertappe mich dabei auch nicht selten in rhetorischer Defensivhaltung. Dabei sind wir, wie alle anderen, stolz auf das was wir erschaffen haben und vor allem auch wie wir es erschaffen haben. Wir bedienen eine Sortiments-Nische, die nach einem Detailgrad lechzt, der von Standardsoftware nicht bedient werden kann. Es ist Teil unserer DNA, den Anspruch nicht an die Grenzen der verfügbaren Technologie anzupassen und es ist vermutlich unser fränkischer Wahnsinn, dass wir glauben, wir können es immer besser.

Immer?

Okay, ertappt: das war schon wieder gelogen. Bei Themen wie Warenwirtschaft, Logistik und Finanz- oder Lohnbuchhaltung halten wir uns lieber raus. Die Komplexität dieser Problemstellungen übersteigt den Headroom, den es für “besser machen” gibt, um ein Vielfaches. Wenn es allerdings um thomann.de geht, gibt es kaum etwas, das wir aus der Hand geben würden.

Angefangen beim Shop-Framework, das eine komplette Eigenentwicklung darstellt. Request- und Response-Handling, Routing, das Handling des gesamten Application Flows: alles selbst gebaut. Das gibt uns für die Funktionalität und Präsentation im Shop unbezahlbaren, kreativen Freiraum, weil wir Lösungen auf allen Ebenen der Software implementieren können. Gleiches gilt für Content-Pflege und Housekeeping-Tools. Wir entscheiden, wie unsere Prozesse gestaltet sind und die Software bildet diese ab, nicht andersrum.

Außerdem gibt es andere Komponenten, bei der fertige Lösungen einfach nicht gut genug waren. Zum Beispiel unser Service, der berechnet, wann bestellte Ware beim Kunden ankommen wird. Oder unser Service, der Versandregeln für über 160 Länder inklusive Besonderheiten zu Städten und Postleitzahl-Gebieten kennen und in Echtzeit auf einen Warenkorb anwenden können muss.

Und als Drittes gibt es noch Komponenten, die so speziell sind, dass nicht mal annähernd eine Standardlösung in Frage gekommen wäre; z. B. Stompenberg FX. Eine Software, die analoge Effektgeräte digital steuerbar machen kann und gleichzeitig den Anspruch hat, das Gefühl des echten Effekts visuell zu vermitteln, gab es nicht, bevor wir sie erdacht und gebaut haben.

Früher war alles schlechter

Wenn ich heutzutage auf ein Problem stoße, dann weiß ich, dass mit an Sicherheit grenzender Wahrscheinlichkeit jemand dieses Problem schon vor mir gelöst hat und irgendwo im Internet die Lösung dafür steht. Wenn die zugrundeliegende Frage nicht zu simpel war, dann auf Stackoverflow - und sonst halt bei gutefrage.net.

thomann.de gibt es seit 1996. Stackoverflow kam 12 Jahre später, npm 14 Jahre und Composer 16 Jahre. Die meisten heute bekannten Shopsysteme erschienen ebenfalls erst Jahre nach der ersten Revision unseres Onlineshops. Das heißt, die Menge an fertigen Lösungen, aus der man sich bedienen konnte, ging gegen Null.

Die grundlegende Situation, dass man Software entweder selbstständig entwickelt oder dass ein Feature nicht existieren wird, gibt es also schon seit mindestens 25 Jahren. Die Anwendungsfälle, die bedient werden müssen, haben sich allerdings stark verändert. Heutzutage gibt es Standardsoftware, die so gut ist, dass Eigenentwicklungen nicht mehr zu rechtfertigen sind. Dinge wie Template Engines oder Test-Frameworks haben wir vor 10 Jahren noch selbst entwickelt. Das ist heute unvorstellbar.

Außerdem lernt die gesamte IT-Branche mehr und mehr, wie wichtig es ist, Komponenten eher klein und dafür erweiterbar zu halten. Dazu gehören z. B. auch viele Headless-Systeme, die uns genau den Teil der Arbeit abnehmen, um den wir uns nicht kümmern möchten und dafür die Zeit geben, uns um das Wichtige - das, was unsere User sehen - zu kümmern. Zusätzlich zu den kleiner geschnittenen Komponenten haben sich Standards etabliert, die die Interoperabilität zwischen Standard- und Custom-Komponenten erlauben (ein gutes Beispiel sind hier die PSRs in der PHP-Community).

Also was denn jetzt?

Es bleibt ein Balanceakt zwischen Zukauf und Eigenentwicklung und die Antwort wird weiterhin, zumindest teilweise, aus dem Bauch heraus getroffen werden müssen. Es gibt keine Metriken oder Blaupausen, an denen wir uns bedienen können. Die Kosten für einen Zukauf mögen sich errechnen lassen, aber die Abhängigkeit, in die man sich begibt, nicht. Das Gleiche gilt für ein Entwicklerteam: man kann errechnen, was ein Team pro Sprint kostet und im besten Fall schätzt das Team die zu investierende Zeit richtig ein. Dass ein Team in diesem Zeitraum nicht zur Verfügung steht, um andere Features zu entwickeln, die möglicherweise einen höheren Mehrwert bringen, ist ein Risiko.

Zeit für die Glaskugel: was bringt die Zukunft?

Die Anforderungen an alle Komponenten wird weiter steigen, vor allem den abzubildenden Detailgrad und die Performance betreffend. Es wird mehr und mehr notwendig, dass wir uns Spezialist:innen leisten, die sich auf Teilbereiche konzentrieren und dass wir diese Teilbereiche kleiner schneiden, damit man die Expertise in der jeweiligen Domäne behalten kann.

Für uns wird das konkret heißen, dass wir Standards besser und schneller adoptieren und vor allem lernen müssen, Standardlösungen konkreter zu evaluieren. Andernfalls laufen wir Gefahr, dass uns unser Stolz auf eigenentwickelte Software daran hindert, bessere Lösungen zu implementieren oder dass wir sie nicht implementieren können, wenn wir nicht die notwendigen Schnittstellen-Standards geschaffen haben.

Es wird aber auch weiterhin so sein, dass wir Ideen haben, die niemand vor uns hatte und dass wir auf Probleme stoßen, die keiner bis jetzt gelöst hat. Und dann werden wir tun, was wir immer tun: wir werden die Lösung dafür bauen und wenn es dann 5-10 Jahre später an jeder Ecke Standardlösungen zu diesem Problem gibt, werden wir darüber diskutieren, warum wir lieber Eigenentwicklungen bauen.

Hello, Webteam

Hello, Webteam

Wir sind das Thomann Webteam, wir basteln den Webshop und die Thomann App.
Voll auf Full Responsive

Voll auf Full Responsive

Warum wir unseren Shop umbauen – und Lila das neue Blau ist.
Open Space 2021

Open Space 2021

Sommer 2021 – Home Office, Lockdown, vierte Welle und: huch, ein Open Space!
Bits, Beats, Ops-Team

Bits, Beats, Ops-Team

Jemand muss den Shop ins Internet bringen. Das ist unsere Mission.
Das kann Kanban

Das kann Kanban

Die Idee hinter dem Kartenschieben – mit einem knusprigen Nachwort.
ThomannUI: Der Beginn einer Component Library

ThomannUI: Der Beginn einer Component Library

Ein Einblick in die Component Library auf Basis von React von Julian Kern