"Diese Website ist recht einfach. Alles, was Sie tun müssen, ist X, Y, Z zu erledigen. Sie scheinen technisch sehr versiert zu sein, daher glaube ich, dass Sie nicht viel Zeit brauchen werden, um sie aufzubauen."
Ich erhalte von Zeit zu Zeit solche E-Mails. Fast alle Leute, die diese E-Mails schreiben, sind entweder nicht technisch versiert oder arbeiten an ihrem ersten Produkt. Anfangs, als ich Leute so etwas sagen hörte, war ich immer sehr verärgert. Wer waren sie, um über die Zeit zu streiten, die Softwareentwicklung braucht? Aber später wurde mir klar, dass sogar ich selbst ratlos bin, wenn ich vorhersagen soll, wie viel Entwicklungszeit meine eigenen Projekte in Anspruch nehmen werden. Wenn ich es nicht einmal selbst kann, warum sollte ich mich dann über diese Leute ärgern?
Was mich wirklich deprimiert, ist nicht der Fehler in ihren Schätzungen. Das Problem ist, dass sie tatsächlich glauben, eine korrekte Schätzung abgeben zu können. Als Entwickler stellen wir oft fest, dass ein Außenstehender, wenn es um Softwareentwicklung geht, komplexe Dinge natürlicherweise als sehr einfach einschätzt.
Das ist keine Entschuldigung für unseren Ärger. Aber es wirft eine andere interessante Frage auf: Warum versagt unsere angeborene Fähigkeit, Komplexität vorherzusagen, bei Programmierproblemen?
Um diese Frage zu beantworten, schauen wir uns an, wie unser Gehirn Dinge einschätzt. Manche Dinge kann selbst eine unerfahrene Person leicht richtig einschätzen, andere hingegen nicht.
Denken wir daran, jemandem beim Gitarrespielen zuzusehen. Selbst wenn du noch nie Gitarre gespielt hast, kannst du nach einer Gitarrendarbietung von „Mary Had a Little Lamb“ grob erraten, dass sie einfach ist und dass man keine sehr fortgeschrittenen Fähigkeiten braucht, um sie zu spielen. Ebenso kannst du nach dem Anhören von jemandem, der Pachelbels Kanon in D-Dur spielt, leicht folgern, dass er komplex ist und langes Üben erfordert, um ihn zu spielen.
Warum können wir die Komplexität dieser beiden Stücke schnell und genau einschätzen? Das hängt mit den Methoden zusammen, mit denen wir beurteilen, ob etwas einfach oder komplex ist. Unser Gehirn hat einige fertige Muster, um diese Aufgaben zu bewältigen, und das erste basiert auf Geschwindigkeit. In diesem Fall erkennt das Gehirn, wie viel pro Sekunde gespielt wird. Anhand der Menge, die pro Sekunde gespielt wird, können wir uns leicht ein intuitives Urteil über die Komplexität des Stücks bilden. Da das Spielen eines Liedes auf der Gitarre ein physischer Prozess ist, eine sensorische Aktivität, kann unser Gehirn daraus leicht die Geschwindigkeit ableiten und sie dann in Komplexität umwandeln.
Wir haben auch eine weitere angeborene Grundlage für die Einschätzung: das Volumen. Denken wir daran, ein Zelt mit einem Mehrfamilienhaus zu vergleichen. Selbst wenn jemand nie Architektur studiert hat, kann er dir sagen, dass das Entwerfen und Bauen eines Zeltes normalerweise einfacher ist als das Entwerfen und Bauen eines Mehrfamilienhauses. Warum? Weil wir physisches Volumen von Natur aus als Indikator für die Komplexität einer Sache verwenden.
Natürlich sind diese beiden Arten der logischen Analyse nicht immer 100% wirksam. Aber in den meisten Fällen machen es die Menschen so, und zwar mit großem Erfolg. In den meisten Situationen stellt unser Gehirn bei der Bewertung physischer Prozesse wirksame Assoziationen zu physischen Objekten her, ohne sich auf frühere Erfahrungen verlassen zu müssen.
Sprechen wir nun über Software. Wenn eine nicht-technische Person versucht, die Entwicklungszeit von Software einzuschätzen, helfen ihr zwei sehr grundlegende intuitive Indikatoren: Komplexität gemessen am Umfang und Komplexität gemessen an der Geschwindigkeit. Doch diese Person erkennt nicht, dass Software nicht das ist, was sie sich darunter vorstellt. Software ist im Wesentlichen keine greifbare Substanz. Sie hat weder Umfang noch Geschwindigkeit. Ihre winzigen Bestandteile mögen gelegentlich über den Computerbildschirm blitzen. Aus diesem Grund versagen unsere grundlegenden intuitiven Sinne, wenn wir vor der Entwicklung einer Webanwendung (oder irgendeiner Art von Software) stehen.
Der erste Punkt, die Geschwindigkeit, kann von einem Außenstehenden offensichtlich überhaupt nicht zur Bewertung von Software herangezogen werden. Daher neigen sie natürlich dazu, den Umfangsindikator zur Bewertung zu verwenden. Entweder anhand der Anzahl der Seiten im Spezifikationsdokument oder anhand der Anzahl der Anwendungsfälle oder Funktionen der Software.
Manchmal funktioniert diese Bewertungsmethode tatsächlich! Bei einer statischen Website ohne besondere Designanforderungen kann ein Außenstehender die Entwicklungszeit auf diese Weise leicht schätzen. Aber normalerweise kann der Umfang bei der Softwareentwicklung die Komplexität nicht wirklich und effektiv widerspiegeln.
Leider basiert die einzige effektive Methode zur Einschätzung der Softwarekomplexität auf Erfahrung. Und selbst das funktioniert nicht immer gut. Als Programmierer weiß ich, dass ich anhand ähnlicher Funktionen, die ich zuvor entwickelt habe, einschätzen kann, wie viel Entwicklungszeit jede der aktuellen Funktionen beanspruchen wird. Dann addiere ich die Gesamtzeit, und das gibt mir eine grobe Schätzung, wie lange das gesamte Projekt dauern wird. In der Realität stößt jedoch jedes Projekt während der Entwicklung auf zwei oder drei Engpässe. Diese Engpässe können rücksichtslos große Mengen an Zeit eines Programmierers verbrauchen, und man kann sie nicht vorhersehen, bevor man auf sie stößt. Sie können das gesamte Projekt aufhalten und um Wochen oder sogar Monate verzögern.
Das sind Dinge, die unerfahrene Menschen nicht verstehen, wenn sie die Komplexität einschätzen. Sie verstehen nicht, warum Methoden, die bei anderen Dingen gut funktionieren, nicht funktionieren, wenn sie auf die Softwareentwicklung angewendet werden. Wenn Sie also das nächste Mal jemanden sagen hören: "Ich denke, du kannst es in ein paar Tagen entwickeln", egal wer es sagt, regen Sie sich nicht auf. Atmen Sie tief durch, zeigen Sie ihnen die Adresse dieses Artikels und machen Sie mit dem weiter, was Sie gerade getan haben.
[Originaler englischer Text:Ich bin sicher, es dauert nur ein paar Tage, bis du es programmiert hast ]