Bei der Software-Entwicklung gibt es ein bekanntes, aber nicht dokumentiertes Phänomen, die Balkon-Programmierung. Vermutlich deutet sie auch auf tiefer liegende menschliche Schwächen und Gewohnheiten.
Doch zunächst zu dem Phänomen der Balkon-Programmierung selbst:
Wenn man ein Programm soweit fertig gestellt hat, dass es im Wesentlichen funktioniert, nur leider nicht in ein paar Sonderfällen (oder was man dafür hält), so ist man geneigt, das Software-Gebäude um entsprechende Balkone zu ergänzen, so dass auch noch diese Sonderfälle abgedeckt sind. Das rettet den Programmierer bis zum nächsten Kundentermin – oder bis zum nächsten zufällig entdeckten Sonderfall. So kommt im Laufe der Zeit ein Balkon zum anderen dazu.
Zum Schluss versteht keiner mehr das Programm, das aus mehr Balkonen als aus eigentlicher Problemlöse-Substanz besteht. Dann ziehen die Balkone mehr Aufmerksamkeit auf sich als das eigentliche Sachproblem.
Wenn man die Grundlagen nicht völlig klar stellt und die eigentliche Substanz absolut in Ordnung bringt, verliert man zu viel Zeit an Balkonen und von ihnen verursachte Sekundärproblemen. Wenn man die Grundprinzipien nicht glasklar durchschaut, wird man immer wieder mit Zufällen, Ausnahmen und angeblichen Sonderfällen konfrontiert, deren Abarbeitung so viel Zeit frisst, dass man zum Eigentlichen nicht mehr kommt. Das gilt für Software-Systeme, Sozial- und Finanz-Systeme gleichermaßen.
Hier ist die Informatik näher an der Mathematik mit ihrer 100%-igen Korrektheit als an den Ingenieur-Wissenschaften. In den Ingenieur-Wissenschaften kann man sehr gut mit der 80-20-Regel leben. Man versucht erst gar nicht 100%-ige Perfektion. 80%-ige Korrektheit tut es meistens auch. Für die restlichen 20% müsste man unverhältnismäßigen Mehraufwand betreiben, so dass das Unterfangen unwirtschaftlich würde. Daher muss die statische Berechnung genügend Sicherheitsspielraum enthalten, so dass die Brücke auch bei ungenauen Berechnungen noch standhält.
Von „Software-Ingenieuren“ oder „Software-Engineering“ zu reden ist daher irreführend. Software-Konstruktion ist keine Ingenieurstätigkeit. Oder anders herum formuliert: Wenn Software ingenieursmäßig konstruiert wird, dann ist sie weniger eine Problemlösung als vielmehr Ursache für eine Vielzahl von Sekundärproblemen.