Paretoware //2681

Fortschritte verlaufen in der Softwareentwicklung nicht linear. Ziemlich schnell hat man einen im Wesentlichen funktionierenden Prototypen, aber die Feinheiten ziehen sich halt hin.

Nehmen wir als Beispiel, dass eine zu implementierende Funktion bestimmte Daten als Datei abspeichern soll. Die Daten werden in geeigneter Form von einer anderen Funktion aufbereitet und bereitgestellt, die uns jetzt nicht zu interessieren braucht. Als Parameter erhält unsere Funktion den Dateinamen (samt Pfad) der zu schreibenden Datei.
Da ist es (bei ausreichender Vorbereitung) vielleicht nur eine Zeile Code, die Daten in die Datei zu schreiben, und normalerweise funktioniert das einwandfrei.

Was aber, wenn nicht? Denn es gibt so viele Gründe, warum der Speichervorgang schief gehen könnte. Eine vollständige Liste dürft ihr hier nicht erwarten. Aber es fängt schon damit an, dass manche Zeichen für Dateinamen nicht zulässig sind. Dann müssen die Verzeichnisse im Pfad existieren. Wenn die Datei bereits vorhanden ist, könnte sie schreibgeschützt sein. Oder das ganze Speichermedium ist schreibgeschützt. Eventuell fehlen die Zugriffsrechte. Oder die existierende Datei ist von einer anderen Anwendung gelockt. Vielleicht ist der Datenträger auch so voll, dass die Daten nicht mehr drauf passen. .. Wie gesagt, das sind bei weitem nicht alle möglichen Problemursachen. Und natürlich kann auch beim Aufbereiten des Datenstreams etwas schief gehen, während der Schreibvorgang vielleicht schon begonnen hat. Oder irgendein anderes Problem tritt gleichzeitig auf, das noch nicht einmal etwas mit dem Schreiben zu tun haben muss.

Wenn man die Software sauber programmieren will, müssen alle diese Fälle abgefangen werden, bevor sie für die Anwender freigegeben werden kann. Und wenn dann mal so ein Fall auftritt, wollen die Anwender sogar noch eine aussagekräftige Fehlermeldung.

Viele Softwerker meinen ja, dass die Pareto-Verteilung von 20:80 Softwareentwicklung nicht angemessen beschreibt. Prototypen mit grundlegender Funktionalität hat man bereits mit geringem, vielleicht 10% Aufwand. Aber bis die Software richtig ausgereift ist, und ein ansprechendes GUI hat, so dass jeder DAU sie problemlos und größtenteils intuitiv bedienen kann, muss noch viel Zeit und Arbeit hineingesteckt werden.

Nicht alle Fehler eines Produkts sind offensichtlich. Manche treten nur sporadisch auf, andere haben Seiteneffekte, die man überhaupt nicht korrekt zuordnen kann, manche führen unbemerkt zur Instabilität des ganzen Systems oder bringen es gar zum Absturz.
Ich erinnere mich an einen Fall, da wurden in einem bestimmten Modus die GDI-Handles nicht sauber freigegeben. Erst nach längerer Zeit wurden dann systemweit Icons oder andere graphische Elemente nicht mehr angezeigt. Wenigstens war das im Grunde eine harmlose Sache, ohne größere Auswirkungen. Die Ursache zu finden, hat allerdings lange gedauert.
Ich habe daraus gelernt. So etwas passiert mir nicht mehr.
Die Zeit für gründliche, sorgfältige Prüfungen und Tests muss man sich auf jeden Fall nehmen, selbst wenn das Produkt auf den ersten Blick einwandfrei erscheint (und noch so dringend benötigt wird).

Werbung