Softwareentwicklung
04.11.2020, 11:55 Uhr
Warum dauert das so lange?
Die Frage aus der Überschrift oder Variationen davon werden häufig gestellt. Ingenieur Justin Etheredge ist der Frage nachgegangen und hat nach Erklärungen gesucht.
Warum dauert es so lange, Software zu entwickeln? Diese und Variationen dieser Frage sind häufig zu hören: Warum ist das Erstellen von Software so teuer? Warum liefert mein Team Software so langsam aus? Warum liege ich mit meiner Software ständig hinter dem Zeitplan zurück?
Obwohl Unternehmen laufend mehr mehr kundenspezifische Software brauchen um wettbewerbsfähig zu bleiben nimmt das Gefühl zu, dass mit der Zeit die Geschwindigkeit, mit der Software ausgeliefert wird, stagniert oder schlimmer noch, langsamer wird.
Justin Etheredge sagt, dass es beim Lösen von Problemen, nicht nur von Softwareproblemen, zwei Arten von Komplexität gibt: die essentielle Komplexität und die zufällige Komplexität.
- Essentielle Komplexität ist die Problem-inhärente Komplexität. Das Problem lässt sich nicht ohne diese Komplexität in Angriff zu nehmen.
- Zufällige (accidental) Komplexität - Dies ist eine Komplexität, die mit dem Ansatz und den Werkzeugen einhergeht, die Sie zur Lösung eines Problems verwenden. Diese Komplexität ist nicht Teil des eigentlichen Problems, das Sie lösen, sondern dies ist die Komplexität, die Sie mit Ihrer Lösung einbringen.
Diese Idee stammt aus Fred Brooks' Arbeit "No Silver Bullet – Essence and Accident in Software Engineering". Stellen Sie es sich so vor: Wenn Sie versuchen, eine mathematische Aufgabe zu lösen, ist die wesentliche Komplexität das Verständnis der Mathematik, das erforderlich ist, um tatsächlich eine Lösung zu berechnen. Wenn Sie das Problem lösen wollen, müssen Sie die erforderliche Mathematik lernen (oder jemanden finden, der sie beherrscht). Sie können der Mathematik nicht entkommen, wenn Sie das Problem lösen wollen.
Hier kommt die zufällige Komplexität: Angenommen, es handelt sich um ein anspruchsvolles mathematisches Problem und alles im Kopf zu machen, wäre wirklich unproduktiv. In diesem Fall werden Sie einen Taschenrechner verwenden wollen. Das ist die zufällige Komplexität. Erinnern Sie sich an das erste Mal, als Sie versuchten, einen graphischen Taschenrechner für etwas mehr als nur einfache Mathematik zu verwenden? Die zufällige Komplexität besteht darin, zu lernen, wie man den dummen TI-83 benutzt, um die gesamte komplexe Mathematik einzugeben, damit Sie Ihr Problem lösen können. Sie brauchten keinen Taschenrechner zu benutzen, aber Sie wussten, dass er Ihnen helfen würde und wahrscheinlich nicht allzu schwer zu lernen sein würde.
Aber lassen Sie uns für eine Minute so tun, als ob Sie mit Mathematica vertraut wären. Mathematica ist ein unglaublich mächtiges und komplexes Stück Software, aber da Sie es bereits kennen, entscheiden Sie sich, Ihr Problem damit zu lösen. Sie haben bereits in das Erlernen von Mathematica investiert, so dass es für Sie kein großer Mehraufwand war, aber Sie haben gerade die zufällige Komplexität Ihrer Lösung um einen astronomischen Betrag erhöht.
Ein paar Wochen später befindet sich ein Kollege von Ihnen in einer ähnlichen Situation und erinnert sich, dass Sie ein sehr ähnliches Problem gelöst haben. Er kommt zu Ihnen, um zu sehen, wie Sie das Problem gelöst haben, und Sie schicken ihnen das Mathematica-Projekt. Glauben Sie, dass er Mathematica lernen wird? Eher nicht. Er wird einen anderen Weg finden, um das Problem zu lösen, oder versuchen, Sie dazu zu bringen, es für ihn zu lösen.
Wie Sie sehen, kommen die beiden Arten von Komplexität von verschiedenen Orten, aber sie sind untrennbar miteinander verbunden. Man kann ein Problem nicht ohne eine zufällige Komplexität lösen. Selbst Bleistift und Papier bringen eine winzige Menge an zufälliger Komplexität mit sich.
Wie diese Problematik bei Softwareprojekten wirkt und ob sie zu- oder abnimmt lesen Sie in diesem englischsprachigen Artikel von Justin Etheredge auf Simplethread.com.