Softwareentwicklung und Individualsoftware aus Hamburg.

Die meisten Aufgaben löst Standardsoftware besser und billiger, als ich es je könnte. Ein Warenwirtschaftssystem neu zu bauen, weil das gekaufte an zwei Stellen unbequem ist, ist fast immer ein teurer Fehler. Deshalb fängt jedes Gespräch mit der Frage an, ob überhaupt gebaut werden muss.

Interessant wird Eigenentwicklung dort, wo euer Ablauf tatsächlich anders ist als der aller anderen — meistens genau da, wo euer Geld verdient wird. Das sind die Stellen, an denen Standardsoftware euch zwingt, euren funktionierenden Prozess an ein Formular anzupassen. Und es sind die Stellen, an denen zwischen zwei gekauften Systemen eine Lücke klafft, die momentan ein Mensch mit Copy-und-Paste überbrückt.

Wenn du dir nicht sicher bist, in welche Kategorie dein Problem fällt: das herauszufinden ist Teil der Arbeit, nicht deine Hausaufgabe vor dem ersten Gespräch.

Der Schwerpunkt liegt auf Software, die intern benutzt wird und deshalb selten schön aussehen muss, aber jeden Tag funktionieren: Werkzeuge für die eigenen Leute, Portale für Kunden, und die Verbindungen dazwischen.

• Web-Anwendungen, interne Werkzeuge und Portale
• APIs und Schnittstellen zwischen euren Systemen
• Architektur-Beratung, Code-Reviews, zweite Meinung
• Bestehendes modernisieren statt teuer neu bauen
• Tests, Dokumentation und ein Deployment, das ihr selbst bedient

Alte Software hat einen schlechten Ruf, den sie sich oft nicht verdient hat. Ein System, das seit zehn Jahren läuft, hat zehn Jahre lang Sonderfälle gelernt, die in keiner Anforderungsliste stehen. Ein Neubau fängt bei null an — und entdeckt diese Sonderfälle einzeln wieder, im Betrieb, meistens zum ungünstigsten Zeitpunkt.

Bevor ich über Ablösung rede, schaue ich mir an, was wirklich weh tut. Häufig ist es nicht der Kern, sondern die Ränder: eine veraltete Bibliothek mit bekannten Lücken, ein Deployment, das nur einer beherrscht, fehlende Tests, ein Datenmodell, das drei Umbauten hinter sich hat. Das lässt sich in Etappen geraderücken, während der Betrieb weiterläuft.

Manchmal ist der Neubau trotzdem die richtige Antwort. Dann sage ich das mit Begründung — und mit einem Weg, der nicht verlangt, dass ihr zwei Jahre lang stillhaltet.

Alle ein bis zwei Wochen gibt es etwas Fertiges zum Anfassen, nicht Monate Stille gefolgt von einem großen Release. Das ist keine Methodik-Frage, sondern eine Risikofrage: je früher ihr etwas benutzen könnt, desto früher fällt auf, wenn wir uns über eine Anforderung missverstanden haben.

Um die Stellen, die beim Kaputtgehen weh tun, kommen automatisierte Tests. Deployments laufen auf Knopfdruck, nicht über eine Anleitung im Kopf einer einzelnen Person. Dokumentation entsteht von Anfang an, nicht am Ende, wenn niemand mehr weiß, warum eine Entscheidung so gefallen ist. Diese Arbeitsweise kommt aus dem Konzernumfeld und ändert sich bei kleinen Projekten nicht — sie ist dort nur schneller erledigt.

Der Code gehört euch. Dazu kommen Dokumentation und eine Übergabe, in der jemand aus eurem Team oder ein anderer Dienstleister den Stand tatsächlich übernehmen kann, ohne bei null anzufangen.

Das ist ausdrücklich das Ziel: dass ihr das Ding ohne mich betreiben könnt. Eine Abhängigkeit vom Entwickler ist für euch ein Risiko und für mich kein Geschäftsmodell, an dem ich Freude hätte.