Zukunftsaussichten von velorent

18.08.2022

Der letzte Blogeintrag ist ja nun schon länger als ein Jahr her. Aber die Dienste laufen noch, also, wohin geht die Reise mit velorent? Nun: Was lange währt, wird endlich gut. Softwareentwicklung ist nun doch nicht eben so einfach wie angenommen.

Bei all den schlechten Nachrichten will ich auch mal was Positives ankündigen: velorent geht voraussichtlich zum Jahreswechsel in die nächste Evolutionsstufe. Intern wird bereits die nächste Version getestet. Schneller, komfortabler in der Bedienung und mit neuen Komfort-Features, etwa der automatisierten Rechnungsstellung! Damit sich Händler*innen noch mehr auf das Kerngeschäft fokussieren können, während velorent die lästige Arbeit abnimmt.

Das war meine Position 2021. Und naja, es ist bald 2023 und besagte Änderungen sind noch nicht da. Für dieses Problem gibt es mehrere Ursachen:

  1. Mentale Probleme.
  2. Falsche Annahmen innerhalb der Entwicklung.

😟 Magst du da ins Detail gehen?

Klar, gerne. Also, fangen wir mit dem ersten Punkt an. Kurz gesagt: Depression ist ein Arschloch. Ja, das sag ich ganz explizit so. Wer selbst schon betroffen war, weiß genau wovon ich rede. Und leider hat mich besagte Depression in ein absurd tiefes Loch geführt. Ich hatte velorent die ganze Zeit im Hinterkopf, aber jeder Versuch, irgendwie größere Arbeiten vorzunehmen, endete nur in Kopfschmerzen und langanhaltender Erschöpfung.

So schwer es mir viel, ich musste die Entwicklung für eine viel zu lange Zeit komplett auf Eis legen. Klar, ich hätte mir das Gegenteil gewünscht, aber das lag leider nicht in meiner Gewalt.

Aber du sagtest was von falschen Annahmen?

Jup, damit kommen wir zum zweiten Problem. Ich hab bis – sagen wir – 2020 angenommen, dass ich das mit der Softwareentwicklung ganz gut beherrsche und meine Annahmen in der Regel zutreffen. Bis dato war das auch immer zutreffend. Aber nun. Stellt sich heraus, dass dem doch nicht so ist. Details? Gerne. Ab hier wird es dann aber sehr spezifisch, falls das nicht von Interesse sein sollte: das Fazit ist weiter unten.

⚠️ Ab hier wird’s technischer.

Softwareentwicklung ist ein sich absurd schnell änderndes Feld. Gefühlt wöchentlich gibt’s ein neues Framework, eine neue Programmiersprache, neue Tools, neue Möglichkeiten für das Deployment. Kubernetes, Microservices, eine Bastion an JavaScript-basierten UI-Frameworks usw. Und all diese Dinge wurden entwickelt, um ein gewisses Problem zu lösen. Meist werden Dinge danach einfacher, gewisse Workflows klarer oder irgendein anderes Problem wird gelöst.

Die eigenen Probleme beginnen da, wo diese Annahmen auf die eigene Software übernommen werden. velorent ist klein und auch die Software ist bewusst einfach gehalten. Einfachheit ist aber schwer. So nutzt die noch aktuelle Version 1 als Code-Basis C# (ASP.NET Core) und der Code ist nach dem CQRS-Pattern strukturiert. Bereits der zweite Punkt war ein Fehler, aber damals, 2019, klang das einfach sinnvoll.

Über die Jahre sind dann verschiedene Probleme am Code aufgetaucht. Und aus einem eigentlich relativ sauberen Aufbau ist dann der berüchtigte Spaghetti-Code geworden. Ich mag 🍝, aber nicht in meinem Code. So, nun gibt es für besagtes Problem verschiedene Lösungen. Sinnvoll wäre ein Refactoring gewesen. Und genau das hab ich nicht gemacht, das war rückblickend ein sehr großer Fehler.

Warum denn nicht?

Rückblickend wüsste ich das auch gerne. Mein Vergangenheits-Ich hat sich trotz vorhandener und sehr guter Unit- und Integration-Tests dagegen entschieden. Begründet hab ich das mit Performance-Gründen (🤦‍♀️), einer geplanten Neuentwicklung der UI als SPA mit Svelte und einer besseren Zuverlässigkeit.

Ja, das wäre alles auch damals mit einem Refactoring möglich gewesen. Nein, damals wusste ich das leider nicht. Hätte ich es mir rückblickend gewünscht? Definitiv.

Und was ist stattdessen passiert?

Eine ganze Menge. Ich hab sehr viel probiert, experimentiert, gebastelt. Unter anderem:

  1. Refactorings des bestehenden Codes. Ergebnis: viel zu früh abgebrochen, falsche Annahmen beim Refactoring.
  2. Entwurf auf Basis der Microservice-Architektur. Ergebnis: zu komplex für eine Person. Asynchrone Kommunikation wird extra schwer.
  3. Entwurf des Dashboards auf Basis von Svelte. Ergebnis: sieht hübsch aus, aber führt im Endeffekt auch dazu, dass ich an zwei Orten immer am basteln bin, wenn es um Features und so geht.
  4. Entwurf auf Basis einer anderen Programmiersprache (Go). Ergebnis: kommt dann hoffentlich im Quartal Q1/2023.

Ja, ich hab velorent neugeschrieben, beziehungsweise ich bin noch dabei. War es das wert? Sehen wir dann. Bereue ich es manchmal? Definitiv.

Aber: ich hab ne ganze Menge aus diesen Fehlern gelernt und ehrlich gesagt, so stark auf die Nase zu fallen, musste vielleicht auch sein.

Kurzer Rant 😠

Ganz kurzer Rant: Nein, wir brauchen auch keinen Kubernetes-Cluster, wir brauchen keine Hochverfügbarkeit, wir brauchen keine unendliche Skalierung. Keep it simple. Auch wenn das alles verlockend und fancy aussieht.

Fazit?

Ich hab viel lernen müssen, für meinen Geschmack etwas zu lange. Aber die Zeit ist nicht zurückdrehbar, es sollte so passieren.

Für die Zukunft kann ich nur aufpassen, vernünftigere Entscheidungen zu treffen. Für das Quartal Q1/2023 hab ich mir vorgenommen, den Rewrite von velorent produktiv gehen zu lassen. Bis dahin ist zwar noch ein wenig was an Arbeit zu tun, aber hoffentlich kann ich dann wieder häufiger Updates veröffentlichen als vorher.

Ich bin für meinen Teil tatsächlich auch sehr zufrieden mit der Neuentwicklung. Sie ist bereits jetzt schneller und weniger fehleranfällig. Wie sich das ganze dann im Produktivbetrieb äußert, wird die Zeit zeigen.

Bis dahin: Stay safe, wear a mask. 😷