Warum Feature-Creeping deine Software-Projekte zerstört!

Man kann in der Softwareentwicklung eine ganze Menge Fehler machen, die sehr sehr große Probleme in den Projekten verursachen. Einer der größten Fehler und der mit Abstand mit den katastrophalsten Konsequenzen ist die rein Feature-getriebene Softwareentwicklung, oder auch Feature-Creeping genannt. Und obwohl Bedenken seitens der Softwareentwicklung, besonders der Softwareentwickler, angemeldet werden, geht das Ganze über Monate so weiter, über Jahre, in manchen Projekten sogar über ganze Jahrzehnte. Und am Ende folgt dann der große Knall. Obwohl man viele Kunden hat, obwohl man große Chancen am Markt hat, obwohl man vielleicht unglaublich viel Umsatz in der nächsten Zeit schaffen könnte – es passt keine Funktion mehr in das Projekt rein. Das Projekt ist tot, und damit hat das Unternehmen einen Schaden, der oftmals in die Millionenhöhe geht. Und auch wenn es ein bisschen wie die Schlagzeile aus einer Bild-Zeitung klingt, die Wahrscheinlichkeit, dass dein Projekt oder deine Projekte genau auf demselben Weg sind, ist durchaus gegeben. Vielleicht ist es sogar schon zu spät. Deshalb, liebe Softwareentwickler, zeigen wir heute mal, was es bedeutet in der Softwareentwicklung, wenn wir die ganze Zeit nur funktionsgetrieben entwickeln. Und liebe Product Owner, liebe Manager, liebe Geschäftsführer, liebe Vorstände, hört genau zu, weil am Ende haben wir da fast gar keine Schuld dran, sondern ja, der Hauptschuldige liegt bei euch. Ich würde sagen, nach dem Intro geht’s los. Viel Spaß! Dieses Video hier war lange überfällig. Ich glaube, es wurde sich kein Video mit ganz weitem Abstand so oft gewünscht wie ein Video zu dem Thema: Wie rein funktionsbasierte Softwareentwicklung die Softwareentwicklung in den Graben fährt.

Die meisten von euch haben aber gesagt, dass sie gerne ein Video haben möchten, was vom Sprachgebrauch, vom technischen Niveau nicht so ist, dass es nur für Softwareentwickler ist, sondern dass sie es gerne auch im Projekt verteilen wollen, an POs, an wen auch immer bei euch im Unternehmen. Und deswegen machen wir dieses Video mal. Wir zeigen alle Probleme, aber wir versuchen mal nicht so die technische Genauigkeit reinzugeben, die wir normalerweise in den Videos haben, sondern wir versuchen es mal auf einer Ebene, dass auch das Management die Problematik versteht. Wenn wir Softwareprojekte entwickeln, dann haben wir Leute, die Interesse dran haben, dass sich unsere Software weiterentwickelt. Das sind die sogenannten Stakeholder. Stakeholder können ganz viele verschiedene sein. Das sind natürlich primär die Kunden, die unsere Software benutzen, aber auch, keine Ahnung, die Architekten, der Support, die Entwickler. Es gibt eine ganze Menge an Stakeholdern. Habt wir schon in anderen Videos drüber geredet. Aber diese Stakeholder-Ideen, die dort generiert werden, die werden von Product Ownern normalerweise aufgenommen und werden umgewandelt in entsprechende Anforderungen, also in Tickets, am Ende des Tages in unseren Ticketsystem. Und ganz wichtig dabei: Diese Anforderungen können immer, hauptsächlich erstmal, aufgesplittet werden in zwei verschiedene Arten von Anforderungen. Auf der einen Seite die funktionale Anforderung und auf der anderen Seite die nicht-funktionale Anforderung. Und diese beiden Anforderungen unterscheiden sich schon mal sehr sehr stark voneinander. Weil einer der Hauptprobleme bei dieser bei diesen beiden Anforderungstypen ist es, dass wir mit den funktionalen Anforderungen ja ein ganz spezielles Unternehmensziel erreichen, was wir mit den nicht-funktionalen nicht erreichen können.

Wenn ich jetzt funktionale Anforderungen betrachte, geht es um das Was in der Softwareentwicklung, also: Was soll in meine Software reingebracht werden? Welche Funktionen sollen darin enthalten sein und so weiter und so fort. Und wenn wir es an ein Beispiel machen, ich nehme das Beispiel von einem Webshop. Wenn ich ein Webshop-Entwickler bin und mich ruft ein Kunde an und sagt: David, wir hätten gerne die und die Funktion, dann kann ich da mir das angucken, kann ein Angebot machen und kann sagen: Hier, keine Ahnung, die Funktion kostet dich 5000€. Dann bekomme ich den Auftrag, implementiere diese funktionale Anforderung, deploye das zum Kunden und kann entsprechende Rechnung stellen. Das heißt, mit einer funktionalen Anforderung kann ich immer direkt das monetäre Ergebnis im Unternehmen beeinflussen. Natürlich nicht immer, es gibt natürlich unterschiedliche Softwareentwicklungssituationen. Manche haben einen direkten Endkunden, an den sie Funktionen verkaufen können, manche machen das Ganze intern, aber am Ende ist der Gedanke und die Motivation dahinter gleich: Mit funktionalen Anforderungen können wir den Kunden zufriedenstellen und irgendeine Art und irgendeine Art von Vorteil generieren. Die nicht-funktionalen Anforderungen, die sind jetzt nicht für das Was zuständig, sondern bei den nicht-funktionalen Anforderungen geht es um das Wie. Also: Wie wird die Software implementiert? Also wie schnell, wie wartbar, wie weiterentwickelbar, wie skalierbar, wie benutzbar und all diese Wies, die man sich in diesem Zusammenhang stellen kann. Die nicht-funktionalen Anforderungen sind, so kann man das zusammenfassen, für die Qualität zuständig. Es ist in dieser Grafik nicht ganz richtig dargestellt. Die nicht-funktionalen Anforderungen kommen natürlich vom Product Owner, weil es nicht-funktionale Anforderungen gibt, die aus Kundensicht relevant sind. Der Kunde z.B. interessiert sich sehr für die Effizienz der Anwendung, für die Benutzbarkeit und für solche Aspekte. Aber es gibt natürlich auch Aspekte, die für uns als Unternehmen wichtig sind, z.B. dass die Anwendung gut analysierbar ist, dass der Entwickler sie leicht lesen kann, dass wir Dinge wiederverwenden können, dass wir sie einfach modifizieren können, dass wir sie einfach erweitern können etc. Und deswegen steuert auch der Architekt entsprechende nicht-funktionale Anforderungen in Form von Richtlinien in dieses Projekt bei. Und diese Voraussetzung, die wir jetzt hier geschaffen haben mit funktionalen, nicht-funktionalen Anforderungen und den Richtlinien, nennen wir mal eine, ja, eine ordentliche Voraussetzung für die Softwareentwicklung. Und die Frage ist jetzt: Was passiert, wenn wir diese ordentliche Voraussetzung nicht haben? Was sind die Konsequenzen, wenn wir uns jetzt zu stark auf die Funktion konzentrieren und den Rest eben nicht wirklich beachten?

Wie eben schon erwähnt, wir versuchen das Beispiel jetzt ein bisschen einfacher zu machen. Das heißt, wir wollen jetzt hier nicht in die Technik abschweifen, sondern wir versuchen das allgemein verständlich für auch andere Rollen in der Softwareentwicklung zu machen. Und wir visualisieren das Ganze mal so, dass wir eine Ebene haben, und dieser Entwickler befindet sich auf der Ebene, und der Entwickler bewegt sich jetzt von links nach rechts. Und je schneller er das tut, umso schneller sind wir auch im Projekt, das heißt, umso mehr Fortschritte machen wir, umso mehr funktionale Anforderungen können wir am Ende des Tages in die Anwendung einbauen. Aber dieser Softwareentwickler ist jetzt nicht allein auf weiter Flur. Er läuft zwar alleine von links nach rechts, aber er zieht einen Schlitten hinter sich her. So, dieser Schlitten, wie ich ihn jetzt mal angenommen habe, ist nichts, das heißt, er kann diesem Schlitten ganz entspannt lospazieren und kann entsprechend im Projekt ja Strecke machen. Und wenn dieser Entwickler jetzt mit diesem Schlitten läuft, dann mal angenommen, macht er im ersten Monat eine Strecke und entwickelt zehn verschiedene Funktionalitäten. Welche Funktionalitäten das sind, ist erstmal egal, aber diese Zehn ist jetzt für uns die Kenngröße für die Geschwindigkeit dieses Entwicklers. So, damit das Software-Entwickler jetzt in den Projekten arbeiten kann und zwar nachhaltig arbeiten kann, wobei nachhaltig bedeutet, dass er eine Anwendung entwickelt, die erweiterbar ist, wartbar ist, die eine gute Struktur hat, die analysierbar ist und so weiter und so fort, braucht er verschiedene Dinge. Natürlich braucht er in erster Linie funktionale Anforderungen, also muss wissen: Welche Funktionalität soll er jetzt in dieser Anwendung reinimplementieren? Aber natürlich soll er auch nicht-funktionale Anforderungen bekommen, also sagen wir, wie diese Funktionalität in die Anwendung implementiert werden soll. Einmal: Wie soll sie aus Kundensicht implementiert werden? Aber auch: Wie sollte diese Funktionalität für uns als Unternehmen implementiert werden? Weil wir wollen diese Funktionalität natürlich, weil wir dort Geld investiert haben, in irgendeiner Art und Weise sichern. Das heißt, sie soll zukunftsfähig implementiert sein, die soll erweiterbar sein, wartbar sein und so weiter. Darüber hinaus brauchen wir aber auch noch Wissen, weil es ist jetzt nicht so, dass jeder Softwareentwickler automatisch das Wissen mitbringt, um große Softwareanwendungen zu bauen, um Softwareanwendungen zu bauen, die wirklich lange erweiterbar, lange wartbar sind. Und am Ende des Tages wird das mehr oder weniger untergebrochen auf Architekturwissen. Und der Klassiker ist immer, wenn man jetzt aus der Ausbildung kommt, aus dem Studium kommt, dann hat man fast gar kein bis überhaupt kein Architekturwissen, weil es eben nicht Bestandteil der Standardausbildung auf Universitäten, Fachhochschulen und eben auch auf, ja, der Ausbildung ist. Und der vierte Faktor ist natürlich Zeit. Wir brauchen Zeit zur Implementierung. Wir brauchen Zeit, um die funktionalen Anforderungen zu implementieren. Wir brauchen Zeit, um nicht-funktionale Anforderungen zu implementieren. Und wir brauchen natürlich auch Zeit, um, ja, neues Wissen aufzubauen und uns in verschiedene Dinge einzuarbeiten. Bekommen wir diese vier Inputs, dann bezeichnen wir das Ganze, wie eben schon erwähnt, als ordentliche Voraussetzung. Das bedeutet, dass wir das Projekt, dass wir das Produkt weiterentwickeln können mit einer gleichbleibenden Geschwindigkeit, dass wir also für Erweiterbarkeit und Wartbarkeit sorgen. Das heißt, im nächsten Monat können wir wieder erneut zehn Funktionen implementieren, genauso wie im Monat davor. Aber ich hätte ja eben dieses Problem, das größte Problem in der Softwareentwicklung genannt, wenn das einfach so gemacht wäre mit diesen vier Inputs.

Die Realität ist, dass einfach da draußen die Unternehmen viel zu oft von diesen vier Inputs nur einen einzigen Input haben, und das ist selbstverständlich nur die Funktion. Die Konsequenz ist jetzt natürlich, dass der Softwareentwickler die Funktionalität nicht richtig implementiert, nicht so implementiert, wie man sie normalerweise implementieren sollte. Das heißt, normalerweise würde ich mehr, ja, Fokus auf die Qualität legen. Ich würde mir umfangreicheres Wissen aneignen, wie das Ganze implementiert werden muss, sodass ich das im Endeffekt langfristig warten und weiterentwickeln kann. Und oftmals wird auch Zeitdruck ausgeübt in solchen funktionsgetriebenen Softwareentwicklungen, und dann werden noch mehr Dinge eingespart. In irgendeiner Art und Weise Qualität in die Anwendung bringen können. Und wir müssen jetzt hier an der Stelle mal ganz klar sagen, das sehe ich auch immer wieder in Projekten, in Beratungsprojekten bei meinen Kunden: Wenn wir jetzt zu solchen Sachen wie nicht-funktionalen Anforderungen, Richtlinien und auch Zeitbudgets reden, das ist keine alleinige Schuld der Entwickler. Das heißt, die Entwickler sind nicht verpflichtet, sich diese Dinge immer wieder anzunehmen und sie immer wieder einzufordern, sondern sind im Endeffekt Inputs, die geliefert werden müssen von anderer Stelle. Das heißt, die funktionalen Anforderungen sicherlich vom Product Owner, aber auch die nicht-funktionalen Anforderungen müssen in großen Teilen vom Product Owner kommen, müssen vom Architekten kommen. Und da sind wir wieder beim Thema: Die Architektenrolle ist so so oft nicht besetzt, obwohl sie eigentlich das Wichtigste absichern, schützen soll, nämlich das Softwareprodukt, unser Investment, was für in der Softwareentwicklung getätigt haben. So, aber wir haben jetzt von diesen vier Dingen drei eingespart. Das heißt, wir haben keine Zeit vorgegeben, keine nicht-funktionalen Anforderungen und wir haben uns nicht um den Wissensbedarf gekümmert. Das bedeutet, dass die implementierte Lösung, die wir implementieren, nicht optimal ist und dass wir später noch mal Zeit investieren müssen in diese Implementierung, um alles so zu machen, wie wir es ursprünglich hätten machen müssen. So, und diese Zeit, die wir investieren müssen, die nennen wir technische Schulden, und die liegen jetzt gedanklich auf diesem Schlitten drauf und haben natürlich ein gewisses Gewicht, die der Entwickler ziehen muss. So, weil wir jetzt bei den vier Dingen drei weggelassen haben, ist der Schlitten schwerer und folglich schafft der Entwickler jetzt im nächsten Monat nicht mehr so viel Strecke, hat nicht mehr so ein hohes Tempo und schafft von diesen zehn Funktionalitäten leider nur noch neun. Jetzt müssen wir also den Entwickler irgendwie wieder schneller bekommen. Wie machen wir das? Na, wir müssen zusehen, dass wir Gewicht von diesem Schlitten runterbekommen, dass wir diese technischen Schulden in irgendeiner Art und Weise abbauen. Und dieser Vorgang in der Softwareentwicklung, dieser technischen Schulden abzubauen, nennen wir Refactoring. Refactoring bedeutet, dass wir unser Projekt nachbearbeiten, dass wir also die Dinge gerade ziehen, die wir in der Vergangenheit nicht richtig gemacht haben. Und das bedeutet auf der anderen Seite aber auch, dass wir in der Zeit keine neuen Funktionalitäten, ja, entwickeln, sondern wir verändern die Strukturen und die Implementierung von bereits existierenden Funktionalitäten. Das heißt, in dieser Zeit implementieren wir keine neuen Funktionalitäten. Nachdem wir das Refactoring jetzt gemacht haben, haben wir natürlich wieder die alte Geschwindigkeit, das heißt, wir haben alle Gewichte von diesem Schlitten runtergebracht und sehen jetzt zu, dass wir wieder mit der normalen Geschwindigkeit von zehn Funktionen pro Monat entwickeln können. Das bedeutet jetzt: Wir haben Zeit eingespart, indem wir quasi mehr Zeitdruck ausgeübt haben, keine nicht-funktionalen Anforderungen vorgegeben und uns nicht um Richtlinien gekümmert haben. Das ist die eine Sichtweise. Auf der anderen Seite haben diese technischen Schulden, und diese technischen Schulden jetzt abzubauen, dauert meistens wesentlich länger als der Betrag der technischen Schulden ist. Weil wenn ich jetzt so eine Funktionalität direkt eine Stunde später, z.B. implementiere oder behebe, dann ist es natürlich so: Ich kenne den Quellcode noch, die Anwendung noch, ich bin in der Funktionalität als Entwickler noch tief drin, dann kann ich es vielleicht in, ja, fünf Stunden oder ein bisschen mehr schaffen. Wenn ich aber nach Monaten oder manchmal sogar Jahren diese technischen Schulden wieder entfernen muss, dann muss ich mich natürlich wieder in die Anwendung reindenken, ich muss mich wieder in den Quellcode reinarbeiten, muss gucken, was da überhaupt passiert ist, und dann kann es sein, dass da ein Faktor vor steht, und dann kann es auch sein, dass es der zwei- oder dreifache tatsächliche Aufwand ist, den ich dann am Ende des Tages habe. Das heißt, aus fünf Stunden technischer Schuld werden dann am Ende 15 Stunden, 10 Stunden, je nachdem welchen Faktor man erhöht. So, jetzt ist aber das, was wir uns angeschaut haben, noch gar nicht wirklich das Hauptproblem. Weil mal eine gewisse Zeit lang technische Schulden aufbauen, dann wieder abbauen, das ist soweit eigentlich kein großes Problem. Ihr seht ja, unser Schlitten ist leer. Das eigentliche, tatsächliche Problem ist, dass viele Unternehmen gar nicht erkennen, wie Softwareentwicklung richtig funktioniert, sondern sie gehen hin und implementieren einfach eine Funktion nach der nächsten, was sie denken, dass Softwareentwicklung so funktioniert. Das heißt, wenn ich jetzt diese Implementierung über einen längeren Zeitraum rein auf Funktionen basiere, dann wird natürlich diese technische Schuld, diese Menge der Päckchen, die hinten auf dem Schlitten des Entwicklers liegen, Stück für Stück für Stück immer größer. Diese viele technische Schuld sorgt natürlich jetzt dafür, dass wir irgendwann in den Folgemonaten, wenn wir ja diese technischen Schulden aufgebaut haben, dann bricht unsere Entwicklungsgeschwindigkeit vollkommen ein, hier auf drei Funktionseinheiten, die wir nur noch rausbekommen. Und das ist jetzt ein ernsthaftes Problem, denn so ein Softwareentwickler ist eine knappe und teure Ressource im Moment. Und wenn wir in so eine Situation hineingeschlittert sind mit so einem großen Berg von technischer Schuld, dann lassen wir diesen Entwickler natürlich auch aus Effizienzgesichtspunkten gesehen sehr sehr wenig aus, denn wir bezahlen einen kompletten Entwickler und bekommen am Ende des Tages nur ein Drittel Entwickler. Die restliche Zeit muss er eben damit kämpfen, irgendwie um diese technischen Schulden herum die Funktionalitäten zu implementieren.

Jetzt könnte man natürlich Trick 17 machen und könnte sagen: Okay, wenn unser Entwickler oder unsere Entwickler nicht genug Geschwindigkeit haben, nur drei Funktionseinheiten schaffen, dann stellen wir einfach weitere Entwickler ein. Das klingt erstmal in der Theorie ganz gut, aber in der Praxis hilft uns das leider nicht wirklich weiter. Wenn wir jetzt bei unserer Analogie bleiben, dann ist das so, dass unser Entwickler oder unsere Bestandsentwickler über Jahre diesen schweren, riesengroßen Schlitten gezogen haben mit der vielen technischen Schuld hinten drauf, und die sind gewachsen und muskulös geworden, richtig stark, und der neue Entwickler, der reinkommt, der ist ziemlich klein und ist auch ziemlich schwach. So, das heißt, da ist für das Team am Anfang überhaupt gar keine Hilfe, da hilft diesem Team in keinster Weise weiter, sondern ganz im Gegenteil, weil man ihm helfen muss, ihn anlernen muss. Sitzt er mehr oder weniger hinten auf diesem Schlitten drauf und belastet das Team noch zusätzlich, weil der Schlitten jetzt noch schwerer ist. Das heißt, in der Folgezeit wird die Geschwindigkeit noch weiter absinken. In der Praxis sieht das Ganze dann so aus, dass solche neuen Entwickler natürlich in der Domäne angelernt werden müssen, also sie verstehen, was der fachliche Kontext ist der Anwendung, aber sie müssen natürlich auch die Anwendung verstehen, damit sie wissen, wo sie Erweiterungen und Wartung machen können. Wenn diese Anwendung unglaublich komplex ist durch diese ganze technischen Schulden, dauert das mitunter sehr sehr lange. Ich habe in Projekten, die ich schon beraten habe, habe ich Einarbeitungszeiten von mehreren Monaten bis zu mehreren Jahren gesehen, und erst dann kann man wirklich so einen neuen Entwickler als wirkliche Verstärkung zählen. Deswegen: In der Theorie, ja, kann man das machen, man gewinnt über zwei, drei Jahre gesehen vielleicht, ja, irgendwie Entwicklungsgeschwindigkeit dazu, aber am Anfang ist es eher kontraproduktiv, und die Entwicklungsleistung geht noch mal ein Stückchen runter. Wenn jetzt trotz des Gemeckers der Entwickler und der Entwicklungsabteilung immer weiter gemacht wird und immer weiter die Funktionen in die Anwendung reingedrückt werden, dann kommen wir irgendwann an die Situation, dass wir einen kompletten Stillstand in der Softwareentwicklung haben. Das heißt, wir haben überhaupt keine Möglichkeit mehr, Erweiterungen oder Wartung an dieser Anwendung zu machen. Und wir müssen an der Stelle wieder ganz ganz deutlich sagen: Wenn wir eine zu stark funktionsgetriebene Softwareentwicklung haben, haben wir diese Situation hier definitiv irgendwann. Es ist hier nicht die Frage, ob wir so etwas bekommen, sondern immer nur die Frage, wann. So funktioniert Softwareentwicklung einfach nicht. Man bekommt ein Produkt raus, man kann es eine Zeit lang entwickeln, aber auf lange Sicht gesehen funktioniert es nicht. Ich habe schon sehr sehr viele Projekte gesehen, ich habe viele Projekte analysiert, und ich kann euch mit absoluter Sicherheit sagen: Wenn ihr auf die Art und Weise Software entwickelt, dann werdet ihr irgendwann in genau diese Falle reintreten und werdet irgendwann vor einem großen, nicht mehr erweiterbaren, nicht mehr wartbaren, monolithischen Riesen-Softwareklops stehen, und nichts geht mehr in die Anwendung rein. Wenn es dann im Unternehmen zu dieser Situation kommt und die Erkenntnis bei den Leuten, auch bei den Entscheidern, irgendwann reift: Oh, wir haben da ein ernsthaftes Problem, lass uns das Problem ein bisschen anschauen, dann wird das Problem in seiner kompletten Größe ersichtlich. Denn das Problem, oder das Problem, was wir geschildert haben, sieht hoffentlich so aus, dass es jeder nachvollziehen kann, dass es auch jemand Nicht-Entwickler verstehen kann, aber es verharmlost die ganze Situation natürlich, weil unser Softwareentwickler, der vorne diesen Schlitten zieht, der ist natürlich in einem viel viel größeren Kontext unterwegs. Und dieser Softwareentwickler, der zieht nicht nur so einen kleinen Stapel technische Schuld hinter sich her, wie wir es gerade gesehen haben, sondern in den meisten Projekten, die über viele Jahre, viele Jahrzehnte gehen, sieht dieser Berg der technischen Schulden wirklich gigantisch aus. Und trotzdem versucht jetzt der Entwickler hier unten irgendwie im Projekt nach vorne zu kommen, das Ganze irgendwie nach vorne zu treiben, trotz dieser Riesenlast, die da auf seinem Schlitten liegt, versucht irgendwie noch das letzte bisschen Geschwindigkeit zu nutzen, um neue Funktionalitäten zu implementieren. Aber trotzdem, dass es eh schon schwierig ist in der Entwicklung, man gar nicht mehr weiß, wo man anfangen soll und wie irgendwas funktioniert, gibt es immer noch das Management, die dann irgendwo noch weiter Zeitdruck aufbauen oder sich beschweren, dass die Kosten zu hoch sind, dass wir nicht genug Features implementieren, dass da der Meilenstein ansteht, dass Kunde XY unzufrieden ist und so weiter. Von diesen Projekten hier habe ich schon in meiner Karriere, in meiner Laufbahn als Berater, eine ganze ganze ganze Menge gesehen. Ich habe Projekte gesehen, bei denen die Menge der technischen Schulden die dreifache Teamkapazität hatte. Das heißt, wenn wir ein Team von fünf Leuten hatten, dann hatten wir eine technische Schuld nachher von 15 Mannjahren in diesem Projekt. Das heißt, wir mit der gesamten Mannschaft hätten wir drei Jahre gebraucht, um das Ganze abzuarbeiten. Es gibt natürlich auch manchmal Projekte, wo weniger technische Schuld ist, aber oftmals, wenn man das über mehrere Jahre, Jahrzehnte macht, dann hat man einfach unfassbar hohe Summen oder hohe Beträge auf diesem technischen Schuldenhaufen, die meistens sehr weit in die Millionen reingehen. Der höchste Wert, den ich bis jetzt hatte, war im weit hohen zweistelligen Millionenbereich. Und das waren alles Probleme, die man hätte verhindern können.

Und das Resultat in so einer Situation, was man dann machen kann, ist natürlich entweder ein Refactoring machen, also diesen riesigen Schuldenberg, der über mehrere Jahre, Jahrzehnte angewachsen ist, dann auch dementsprechend lange abtragen. Das heißt, da haben wir dann solche Refactoring-Projekte, die eben Monate, Jahre gehen, oder wir machen ein komplettes Rewrite, implementieren also diese Anwendung komplett neu. Oder wenn diese Rewrites oder Refactorings die finanziellen Möglichkeiten des Unternehmens übersteigen, dann sieht es ganz ganz schlecht aus. Ich habe in meiner Karriere leider schon einige Unternehmen erleben müssen, die Insolvenz anmelden mussten, weil sie gewisse Moves mit der Anwendung machen mussten, die sie dann aber nicht mehr machen konnten, weil schlichtweg das Geld gefehlt hat. Und das Interessante ist immer: Obwohl die Softwareentwickler jahrelang schreien und sich immer wieder beschweren und sagen: Das geht so nicht, werden sie oftmals nicht gehört, es wird ignoriert, und alle denken: Es ist super, wir sind am Markt erfolgreich, wir haben Kunden, keine Ahnung, wir machen, wir schreiben positive Zahlen. Und dann kommt die große Katastrophe, und dann sind irgendwie alle immer überrascht. Und da würde mich jetzt mal interessieren – wir haben viele Softwareentwickler, die diese Videos schauen – schreibt immer bitte in die Kommentare rein, ob euer Management den tatsächlichen Zustand eurer Anwendung kennt, ob sie danach schon mal gefragt hat, und eure Einschätzung, ob euer Management, eure Geschäftsführung, Vorstand sich der Konsequenzen klar ist, dass wenn ihr so ein Problem hättet, wissen die tatsächlich, was das für das Unternehmen, für das Produkt bedeuten kann, dass für unter das ganze Projekt irgendwann mal neu entwickelt werden muss. Wo wir gerade dabei sind, noch ein ganz kleines Beispiel: Ich habe mal einen Kunden gehabt, der war Marktführer mit seinem Produkt. Das heißt, der hatte, viele Jahre, Jahrzehnte war er Marktführer in einem ganz speziellen Segment, und der hat auch quasi nicht Geld gemacht ohne Ende, aber die haben schon verdammt gute Umsatzzahlen gehabt. Und sie haben eine neue Chance gehabt, in die Cloud zu gehen mit einem neuen Produkt. Und in dem Zusammenhang haben wir uns die Anwendung angeschaut, wollten schauen, wie wir das in die Cloud bringen können. Und die Entwickler haben schon seit Jahren, ja, sich immer wieder beschwert und gesagt: Das geht nicht mehr, wir kriegen keine Funktionalitäten mehr rein, sind Unmengen von Seiteneffekten, Fehlern in die Anwendung gebaut. Also sie haben einen Bug gefixt, und dann taucht er neu auf. Und als sie dann genauer reingeschaut haben, da war dieses Produkt eigentlich schon unwartbar. Und die einzige Konsequenz, die es dann gab, war eben dieses Produkt komplett neu zu entwickeln. Und das wird jetzt seit fast sechs Jahren gemacht und ist noch lange nicht fertig. Und in der Zeit konnten wir noch keinen einzigen Euro damit verdienen, sondern ganz im Gegenteil, natürlich nur viel Geld investieren. Deswegen: Wenn das bei euch so ist, wenn eines von diesen Anzeichen irgendeiner Art und Weise auf euch zutrifft, versucht sofort zu handeln. Und vor allen Dingen stellt euch darauf ein, dass das Problem, was ihr dann entdeckt, wenn man das mal alles zusammenrechnet, was dann technische Schulden ist, das ist verdammt groß, und niemand im Unternehmen wird es gefallen.

Wie umgehen wir die Katastrophe jetzt? Na, wir haben es eigentlich eben schon gezeigt: Also wir müssen zusehen, dass wir den Entwicklern natürlich funktionale Anforderungen geben, selbstverständlich. Wir haben eben gesehen: Funktionale Anforderungen sorgen für Umsatz, und wir brauchen Umsatz, wir müssen die Leute bezahlen. Aber man sollte es deckeln. In den Teams, die ich betreue, z.B. sagen wir immer: Maximal 80% der Anforderungen sollten funktional sein, die in so eine Entwicklung reingegeben werden, weil wir müssen Umsatz generieren, aber wir sollten es auch nicht zu sehr übertreiben, weil wir brauchen mindestens 20% der nicht-funktionalen Anforderungen, die also versuchen, die Qualität zu regeln. Und diese nicht-funktionalen Anforderungen, wie gesagt, sollten vom Product Owner aufgenommen werden und vom Architekten entsprechend durch Richtlinien, Architekturrichtlinien und Entwicklungsrichtlinien vorgegeben werden. Aber wir brauchen natürlich auch Wissen, weil diese ganzen Qualitätsattribute, die wir jetzt immer, wo wir drum herumgeredet haben – Wiederverwendbarkeit, Erweiterbarkeit, Wartbarkeit etc. – das sind alles Qualitätsattribute aus dem Bereich Architektur. Das heißt, die Architektur stellt die langfristige Weiterentwickelbarkeit und Wartbarkeit einer Anwendung sicher. Und damit das Ganze funktioniert, müssen die Entwickler natürlich auch entsprechendes Wissen haben, um das Ganze zu implementieren. Und da, z.B. im Wissensbereich, fange ich bei meinen Kunden als erstes immer an, Wissen aufzubauen im Bereich Softwarearchitektur und im Bereich Softwaredesign, weil damit kann man schon mal die größte Kuh vom Eis holen, was genau diese Problematik angeht. Aber natürlich müssen wir auch zusehen, dass wir genug Zeit einräumen, sowohl für die funktionalen Anforderungen als auch für natürlich die nicht-funktionalen Anforderungen, weil die Kosten Zeit in der Umsetzung und natürlich auch für das Lernen von und die Aneignung von neuen Dingen innerhalb der Softwareentwicklung. Liebe POs, liebes Management, liebe Unternehmensleitung, ich verstehe vollkommen, warum das passiert. Die Unternehmensleitung will wachsen, die möchte die laufenden Kosten decken und vielleicht am Ende ein bisschen Gewinn machen. Der Vertrieb will mit mehr Kunden und mehr Funktionen, mehr Umsatz machen. Das Marketing möchte mehr Funktionen, um mehr Kundengruppen anzusprechen. Und das Produktmanagement möchte ein mit Funktionen gespicktes Produkt haben, was am Markt mithalten kann und wenn nicht sogar das beste Produkt am Markt werden kann. Aber all diese Ziele, all diese Unternehmensziele, die mit Sicherheit notwendig sind und die auch gut sind, die dürfen nicht auf Kosten von eurem Softwareprodukt gehen. Jahrelang massenweise funktionale Anforderungen, also Funktionen in die Anwendung einzubauen, das arbeitet zwar auf all diese Ziele hin, die ich gerade angesprochen habe, aber so funktioniert Softwareentwicklung am Ende des Tages nun mal einfach nicht. Ihr habt hunderttausende oder Millionen von Euro oder Dollars in diese Softwareanwendung reingesteckt als Unternehmen, und ihr fahrt dieses Produkt gerade mit voller Wucht gegen die Wand. Wenn es dann einmal vor dieser Wand hängt, müsst ihr unglaublich hohe Summen investieren, um das Produkt zu restrukturieren oder komplett neu zu entwickeln. Und in dieser Zeit, wo es restrukturiert und neu entwickelt wird, kommen keine neuen Funktionen in die Software rein. Das heißt, es wird mit diesen neuen Funktionen kein Umsatz gemacht. Das heißt, alle diese Interessensgruppen, die ich gerade aufgezählt habe, können dann ihre Ziele gar nicht mehr erfüllen. Das heißt, das Produkt fällt am Markt zurück, es wird weniger attraktiv für Kunden, ihr verliert vielleicht sogar Kunden, und am Ende wird es dann mit dem Unternehmenswachstum auch schwierig. Funktions-eben-Softwareentwicklung ist ein riesengroßer Fehler, den sicherlich niemand absichtlich macht. Wie schon erwähnt, ich bin der Meinung, dass dann oftmals nicht genug allgemeine Software…

Entwicklungswisen im Unternehmen außerhalb der Software-Entwicklungsabteilung existiert. Aber irgendwann werdet ihr einen verdammt hohen Preis dafür bezahlen müssen.

Solltet ihr den Fehler jetzt in eurem Unternehmen entdeckt haben, dann solltet ihr den nächsten großen Folgefehler nicht auch noch machen, weil der macht das Problem um ein Vielfaches schlimmer. Was das ist, das erkläre ich dir in diesem Video.

Ich wünsche euch jetzt einen schönen Tag, viel Spaß bei der Arbeit, bis zum nächsten Video und ciao.