[Helmut S]

Zitat von keko#

Warum habe ich dann schon 100000 Bugs gesehen, wenn das kein Problem war?

Die Faustregel 40-20-40 is im Grunde die allgemeingültige Antwort.

Die Hauptaufwände eines Softwareprojektes liegen der fachspezifischen Analyse, dem Design, der Qualitätssicherung und des Tests.

Coding macht einen vergleichsweise kleinen Teil in einem Softwareprojekt aus. Coding ist je nach Projektgröße/-komplexität, Programmiersprache, Integrationsaufwand, Methoden usw. in einem Bereich von 20%. Bei komplexen Projekten ist der Codinganteil kleiner, bei einfachen Projekten größer.

---------------------

Die Erfahrung zeigt, dass die meisten der Programmfehler ihre Ursache in mangelnder Analyse, fachlichen Missverständnissen oder schlechtem Testsetup haben. Hierfür liegt der Grund oft im Management bis runter zum Projektleiter. Falsche Aufwandsschätzung, Feature Inflation, fehlende/zu wenige Ressourcen, Termindruck... you name it

Fehlerhaftes Coding ist in nur wenig Fällen für Bugs in Produktionscode verantwortlich und wenn, dann ist das schlicht Inkompetenz des Entwicklers und Schlamperei des Teams, allen voran des Projektleiters (ggf. Entwicklungsleiters). Es ist seine Aufgabe auf Prozessebene sicher zu stellen, dass das nicht passiert.

Am Ende ist es natürlich auch eine Qualifikationsfrage. Mal einen Code zu programmieren, das lernen Ingenieure oder viele Naturwissenschaftler im Studium. Es gibt da Vorlesungen wie "Programmieren in Java" o.ä. Mit Softwareentwicklung oder gar Softwareengineering hat das noch nichts zu tun. Leute auf dem Niveau, die sich nicht weiter qualifiziert haben, sind für ernsthafte Projekte im Softwarebereich unbrauchbar. Diese Leute können heute und sofort durch KI ersteht werden.

Btw: Nur weil einer ein Informatik abgeschlossen hat, heißt das auch nicht, dass er programmieren kann. Ein wesentlicher Fehler in den ersten Jahren nach der Bologna Reform war, dass die FHs sehr stark auf Wekzeugwissen abgehoben haben. Konzeptionelle Grundlagen fehlten teilweise völlig. Mittlerweile hat sich das wenigstens Ansatzweise geändert, wenn ich mir die Modulhandbücher ansehe.

Ich will das Qualifikationsthema nicht weiter ausführen. Aber es gäbe nach zich betreuten Diplom-, und Abschluß- und Praktikumsarbeiten einiges zu sagen zu Fachinformatiker für Anwendungsentwicklung, zu Bachelor/Master vs. Diplom und zu FH versus Uni und vieles mehr.

Vielleicht noch einen Hinweis: Eine zentrale Fähigkeit für jemanden, der in Softwareprojekten arbeiten will ist Abstraktionsfähigkeit. Das ist auch der Grund, warum i.W.S. mathematisch ausgebildete Personen gar nicht so schlecht in ein Team passen. D.h. aber noch nicht, dass die gut Programmieren können.

---------------------

[...]

Zitat von keko#

Woher nehmen sie ihr Wissen dafür? Sollte nicht auch gleich eine KI das coachen übernehmen?

Wenn ich noch vor einem halben Jahr den Aufwand eines ernsthaften Programmierers bei 20/80 bzgl. KI Coding / Human Coding gesehen habe, würde ich heute das Verhältnis eher umgekehrt bei 80/20 sehen. Gerade Claude ist wirklich, wirklich gut.

Wenn wir also über Coding durch KI reden, sprechen wir grob von 20% Projektaufwand der durch die Anwendung von KI produktiver gestaltet werden kann. Allerdings, wie sehr leicht einsichtig ist, nicht zum Nulltarif: Irgendjemand muss, vereinfacht gesagt, das System auch prompten.

Trotzdem sind in den anderen 80% eines SW Projektes noch da und entscheidend. Freilich, auch hier sehe ich Möglichkeiten des KI Einsatzes. Ich kann mir z.B. schon vorstellen, dass ein KI Agent die Infrastruktur eines Unternehmens analysiert und Architekturentscheidungen trifft. Ich hätte an der Stelle aber das Bedürfnis eine Security Debatte zu führen. Auch in der QS kann ich mir einiges vorstellen. Ggf. sogar auch in CD/CI bzw. DevOps Prozessen.

---------------------

Am Ende hätte ich eine Bitte: Lass uns sauber unterscheiden zwischen Programmieren, Softwareentwicklung und Softwarengineering.