Hilfe für “insolvente” Softwareprojekte

You can read an english version of this idea in the july issue of the PragPub Magazine.


Bei den privaten Fernsehsendern sind Formate, bei denen ein erfahrener Koch, Restaurants oder der ehrenamtliche Schuldenberater aus Berlin, Familien vor dem Untergang rettet der Hit. Ich denke, dass viele Softwareprojekte auch so einen “Schuldenberater” gebrauchen könnten.

Nun haben Softwareprojekte nicht direkt was mit Schulden zu tun aber schon Anfang der 90er hat Ward Cunningham einen Bezug zwischen techn. Komplexität und Schulden hergestellt. Der Begriff technische Schulden wird heute, auch immer wieder im Zusammenhang mit Refactorings benutzt.

Setzen wir doch nun mal die Features welche in dem Projekt umgesetzt werden mit den Dingen gleich, welche für Geld zu kaufen sind. Und sehen als Preis für ein Feature die Zeit an, die benötigt wird um ein Feature umzusetzen. Wie kommen wir dann zu den Schulden?



Die Personen im TV haben oft in jungen Jahren über Ihre Verhältnisse gelebt und konnten den tollen Angeboten “Heute kaufen, morgen zahlen” schlecht widerstehen. Meist ging das gut, bis ein “Unglück” geschah oder sie anders die Kontrolle verloren haben.

Und bei Softwareprojekten, ist es da anders? – Na schauen wir mal: Am Anfang steht das tolle Projekt vor der Tür und die CodeBasis ist = null. Also wird ein Team zusammengewürfelt aus mehr oder weniger erfahrenen Entwicklern. (Die unerfahrenen sind meist günstiger also auch oft in der Mehrheit.) Mit guten Vorsätzen und Anfangsanforderungen, Architektur und Design wird losgelegt. An der ein oder anderen Stelle wird nun bewusst eine Abkürzungen genommen, das Design vereinfacht oder eine Infrastrukturbetrachtung vertragt um ein Feature schneller zu bekommen. Das sind die ersten technischen Schulden. Zeit ist Geld und in Festpreisprojekten sowieso.

Die Schulden sind in beiden Fällen erst mal nichts schlimmes. Problematisch wird es erst, wenn man den Überblick verliert und zu viele Schulden aufnimmt. Irgendwann übersteigen die Ausgaben für das tägliche Leben und die Rückzahlungen der Schulden die Einnahmen. Bei Softwareprojekten heißt dies, es dauert immer länger ein neues Feature umzusetzen, bis dies unmöglich wird.

Ist es erst mal so weit gekommen, werden oft die Augen verschlossen und es wird nur noch schlimmer.

Bei den finanziellen Schulden gibt es die (Privat-)Insolvenz als letzten Ausweg um aus dem Teufelskreis raus zu kommen.

In den TV Folgen, kommt der Profi meist kurz vor der Insolvenz zu den Leuten, um ihnen dabei zu helfen, die Insolvenz zu vermeiden und ihre Schulden und anderen Probleme in den Griff zu bekommen. Denn oft sind die Schulden nur ein Teil des Problems.

Er beginnt immer damit, sich einen Überblick zu verschaffen. Dabei müssen die relevanten Dokumente oft aus allen Ecken zusammengesucht oder anders wieder besorgt werden. Denn die “Kunden” haben längst den Überblick verloren. Um die Schulden in den Griff zu bekommen, hilft der Schuldenberater ihnen nicht nur dabei einen Überblick über ihre Finanzen zu bekommen sondern auch ihr Leben neu zu regeln und die allgemeinen Probleme in den Griff zu bekommen. Selbst wenn er die Insolvenz nicht vermeiden kann ist dies essentiell, denn was bringt es die Schulden auf 0 zu setzen wenn der Kreislauf danach von vorn beginnt?

Warum gibt es so jemanden nicht für Softwareprojekte? Hier gibt es ja auch so was wie die Insolvenz: “Wir fangen von Vorne an und entwickeln für die nächste Version alles neu.”

Dieser “Schuldenberater für Softwareprojekte” verschafft sich einen Überblick über das Projekt, macht eine Aufstellung, welche Probleme am dringendsten behoben werden müssen und prüft ob das Projekt mit vertretbaren Aufwand gerettet werden.

Aber was viel wichtiger ist, dieser Schuldenberater hilft dabei Ordnung in das Chaos zu bringen. Er hilft dabei einen sauberen Prozess aufzusetzen und aus den Entwicklern ein Team mit Verantwortung für das Projekt zu formen. Er zeigt ihnen wie man mit Legacy Code umgeht, ein Sicherheitsnetz aus Tests baut und man aus den schlechten Gewohnheiten des zusammenhackens von Code raus kommt. Er begeistert die Leute für qualitative Arbeit.

Kurz: Er sorgt dafür, dass das nächste Projekt (oder das aktuell gerettete) nicht wieder vor der “Insolvenz” steht.

Ich übertreibe? Nun wenn man solche Sätze als Normal ansieht: “Alle drei Jahre eine Neuimplementierung ist normal” oder “Der Kunde denkt auch dass eine Neuentwicklung mal wieder angebracht ist und bezahlt diese auch”.  Und 10 Milliarden Euro Verlust im Jahr durch schlechte Software (nach einer aktuellen Studie) für wenig hält, dann übertreibe ich.

Und wenn ich nicht übertreibe, wo findet man nun so einen Schuldenberater für sein Softwareprojekt? Nun ich kenne noch keinen, der sich das auf die Fahne geschrieben hat, aber Hilfe bekommt man bestimmt von einem Software Craftsman – und den findet man in der Softwerkskammer.