Fragen? Antworten! Siehe auch: Alternativlos
Mein Eindruck ist, dass Softwareentwicklung in der Industrie immer mehr als Randdetail betrachtet wird. Die Werbung prügelt da ja auch immer in die selbe Richtung. "Mit diesem Produkt wird alles NOCH VIEL EINFACHER!" Da kann man dem Management schon nachsehen, wenn die glauben, das sei alles total einfach. So viele Evolutionssprünge in Richtung "jetzt NOCH EINFACHER!1!!" wie wir schon gemacht haben. Und es stimmt ja auch. Damals unter DOS hatten wir keinen Speicherschutz und mussten Swapping selber implementieren! Damals unter C, wenn wir da einen Zeiger verlegt haben, dann gab es Speicherkorruption! Damals in den Schützengräben, wenn wir da einen Datenblock freizugeben vergaßen, dann leakte der Speicher!! Kann man sich heute gar nicht mehr vorstellen!1!!
Scherz beiseite: Heutzutage liegt der Fokus bei Leuten, die über die Entwicklung von Software reden, häufig auf Management-Dingen. Sowas wie Extreme Programming. In der Ausbildung (der Hinweis kam gerade per Mail rein, und ich gebe das gerne weiter) wird der Eindruck erweckt, man klickt sich in seinem UML-Tool ein Flowchart zusammen, und dann ist die Software fertig. Das tatsächliche Hinschreiben ist dann ein niederer Akt, den kann man ja auch einer Outsourcing-Firma in Indien überlassen.
Dieser Ansatz ist bei Software genau so falsch wie bei allen anderen Dingen. Ganze Industriezweige haben sich inzwischen dem Management und der Qualitätskontrolle von per Outsourcing hergestellten Produkten verschrieben. Der Westen macht überhaupt nur noch Management und Qualitätskontrolle, die Produkte machen die Billiglohnländer. Bei Software ist das noch nicht so, aber wenn man sich Fachzeitschriften durchliest, könnte man den Eindruck gewinnen.
Ich sehe das so: Der Code ist am Ende das Produkt. Nicht der Plan für den Code. Nicht die Broschüren. Nicht die Meetings. Der Code.
Die Kern-Sorge in der Softwareentwicklung sollte daher auch der Code sein.
Die Maßstäbe sollten wie in anderen Ingenieursdisziplinen auch sein. Elektriker legen Kabel ja auch nicht wild in der Gegend herum. Wenn ihr mal bei einem Auto die Motorhaube aufmacht, dann kommt euch ja auch kein Kabelsalat entgegengequollen. Das ist alles so ausgelegt, dass man es schnell und unkompliziert warten kann. Bei Code sollte man das auch so tun.
Dementsprechend ist Code auch nicht fertig, wenn die Funktionalität da ist. Das ist nur der erste Prototyp. Code ist fertig, wenn niemandem im Team ein Weg einfällt, irgendetwas daran besser zu machen.
Übrigens, nochmal als Nachschlag zu dem anderen Softwareentwicklungs-Artikel. Wenn ihr ein System optimieren wollt, dann empfehle ich, da mit der Frage heranzugehen: Wie kriege ich das mindestens doppelt so schnell? Gar nicht mit Klein-Klein aufhalten. Guckt euch das System an. Legt euch den Gedanken zurecht, dass die Konkurrenz das selbe Problem auf der selben Hardware in der halben Zeit löst, und ihr müsst das jetzt besser als die machen. Die größte Hürde beim Bessermachen ist, dass die Leute sich selbst einreden, das sei schon alles gut genug, oder es sei zu riskant, da jetzt für inkrementelle Verbesserungen den Code anzufassen. Wenn man wirklich was erreichen will, muss man da mental diesen Holzklotz aus dem Weg räumen, der einem sagt, soooo viel besser geht das gar nicht, dass sich jetzt der Aufwand lohnen würde. Zu der Feststellung kann man immer noch kommen. Aber das sollte am Ende der Überlegungen stehen, nicht am Anfang.
Update: Jetzt gehen hier diverse Mails ein, dass Elektriker ja inzwischen auch pfuschen, und dass Autos inzwischen so gebaut werden, dass sie eben nicht mehr wartbar sind, sondern man nur noch ganze Komponenten austauscht, und das auch nur geht, wenn man Spezialwerkzeug hat, das man nicht frei kaufen kann, sondern dass die nur an ihre Lizenzwerkstätten vergeben. Ja, weiß ich. Hatte gerade kein besseres Beispiel zur Hand. Nehmt es also als Verweis auf die guten alten Zeiten, wie sie früher mal waren, als alles besser war. Seufz.