Diese Änderungen, in denen wir im letzten Block gesprochen haben, haben Auswirkungen.
Und diese Auswirkungen haben sie vor allen Dingen dahin,
dass es zu einer Verschlechterung der Software kommt,
vor allen Dingen zu einer Verschlechterung der Struktur.
Und diese Verschlechterung der Struktur gefährdet das, was wir von
geschäftskritischen Systemen erwarten. Das ist überhaupt die Notwendigkeit von Re-Engineering
. Deshalb schauen wir uns das ein bisschen genauer an.
Das sind die Punkte, die hinter dem hinter diesen Änderungen
letztlich stecken
Ja, also diese Änderungen, über die
wir gesprochen haben, haben Auswirkungen auf Wartbarkeit. Wartbarkeit,
das wissen Sie hoffentlich noch, von ungefähr zwei Vorlesungen vorher,
Wartbarkeit, das war diese Qualitätseigenschaft, die ausdrückt,
wie viel Aufwand ist notwendig,
um Veränderungen,
um Wartung durchzuführen
Veränderungen sind ja das, was wir brauchen,
um geschäftskritisches Thema ein Leben zu erhalten.
Deswegen Wattbarkeitsverschlechterung wäre jetzt schlecht für uns.
Ausgangsbasis ist das, was wir geschäftskritische Systeme gesagt haben.
Systeme sind häufig komplex. Da müssen wir einfach sagen,
das ist ein häufig beklagter Missstand,
aber wir müssen einfach nur sagen,
so ist es,
Dokumentation häufig mangelhaft
Wir können zwar sagen, ja, die Forschung arbeitet daran,
dass das sich irgendwann mal verbessert,
aber zurzeit haben wir noch kein wirklich gängiges Modell.
Es ist nach wie vor so,
dass die Dokumentation an sich keinen Wert hat,
sondern mehr so die Laufwege Kot hat den Wert.
Und das ist natürlich ganz klar, was die Priorität hat.
Da es beides als Ausgangsbasis dann finden häufige Änderungen statt
Und die sind, finden unter Zeitdruck statt. Warum mit der Zeitdruck? Ja,
es gibt viel zu wenig Entwickler,
die wirklich an diesem System noch arbeiten,
weil es zu wenig Bezahlung dafür gibt,
während der Erwartungsphase bei einer Neuentwicklung ist es noch was anderes,
aber für die Wartungsphase muss man schon sehen,
wen hat man da noch in der Wartungsvertrag,
wer zahlt dafür, wie viel kann ich dafür im Übrigen entsprechen,
wie viele Leute kann ich bezahlen und außerdem Zeitdruck auch daher,
dass die Anwenderin sich dann ausgedacht haben,
wie ein neues Versicherungsprodukt funktionieren soll oder die Lux,
die in ihrer Kleiderfabrik dann wollen sie das möglichst ganz schnell umgesetzt haben.
Ja, und dadurch kommt der Zeitdruck. So,
diese Sachen, die wir hier haben,
sind schon eigentlich eine ziemlich tödliche Mischung, oder?
Vielleicht nicht gleich tödlich, aber auf jeden Fall schwierig.
Hinzu kommt aber noch, dass Systeme dadurch,
dass sie ja von anderen gebaut sind,
schon eine längere Geschichte haben,
vielleicht auch nicht ideal sind,
dass die Softwareentwicklersysteme häufig
nicht komplett verstehen
Man könnte auch sagen, sie verstehen sie selten komplett,
wenn sie das lieber formuliert haben wollen. Ja,
und hinzu kommt noch, das müssen wir einfach auch noch
zur Kenntnis nehmen, das ist so, Menschen machen Fehler.
Haben Sie vielleicht von mir schon gehört,
dass man sagt, 3 Prozent Fehler ist ganz normal,
wenn die Leute sich ganz viel Mühe geben,
ganz super motiviert und qualifiziert sind,
schaffen sie es vielleicht mit nur 1 Prozent Fehler.
Aber bei 10.000 Lions of Code sind das eben
auch 100 oder 300 Fehler. Das ist,
und wegen der Bedeutung müssen wir noch sagen, dass wir,
dass die Leute sich des Risikos,
den Software,
also Nichtverfügbarkeit von Software hätte,
sehr vorsichtig sind
Risikobewusstsein soll das heißen Vorsicht und Sicherheitsbedürfnis
Der Entwickler führt dazu, dass man eigentlich eine Struktur
möglichst nichts ändert
Strukturanpassungen unterbleiben. Das ist ein Punkt,
den wir einfach nur zur Kenntnis nehmen. So,
wenn wir uns jetzt das mal alles anschauen,
die Systeme sind komplex, sie sind schlecht dokumentiert,
dadurch sind sie schon sowieso schlecht verständlich.
Das sind die ersten beiden Punkte hier. Die Leute sollen
Änderungen machen, verstehen aber das System nicht ganz.
Und es ist auch schlecht verständlich. Menschen machen sowieso Fehler,
das bedeutet, es entstehen neue Fehler.
Und Man repariert wenig, wegen diesem Never Changer Running System.
Das führt dazu, dass die Struktur, dass Fehler weiter zunehmen.
Ich schreibe das manchmal hier so in eine Klammer auf
volle,
volle Rhein
Also es kommen zu alten Fehlern, neue Fehler hinzu.
Das führt dazu, dass die Verständlichkeit weiter schlechter wird,
Strukturänderungen da bleiben.
Deswegen wird die Struktur schlechter. Wohl beides zusammenführt dazu,
das soll ein Fall sein, machen wir mal neu.
Das führt dazu,
dass wir zunehmend die Verständlichkeit sich zunehmend verschlechtert
Ich komme gleich zu noch einem speziellen Begriff dazu,
aber erstmal müssen wir das so einfach zur Kenntnis nehmen,
dass das der Fall ist.
Und das führt dazu, dass zunehmend mehr Fehler gemacht werden.
Ja, auch das ist ein Punkt,
wir hatten es ja hier schon geschrieben,
das müssen wir einfach so sehen.
Und hier möchte ich mal ein bisschen vorgreifen,
das,
was wir
unterlassene Reparaturen machen
Das ist ein weiterer kritischer Punkt. Also wir können,
wir machen zwar hier, wir machen zwar gelegentlich solche Strukturänderungen,
aber ganz vieles bleibt einfach liegen und da bleibt,
weil man schnell fertig werden muss,
weil man jetzt gerade keine Zeit hat.
Solche Fehler passieren und das sind die Sachen,
die der Struktur schlecht bleiben.
Das bezeichnet man als technische Schulden. Dieser Begriff technische Schulden,
den ich Ihnen erklären möchte, nein,
wir wollen das nur noch ein neues Blatt machen.
Seid nur ein Fügen
Querformat. Jetzt technisch schön. Schulden. Technical Debt.
Technische Schulden ist ein total guter Begriff,
weil er uns ermöglicht, mit über Softwarequalität, über Refactoring,
mit unseren Auftraggebern zu sprechen.
Das ist ein
ganz wichtiger Punkt
Weil wir davon ausgehen müssen, dass die Auftraggeber,
dass die Chefs, die Firmeninhaber häufig nur keins oder ein
sehr ungelügendes Verständnis von Softwarequalität haben. Es gelingt ihnen,
es wird ihnen als Projektleiter nicht gelingen oder nur ganz schwer gelingen,
die Auftraggeber davon zu überzeugen, dass sie etwas im Software-Reengineering investieren,
dass sie etwas für die Zukunft tun.
Ich habe das also in meiner Zeit als Projektleiter versucht,
wir haben darum gekämpft, ein System zu erneuern.
Man hat da einen Prototypen, einfach nur in Produktion genommen.
Sie wissen vielleicht, es gibt zwei Regeln für Prototypen.
Erstens baue einen Prototypen, weil er einfach will,
wichtig ist und zweitens schmeiße den Prototypen weg und baue es dann richtig.
Und die Riegel 2 hat man hier verletzt.
Das war bevor ich in das Projekt kam. Und dann
war immer das Versprechen, ja, wir bauen einen,
wir machen eine Renovierung, hieß das damals bei uns.
Die Mikrofon-Engineering kannten wir nicht, sondern wir machen eine Renovierung.
Und diese Renovierung unterblieb im Konsolidierung. Die machte man
nicht. Und das ist einer der kritischen Punkte,
der dazu führt, dass man diese Strukturverschlechterung,
von denen wir gerade besprochen haben,
sehr viel stärker macht
Okay, wir sprechen jetzt über technische Schulden.
Technische Schulden sind keine Fehler. Ja,
ich fange mal damit an, was es nicht ist.
Hups, wissen wir jetzt? Es sind keine Fehler.
Das ist ein ganz wichtiger Punkt. Fehler sind was anderes,
das muss ich reparieren. Das ist ein Problemticket, ja,
das ist nicht. Sondern technische Schulden sind unterbliebene Anpassungen,
die eigentlich gemacht werden müssten
Vielleicht ist sie noch präsent von SE2,
dass wir dort über Entwurfsprinzipien guten Entwurf gesprochen haben,
zum Beispiel, dass man nach Zuständigkeiten fliedert.
Eine Klasse sollte genau für einen Zweck zuständig sein oder eine Komponente oder ein Paket. Ja,
und wenn es nach und nach dazu kommt,
dass man da Sachen reinpackt aus dem Notfall oder wie auch immer,
weil es schnell gehen muss,
dann packt Sachen rein,
die da nicht reingehören,
dann ist die Struktur schlecht an dieser Stelle
Müsste es eigentlich woanders hinpacken. Ja, das sind Beispiele
für diese Strukturanpassung, vernichtet, denen ich gerade spreche.
Außerdem könnte man noch nennen, dass es häufig sowas gibt
wie Notlösungen unter Zeitdruck. Diese Notlösung und der Zeitdruck sind Sachen,
die wir machen, damit es schnell läuft,
damit der Kunde schnell eine neue Version bekommt,
ohne jetzt gleich zum Beispiel einen übervollen Dialog aufzusplitten in zwei.
Eine übergroße Datenbanktabelle aufzusplitten in zwei
Ja, all diese Sachen, oder dass wir festgestellt haben,
wir müssen hier was vereinheitlichen, dort wird das so gemacht,
ob wir das so gemacht haben in der Software,
wir müssen da mal versuchen, die Konzepte klarzuziehen.
Das sind alle Sachen,
die nach und nach auftreten und die dazu führen,
dass wir diese, dass wir solche Strukturanpassungen eben nicht machen.
Technische Schulden führen dazu oder das Ganze führt dazu,
dass die Wartbarkeit schlechter ist
Verschlechtert sich. Und das heißt, Hörer, Aufwand,
bei Änderungen. Und höre auf, weil Veränderungen ist dann
am Ende etwas, wir müssen mehr bezahlen.
Und hier schließt sich der Kreis. Diese Schulden,
die wir jetzt aufgenommen haben,
weil wir mal schnell eben irgendwas ohne Strukturanpassungen gemacht haben,
weil wir was unter Zeitdruck mit einer Notlösung versehen haben und das rausgeben.
All diese Strukturanpassungen und die unterbliebene Struktureinpassung müssen wir
irgendwann schmerzlich bezahlen
Dieses schmerzliche Bezahlen ist,
in dem wir bei Änderungen einen höheren Zeitaufwand brauchen.
Das ist das, was uns am Ende wirklich schmerzt.
Das müssen wir einfach sehen und das wäre ein Punkt,
wo wir uns gleich im nächsten Thema
damit beschäftigen würden