Ein CTO kann Software einkaufen, aber nicht die Verantwortung für ihre Datenwege. Gerade bei geerbten Anwendungen wirken Eigenentwicklung und Kauf zunächst wie eine Budgetentscheidung; später entscheidet sich jedoch, wer einen unerwarteten Datenabfluss nachweisen, stoppen und erklären kann. Meine Position: Kaufen ist oft die bessere Wahl, sofern der Anbieter überprüfbare Kontrolle…
Du brauchst eine kleine Windows-Anwendung für einen Auftrag, aber weder Build-Server noch Zeit für ein Architekturprojekt. Mein Vorschlag ist bewusst eng: Starte mit einem WPF-Fenster, einem ViewModel und einem lokalen Speicherort. Eine funktionierende Übergabe ist für Solo-Freelancer wertvoller als eine Infrastruktur, die erst nach dem Auftrag Nutzen bringt. Die Grenze…
Eine geerbte Qt-Anwendung soll weiterlaufen, doch für Wartung, Tests und Releases gibt es weder belastbare Schätzungen noch viel Budget. Meine Position: Ein kleiner Etat rechtfertigt einen kleineren Freigabeumfang, aber keine abgespeckte Absicherung für die Änderungen, die tatsächlich ausgeliefert werden. Wer beides verwechselt, beauftragt scheinbar günstige Entwicklung und trägt das unbezifferte…
Eine geerbte WinForms-Anwendung ohne Tests lädt zu einer großen Aufräumaktion ein: Formulare entflechten, Framework aktualisieren, Oberfläche automatisieren. Ich würde anders beginnen. Als QA-Ingenieur brauchst du zuerst eine überprüfbare Grenze um das bestehende Verhalten, selbst wenn dieses Verhalten unschön ist. Meine Position: Eine kleine, gezielt getestete Änderung an einem häufig genutzten…
Eine WPF-Anwendung kann für einen einzelnen Auftraggeber hervorragend funktionieren und trotzdem mehr Wartungsarbeit erzeugen, als ein Freelancer bezahlen kann. Seit 2024 haben sich vor allem die .NET-Laufzeiten und die Möglichkeiten für ein zeitgemäßes Erscheinungsbild verändert. Meine Position: Nicht die modernste Architektur ist heute der beste Standard für Solo-Projekte, sondern eine…
Ein grüner CI-Build sagt wenig darüber aus, ob eine JavaFX- oder Swing-Anwendung am Montagmorgen auf einem verwalteten Arbeitsplatz startet und bedienbar bleibt. Teams behandeln Desktop-Releases trotzdem oft wie Server-Deployments: Artefakt bauen, Prozess prüfen, Ticket schließen. Das ist der falsche Betriebsvertrag. Für DevOps zählt zuerst, ob sich ein Fehler auf einem…
Die geerbte Swing-Anwendung hat keine verlässlichen Tests, aber der erste Vorschlag im Planungstermin lautet: „Dann migrieren wir eben zu JavaFX.“ Für QA ist das meist die falsche Reihenfolge. Ein neues GUI-Framework beseitigt keine unbekannten Erwartungen an die alte Anwendung; es macht sie zunächst schwerer zu beobachten. Ich würde zuerst das…
Du übernimmst eine Qt-Desktop-App ohne verlässliche Tests, und der erste Vorschlag lautet: „Wir automatisieren die Oberfläche.“ Das klingt sicher, weil Klicks sichtbar sind. Für die meisten geerbten Codebasen ist es trotzdem der falsche Standard: Ein GUI-Test sagt oft zu spät, was kaputtging, und bricht schon bei harmlosen Änderungen. Ich würde…
Der erste Skalierungsbruch im Software-Outsourcing ist selten der Code, sondern die Schnittstelle zwischen Entscheidung, Vertrag und Lieferung. Meine unbequeme Position: Ein CTO sollte eher standardisierte Lieferfähigkeit einkaufen als vorschnell intern aufbauen, solange die Domäne nicht das Differenzierungszentrum ist, weil interne Teams bei wachsender Unsicherheit langsamer lernen als ein eingespieltes Liefermodell.…
Bei Magento skaliert selten zuerst der Webserver, sondern die Verantwortung für Seiteneffekte: Preisregeln, Indexer, Cache-Invalidierung, Suche, Checkout und Releases greifen ineinander. Meine Position ist unbequem: Ein CTO sollte Magento nur dann in-house skalieren, wenn das Geschäftsmodell an Kataloglogik, Preisbildung oder Checkout-Differenzierung hängt, weil sonst der Betrieb schneller teuer wird als…