Warum eure Software mehr Personal frisst als Weihnachtskekse 🍪💻

Oder: Was Omas, Stanzmaschinen und LEGO euch über Software-Entwicklung beibringen können

Es gibt Firmen, die seit Jahrzehnten die gleichen Produkte, Maschinen oder Anlagen herstellen – und dafür Software benötigen. Seit Jahrzehnten beschäftigen sie Software-Entwickler. Und jedes Jahr brauchen sie mehr davon: mehr Entwickler, mehr Architekten, mehr Projektleiter. Die Kosten steigen, die Teams wachsen.

Und doch fragt sich niemand:
👉 „Warum ist das so?“
👉 „Warum geben wir jedes Jahr mehr für Software aus?“

Vielleicht helfen ein paar Vergleiche …


Die Wirtschaftlichkeit hausgemachter Weihnachtskekse 🎄🍪

Stell dir Oma beim Keksebacken vor:

  • Holt sie jedes Jahr neue Keksformen? Nein.
  • Braucht sie immer mehr Ausstecher, um dieselben Vanillekipferl zu machen? Natürlich nicht.

Die Formen halten jahrelang – und die Rezepte sowieso.


Die Wirtschaftlichkeit der Stanzmaschinen 🏭🔩

Es gibt Firmen, die Blech stanzen. Sie kaufen sich einmal Stanzmaschinen, die jahrzehntelang laufen.
Nur die Formen (die Werkzeuge) werden ab und zu getauscht – je nach Auftrag oder Abnutzung.

Keiner käme auf die Idee, die ganze Maschine jedes Jahr wegzuschmeißen.


LEGO® und die Kunst der Wiederverwendung 🧱✨

LEGO® bringt ständig neue Sets heraus – Raumschiffe, Schlösser, Dinosaurier, super geile Kampfroboter mit Laser, Phaser und Chat GPT 😉. Aber die meisten Steine sind seit Jahrzehnten gleich: Noppen oben, Löcher unten.

Die Maschinen, die die Steine spritzen, laufen jahrzehntelang. Sie werden nur ersetzt, wenn Automatisierung, Energieeffizienz oder Industrie-4.0-Spielereien echte Vorteile bringen.


Fazit 🤔

Liebe Firmen,
wenn ihr seit Jahrzehnten Software entwickelt und trotzdem jedes Jahr mehr Entwickler braucht, dann stellt euch bitte mal die Frage: Warum?

Vielleicht liegt’s daran, dass eure Software gar nicht so soft ist.
Vielleicht ist sie eher wie Hardware: starr, schwerfällig und unflexibel.

Und wenn das so ist … dann wundert euch bitte nicht, dass die Personalkosten explodieren. 😉

Das Küchenmesser als Analogie für UI und UX

Ein gut gestaltetes Layout und eine effektive grafische Benutzeroberfläche (GUI) für eine Anwendung können verglichen werden mit einem Küchenmesser inklusiver Griff. Dadurch wird es:

  • intuitiv: Nutzer wissen sofort, wie es zu verwenden ist (Worauf soll ich klicken?…).
  • sicher: Es minimiert Verletzungsrisiken (Falsche/Verkehrte Dateneingabe, doppelte Einträge, unabsichtliches Löschen von Daten,…).
  • handlich: Es liegt gut in der Hand (Es macht Spaß damit zu arbeiten…).
  • effizient: Man kann präzise und schnell schneiden (Was muss ich als Nächstes anklicken?…).
  • stabil: Es rutscht nicht aus der Hand (Ohje! Muss ich alles nochmal eingeben? Warum funktioniert es diesmal nicht?…).
  • klar: Es bedarf keiner langen Erklärung (die Dokumentation nicht wirklich notwendig, oder wenn es wegen ISO Standards udg. es sein muss, kann auf ein Screenshot und/oder die Erwähnung plus kurzer Tooltip-Text reduziert werden).

Selbst die fortschrittlichste Anwendung verliert an Wert, wenn sie nicht einfach und intuitiv zu bedienen ist, da sie dann selten und ungern genutzt wird.

Weitere verwandte Artikel über Design (UI) und User Experience (UX)…

Sauberkeit und Ordnung

Wie ich in meinem vorigen Beitrag geschrieben habe, habe ich an manchen Sommerferien, als Elektriker auf Baustellen, mein Taschengeld zum Ausgeben für Computerteile & Peripheriegeräte, aufgebessert.

Dabei müssten alle auf der Baustelle, also die Elektriker, Maurer, Installateure, Dachdecker usw., am Ende des Tages ihre Werkzeuge reinigen und ordentlich verstauen, die Materialien genauso… und am Ende mit dem Besen kehren.
Warum?

  1. Effizienz-Steigerung & Wirtschaftlichkeit I: man muss weniger/kaum nach Werkzeug/Materialien suchen, da alles an seinem Platz ist
  2. Effizienz-Steigerung & Wirtschaftlichkeit II: mehr Firmen können gleichzeitig/parallel arbeiten, da mehr Platz zur Verfügung steht
  3. Effizienz-Steigerung & Wirtschaftlichkeit III: man muss auf bestellte Materialien nicht warten, da der Mangel dieser, rechtzeitig erkannt und früh genug vorbestellt wird
  4. Unfall-Vermeidung: man kann nicht über nichts stolpern!
  5. Fehler und Mängel werden früher erkannt und beseitigt

Bei Softwareprojekte jedoch, so scheint es mir, sind Dinge wie Effizienz, Wirtschaftlichkeit, Qualität und Nachhaltigkeit keine erstrebenswerten Merkmale.

Wie sonst kann man folgendes erklären: Man sieht den Groschen, aber nicht den 500 € Schein?

Aufräumen von Code (+ Kommentare und Dokumentation, falls diese überhaupt existieren)?

Wozu? Es funktioniert ja eh! (bis es dann ordentlich kracht)

Vorsorgliche, langfristig-geplante, nachhaltige, gute Software-Architektur und -Management schaut anders aus!

Pläne & Planung

Als Student, während Sommerferien, arbeitete ich manchmal als Elektriker auf Baustellen, und erledigte die Aufgaben die man mir auftrug:
mit Schlagbohrer Löcher für Steckdosen und Schalter in die Mauer bohren, Büchsen für Schalter- und Steckdosen mit Elektriker-Gips in diese Löcher befestigen, Kabel verlegen/ziehen,… und zum Schluß die Steckdosen, Schalter und Verteilerkasten mit Drähte/Kabel verbinden, und am Ende das Ganze Testen.

Auf jede Baustelle gab man mir (als Elektriker) einen Plan in die Hand.

In diese konnte ich auf einem Blick sehen und lesen:

  • wo,
  • wie viele und
  • wie hoch die Steckdose eingebaut werden müssten
  • wo der Kabel-TV-Anschluss war
  • wo der Telefon-Anschluss
  • welche Steckdosen und Lampen hingen an welche Sicherung (Fehlerstromschutzschalter)
  • wie groß/stark sollte die Sicherung dimensioniert sein
  • wie stark (Querschnitt) die Drähte und Kabel

und so weiter.

Die Installateure, die Maurer, die Dachdecker… kurz: alle anderen sind auch ständig mit ihre Pläne herumgelaufen, schauten immer wieder gemeinsam darein, diskutierten miteinander darüber, und machten nach Plan weiter.

Obwohl trivial, doch ich möchte und muss hier erwähnen, dass Kabel, Steckdosen, Schalter, Sicherungen und Verteilerkasten materielle, also sichtbare und greifbare Dinge sind.

Als Softwareentwickler, werde ich meinen Wunsch, einen UML-Diagramm zu erhalten, mit ins Grab nehmen!