Mir wird das Schätzen immer suspekter. Warum tun selbst agile Entwickler das? Mal ehrlich? Auf der einen Seite wissen wir – und ich meine wirklich “wissen” –, dass es unmöglich ist, den Aufwand von Softwareentwicklung zu schätzen. Denn da wo etwas Neu ist, seien es Tools, Techniken, Teammitglieder, Aufgaben, Kunden… da kann man einfach nicht sagen, wie lang es dauert, Anforderungen umzusetzen. Das geht nicht.
Und selbst, wo die Anforderungen und sonstigen Rahmenbedingungen scheinbar soviel präziser sind, haut es nicht hin. Die Hamburger Elbphilharmonie ist da nur eines von vielen aktuellen und weithin sichtbaren Beispielen in Deutschland. Auf anderen Kontinenten und in anderen Branchen ist es aber auch nicht besser: Wie ist es zu erklären, dass das US Militär “a long-standing track record of over-promising and under-delivering with virtual impunity” hat? Da geht es doch um handfeste “Maschinen” wie Flugzeuge und Schiffe. Schiffe kosten nicht 220 Millionen Dollar, sondern das doppelte; Flugzeuge kosten nicht 2,7 Milliarden Dollar, sondern 35% mehr, also knapp 3,6 Milliarden Dollar.
Merkt denn noch einer etwas? Schätzen haut außer in trivialen Fällen nicht hin. Schätzungen sind meistenteils Lügen – weil sie in Bewusstheit ihres Fehlers abgegeben werden – und wenn nicht, dann sind sie Fahrlässigkeiten.
Auf der einen Seite wissen wir also all das – und auf der anderen Seite tun Softwareentwickler es doch immer und immer und immer wieder. Warum? Weil es so schön weh tut? Ja, mir scheint, ein gewisser Hang zum Masochismus scheint da mitzuspielen. Der drückt sich auch immer wieder in der Sprache aus, die den Softwareentwickler bzw. seine Abteilung oder sein Unternehmen zu einem willenlosen Opfer des Kunden macht. Denn der Kunde will es so. Der will eine Schätzung. Entweder direkt, indem er fragt, “Wie lange dauert das? Wieviel kostet es?” Oder indirekt, indem er vorgibt, “Das darf nur soundsoviel kosten und soundsolange dauern!”
Und dann kuschen sie alle. Kopf und Schwanz einziehen und frisch geschätzt. Oder die Schätzungen von Inkompetenten einfach übernehmen. Wird schon hinhauen. Irgendwie. Denn wenn nicht… dann Gnade ihnen der Markt, der neue Gott. Dann wird abgestraft, weil die Softwareentwicklung sich nicht als wettbewerbsfähig erwiesen hat.
Ich kann das nicht mehr hören.
Die ganze Welt verschätzt sich allermeistens. Aber keiner will das wahrnehmen. Und das Wurzelproblem angehen will schon gar keiner. Das ist nämlich erstens eine Mentalität des “Ich will meinen Arsch retten” und zweitens eine Verkennung der Realität des 21. Jahrhunderts. Über Ersteres will ich mich hier nicht weiter auslassen. Ein andermal vielleicht. Und zu Letzterem sei nur gesagt: Das Charakteristikum des 21. Jahrhunderts ist die Komplexität. Bis ins 20. Jahrhundert mag die Welt kompliziert gewesen sein. Sie schien mit Zuckerbrot und Peitsche und Maschinen bewältigbar. Doch das ist vorbei. Autos, Fernseher, Gesundheit, Fußballmannschaften, Ehen, Märkte, nationale Sicherheit… das alles ist in der Komplexität angekommen – allemal die Software. Das heißt: Nachdenken, hartes Nachdenken und Rumrechnen führt zu keinem sicheren Ergebnis mehr.
Die Architekten und Bauunternehmer der Elbphilharmonie haben sicherlich hart über die Kosten des Bau nachgedacht und nicht leichtfertig den ursprünglichen Millionenbetrag genannt – und trotzdem haben sie meilenweit daneben gelegen. Ebenso die Ingenieure bei Flugzeug- und Schiffsbauern der US Streitkräfte.
Die schlichte Möglichkeit zu einer verantwortungsvollen, verlässlichen Schätzung ist überbewertet. Sie grenzt geradezu an Aberglauben, sage ich mal.
Und diesem Aberglauben will nun auch noch die Agilitätsbewegung dienen? Das ist doch Quatsch, oder?
Nein, man komme mir jetzt nicht wieder mit “Aber der Kunde will das und deshalb müssen wir.” Wenn wir so als Art immer gedacht hätten, dann säßen wir noch auf den Bäumen in der Afrikanischen Savanne. Nur weil irgendwo ein Widerstand ist, geben wir als Art nicht nach. Wir sind da anders gestrickt. Widerstand hat uns immer herausgefordert. Wie ist sonst zu erklären, dass der Mensch von der Savanne ins ewige Eis ausgewandert und dort geblieben ist? Eskimos trotzen jeden Tag Widerständen. Warum? Die könnten doch sagen, “Die Natur ist hier so unwirtlich, die will uns hier nicht. Also weichen wir besser…”
Achso, die armen Eskimos konnten nicht anders? Das ewige Eis war für sie das kleinere Übel. Deshalb mussten, nein, wollten sie dort bleiben. Da bin ich im Zweifel, aber lassen wir die Eskimos. Wenden wir uns ungezwungen extremen Zeitgenossen zu wie Rüdiger Nehberg, Reinhold Messner oder dem weniger erfolgreichen Samuel Koch, der während der Wetten-dass-Sendung verunfallte. Sie alle lieben den Widerstand. Sie leben für die Überwindung von Widerständen. Genauso Mutter Theresa oder Muhammad Yunus, die sich sozialer Probleme angenommen haben.
Also verstecke man sich nicht dahinter, dass der Kunde, der allmächtige, dumme, arrogante, naive, herrschsüchtige Kunde ein solches Problem sei, dass der menschliche Geist nicht überwinden könne. Die Vertriebler der Welt, die Einkäufer der Welt sind nicht zur Wirklichkeit zu erwecken? Das ist für die Art, die den Planeten verlassen hat, ein zu schwieriges Problem?
Ich würde sagen, hier wollen Menschen einfach nur nicht. Niemand will sich den Schuh anziehen, dieses Problem zu lösen. Keiner will den ersten Schritt machen. Noch nicht einmal – um wieder zur Softwareentwicklung zurückzukommen – die ach so innovativen Agilisten. Stattdessen schwenken sie den StoryPoint-Zauberstab, rufen “Aestimatus!” und glauben, mit relatiben Aufwänden und ein bisschen Beobachtung sei das Problem aus der Welt gewünscht. Bullshit!
Relative Aufwände sind nur das: relative Aufwände. Wenn Aufgaben A, B, C laut Schätzung im Verhältnis 1:2:3 stehen, dann weiß man am Ende nur genau das. Aber nicht, wie lange die Realisierung dauert. Nicht, wenn A oder B oder C dank der Marktes oder der Politik oder der Technik oder einer Unpässlichkeit etwas Unwägbares enthalten. Das ist aber beim Geschäft der Softwareentwicklung sehr wahrscheinlich. Sehr, sehr wahrscheinlich sogar. Sonst hieße die Softwareentwicklung auch nicht Software-Entwicklung, sondern Software-Bäckerei oder Software-Schusterei.
Entwicklung als Tätigkeit ist inhärent unwägbar aufwändig. Das liegt an ihrem Auftrag und an ihrem Stoff. Sie soll kreativ sein. Sie muss sich mit Materialien und Werkzeugen rumplagen, die sich in irrwitzigem Tempo ändern. Nicht zu reden vom wetterwendischen Kunden, der heute dies will und morgen jenes. Und egal, was er will, so ganz genau weiß er eh nicht, was das ist. “Machen Sie das mal, Sie als Softwareentwickler wissen das am besten.” – nur leider findet er es am Ende doch nicht so gut, was die Softwareentwicklung aus dieser Freiheit gemacht hat.
Ich widerspreche daher der immer noch gängigen Schätzpraxis. Schätzen zum Zwecke einer Aufwandsbestimmung zum Zwecke einer Preis- und/oder Dauerfestlegung funktioniert für die Softwareentwicklung nicht. Heute nicht und wahrscheinlich in Zukunft nicht. Da helfen keine StoryPoints und keine lustigen Pokerspiele darum und keine Geschwindigkeitskurven.
Man mag relative Aufwände schätzen, um danach zu priorisieren oder Ressourcen zu allozieren. Wenn Anforderung A weniger aufwändig ist als Anforderung B, dann sollte sie deshalb früher (oder später) angegangen werden. Oder wenn B ansteht, dann sollen noch zwei Entwickler mehr ins Team, um die “processing power” mit ihren “Kernen” zu erhöhen. (Dass dafür der Entwicklungsprozess und Entwurf passen müssen, ist selbstredend.)
Mehr als das lässt sich aus relativen Aufwänden aber nicht ablesen. Alles andere ist Illusion, Augenwischerei und Rumgezappelt vor dem drohenden Blick des allmächtigen Kunden - der Unmögliches will.
Deshalb: Widerspruch gegen das Schätzen.
Statt das Unmögliche zu wollen, sollten wir uns jeden Tag anstrengen, die Wirklichkeit den Blinden und Naiven und Ignoranten, die sie nicht sehen können oder wollen, nahezubringen. Lasst uns Licht anzünden und zu ihnen tragen. Dann mögen sie lesen und sehen, wie die Welt ist: unschätzbar, wenn es um Komplexes geht. Und wo sollte das nicht der Fall sein, wenn es interessant wird? Mit Komplexität lässt sich Geld verdienen. Aber ehrlicher und friedlicher und gesundheitsschonender als heute auf der Basis widernatürlicher Schätzungen.
Die Abstraktionsebenen der Softwarearchitektur sind für mich diese:
Architektur macht zunächst auf den Abstraktionsebenen Bounded Context und App Längsschnitte durch das Anwendungssystem. Architektur schneidet es in dünne Scheiben. Die sind vollständig insofern, als dass sie vom Frontend bis zum Backend reichen.
App, Maschine und Prozess zerlegt die Architektur dann transversal weiter. Die funktionalen Scheiben werden “gewürfelt”, um insbesondere Skalierbarkeit, Performance und Verfügbarkeit zu erreichen. Jedes Teil stellt dann nicht mehr für sich einen Anwendernutzen her, sondern trägt nur dazu bei. (Hier ist die klassische Schichtenarchitektur anzusiedeln.)
Grad gibt es ja mal wieder Diskussion um eine Code Kata, die 
Gerade hat die 
