In einem Kommentar zum Interview über CCD, das heise Developer mit mir gemacht hat, heißt es, dass Kunden doch sowieso keinen Sinn für schlechte Softwarequalität hätten. Gemeint ist natürlich nicht die äußere Qualität, die unmittelbar ihren Anforderungen entsprechen soll. Kunden haben selbstverständlich kein Verständnis, wenn Funktionalität fehlt oder die Software zu langsam ist. Da sind sie ganz sensibel. Gemeint ist also ein mangelnder Sinn für die innere Qualität von Software, um die es bei Clean Code Developer geht.
Das hört sich plausibel an. Ihnen ist diese innere Qualität egal, deshalb wird soviel schlechte innere Qualität produziert und akzeptiert. Ist das aber wirklich so? Ist den Kunden die innere Qualität wirklich egal?
Nein, das glaube ich nicht. Sie ist ihnen natürlich nicht egal. Ihnen mag egal sein, was Entwickler bei der Produktion schlechter Qualität empfinden, ob denen das egal ist oder sie sich ständig dabei unwohl fühlen. Aber schlechte innere Qualität ist ihnen nicht egal. Warum ist die Qualität dann so schlecht, wenn es den Kunden doch nicht egal ist und vielen (oder gar den meisten?) Entwicklern auch nicht? Ich glaube, dafür gibt es zwei Gründe:
- Missverständnis: Die Kunden leiden unter einem Missverständnis. Sie glauben, die innere Qualität sei hoch. So wie die innere Qualität von Autos oder Butter hoch ist.
- Blindheit: Weil die Kunden glauben, die innere Qualität sei hoch, vertrauen sie der Softwareentwicklung, wenn die ihnen sagt, wie teuer etwas sein wird und wie lange es dauert. Schlicht aus Basarmentalität heraus feilschen sie dann selbstverständlich – jeder weiß ja, dass es immer noch ein wenig schneller und preiswerter geht, als ein Anbieter behauptet –, doch letztlich akzeptieren die Kunden die Behauptungen und Versicherungen der Softwareentwicklung. Und weil sie das tun – womöglich auch aus einem Gefühl der Inkompetenz heraus –, schauen sie nicht genauer hin. Sie haben keinen eigenen Anspruch an die innere Qualität und damit keinen Maßstab und keine Messinstrumente für die innere Qualität. Auf dem Auge “Innere Softwarequalität” sind sie sozusagen blind. (Die üblichen Controller sind da übrigens kein korrektiv, weil sie selbst auch keine Wahrnehmung, keinen Anspruch an innere Qualität haben und ihr Horizont eher eng ist.)
Das bedeutet, Kunden akzeptieren aus einem Missverständnis heraus und aufgrund einer Unfähigkeit, das Gegenteil behaupten zu können, die schlechte Qualität von Software. Aber nicht, weil sie ihnen egal ist.
Wenn nun jemand daher kommt und den Kunden klarmacht, dass 1. die innere Qualität von Software schlecht ist, sie also einem Missverständnis aufsitzen, und 2. diese schlechte Qualität sie viel Geld kostet, dass hier also einiges an Einsparpotenzial in den IT-Ausgaben schlummert, dann… ja, dann muss sich die Softwareentwicklung warm anziehen. Denn dann werden die Kunden ganz deutlich ihren Qualitätsanspruch formulieren. Wohl dem also, der dann schon die Kompetenz hat, ihre neuen Ansprüche auch zu erfüllen.
Oder kommt dann alles anders? Winken die Kunden dann ab und gähnen, weil sie das doch schon alles wissen? “Klar, wir wissen, die innere Qualität ist schlecht und wir hauen riesige Summen für Änderungen an verquarzter Software raus – aber es ist uns egal. Wir tun das ganz bewusst, weil wir schneller Ergebnisse jetzt sofort sehen wollen, statt später mit höherer innerer Qualität.” Könnte es sein, dass Kunden diese Antwort geben? Vielleicht der eine oder andere. Im Großen und Ganzen bezweifle ich es jedoch.
Es bleibt also dabei: Wenn die Kunden anfangen, sich den Sand des Missverständnisses aus den Augen zu wischen und ihre Blindheit überkommen, dann wird es wirklich spannend in der Softwarebranche.
15 Kommentare:
Die Kunden sollen auch die Details über innere Software Qualität nicht wissen müssen. Sie brauchen irgendwelche Metapher oder Metric dafür, da sie mindestens ein Überblick über den Zustand der inneren Qualität haben können.
Technical Debt finde ich dafür ganz gut. Das vergleicht diese innere Qualität mit finanziellen Schulden, etwas das Kunden sehr gut verstehen können.
Das muss aber auch den Kunden als konkrete Zahlen übermittelt werden, idealerweise in den gleichen Einheiten die Aufwand (für neuen Anforderungen und Bug-Fixing usw.) normalerweise geschätzt wird, wie z.B. Story Points oder Stunden.
Finanzielle Schulden haben zwei Komponenten die müssen zurück gazahlt werden, das Schuldenkapital, und die Zinsen. Das ist genauso bei Technical Debt. Wir haben den Aufwand benötigt um das Technical Debt selber zu entfernen, sowie den zusätzlichen Aufwand an anderen Anforderungen und Bugfixes usw.
Zur Zeit siehen die Kunden normalerweise nur einen Totalaufwand pro Anforderung, die Zinsen ist schon Inklusiv, und das Schuldenkaptial ist oft komplett vom Kunden versteckt.
Bevor Kunden interesse auf Clean Code, und innere Qualität haben werden, müssen beide dieser Komponenten den Kunden explizit angezeigt.
z.B. Wenn eine User Story 5 Story Points kosten soll, aber kostet wegen Technical Debt 15 Story Points. Der Kunde sollte nicht einfach die 15 sehen, sondern soll er wissen genau wie viel er "Zahlt" und wofür. Erst dann wird er Interesse haben, die innere Qualität zu verbessern.
Naturlich sollte der Kunde auch eine Idee haben über wie viel Technical Debt insgesamt im System liegt.
Also aus meiner Erfahrung heraus ist das 'Problem' einfach mangelndes Wissen seitens der Kunden. Die wollen eine Software, die gut läuft, Ihren Anforderungen entspricht und Ihnen ein gutes Gefühl vermittelt. Für technische Details wie 'innere Qualität'interessieren sie sich einfach nicht - meistens wissen sie noch nicht mal so genau, was das ist. Sollen und müssen sie auch nicht; es ist ausschließlich Sache der Abteilung 'Software-Entwicklung', gute Arbeit abzuliefern. Der Kunde handelt nach dem Motto 'gutes Geld für gute Arbeit'. Technische Details sind nicht sein Metier, es hat ihm aber auch in den letzten Jahren niemand wirklich gesagt, dass interne Qualität bei Software wie bei jedem anderen Produkt auch eine wichtige Sache ist, dass man die messen und verbessern kann.
Der Kunde soll sich damit auch überhaupt nicht befassen müssen, dafür bezahlt er ja schließlich Leute, von denen er annimmt, dass die ihr Handwerk verstehen. Es ist wie bei jedem anderen Produkt auch: Höhere Qualität kostet auf kurze Sicht mehr, ist nicht unmittelbar zu sehen und zahlt sich erst auf längere Sicht aus. Wenn du ein T-Shirt kaufst, mag es erst mal gut aussehen - wenn es aber nach dem ersten Waschen nur noch als Putzlappen zu gebrauchen ist, dann war es eine ziemlich schlechte Investition; egal wie 'billig' es war...
Die eigentliche Herausforderung für die Fraktion 'SW-Entwicklung' besteht IMHO darin, sich als Fach-Experte hinzustellen und zu sagen: 'Ok, wir brauchen jetzt für die Entwicklung vielleicht ein paar Wochen oder Monate länger, dafür kommt das über geringere Wartungskosten in den nächsten Jahren zigfach wieder rein.' Wenn man das business-like überzeugend vorbringen kann(also nicht in technischem Kauderwelsch, sondern mit Begriffen wie etwa 'Kosten/Nutzen', 'Return on Investment' oder 'Investitionssicherheit'), rennt man bei den meisten Kunden offene Türen ein.
Der Kunde ist meiner Erfahrung nach wirklich das geringste Problem an der Sache, eher ist das schon der Entwickler, der seit Jahren denselben Stiefel macht und für Sachen wie 'interne Software-Qualität' im Grunde nichts übrig hat, weil 'wir steigern jetzt die Qualität' immer auch impliziert: 'bis jetzt lässt sie zu wünschen übrig'. Uneinsichtige Kunden sind mir bis jetzt eigentlich noch nicht untergekommen, nur welche, die noch niemand überzeugt hat, in Qualität zu investieren. Dafür aber eine ganze Menge 'alteingesessene' Entwickler, die jede Veränderung passiv boykottieren...
Ein Hauptproblem ist doch, dass im Zweifelsfall - wenn es billiger oder schneller gehen muss - die Qualität außen vor gelassen wird. Dann wird eben doch schnell mal unsauberer Code geschrieben, den man ja später noch aufräumen kann, um das (zumeist) zeitliche Projektziel zu halten.
Da der Kunde auch erst einmal nicht sieht, wie die innere Struktur aussieht, ist ihm das dann zunächst auch egal. Erst langfristig machen sich diese "bad smells" dann bemerkbar, hauptsächlich in mangelnder Wart- oder Erweiterbarkeit.
Dass die Ursachen hierfür jedoch im ursprünglichen "Schnell, schnell" liegen - das wird dann häufig gerne ignoriert.
Wie ich mal in einem Blogeintrag (http://www.des-eisbaeren-blog.de/post/2009/02/01/Die-Forderung-nach-Softwarequalitat.aspx) geschrieben habe:
"Das Paradoxe an Softwarequalität ist nämlich, dass sie gleichzeitig Geld und Zeit kostet, aber auch Geld und Zeit spart: Wird während der Entwicklung bereits auf die Einhaltung gewisser Qualitätsregeln geachtet, ist das natürlich aufwändiger, als wenn dies nicht geschieht.
Leider wird die Argumentation in der Praxis häufig an dieser Stelle beendet, denn sobald Auslieferungstermine oder Kosten die Entwicklung beeinträchtigen könnten, wird in der Regel als erstes an der Qualität gespart, denn der Code könnte zu einem späteren Zeitpunkt noch überarbeitet werden.
Das Problem ist nur: Dieser Zeitpunkt wird so gut wie nie erreicht. Denn nach der Auslieferung der Software beginnen zumeist die Arbeiten an der nächsten Version – Zeit, die vorherige erst noch zu bereinigen, findet sich nicht.
Vordergründig mag dieses Vorgehen auch in Ordnung sein, denn auf den ersten Blick funktioniert alles, und es wurden sogar Zeit und Geld gespart. Zugleich wird akzeptiert, dass der ausgelieferte Code nicht fehlerfrei ist, weshalb später Zeit in die Behebung von Bugs fließen muss. Doch genau an dieser Stelle liegt der Hund begraben."
Hier anzusetzen und dem Kunden klarzumachen, dass anfangs höhere Kosten unterm Strich langfristig gesehen Geld sparen, das ist meines Erachtens essenziell wichtig.
@Golo
Du schreibst:
'Das Paradoxe an Softwarequalität ist nämlich, dass sie gleichzeitig Geld und Zeit kostet, aber auch Geld und Zeit spart: Wird während der Entwicklung bereits auf die Einhaltung gewisser Qualitätsregeln geachtet, ist das natürlich aufwändiger, als wenn dies nicht geschieht.'
Wieso nennst Du das paradox? Das ist das normalste von der Welt bei jedem Produkt - es ist schlicht und einfach die Beobachtung: 'Qualität gibt es nicht umsonst'. Das Problem sehe ich eher darin, dass diese eigentlich sehr simple Tatsache bei der Software-Entwicklung noch immer einen irgendwie mythischen und gewichtigen Klang hat...
Paradox in dem Sinne, dass man Geld ausgeben muss, um Geld zu sparen.
Ich bin nicht davon überzeugt daß Kunden sich Gedanken über innere Qualität von Software machen, weil sie sie nicht verstehen. Vielleicht kann man es mit einem Fernseher vergleichen. Millionen haben so ein Ding zu Hause stehen, aber wer weiß schon wie er im Inneren funktioniert? Und auch nur eine Minderheit interessiert sich dafür (ausgenommen Fernsehtechniker). Die innere Qualität kann nur bewerten wer selber Entwickler ist. Erst wenn die Software vor die Wand läuft und dann die Frage aufkommt, warum die Problembehebung so viel Zeit und Geld kostet, wird über innere Qualität gesprochen.
Alle Kunden sind gleich :)
@*: Ihr habt ja recht, dass Kunden sich keine Gedanken über die Details machen sollen müssen.
Ihr habt auch recht, dass die Entwickler darauf achten müssen für das ganze Geld, das sie bekommen.
Letztere tun es nun de facto aber nicht, sonst würden wir hier nicht die Hände überm Kopf zusammenschlagen.
Und erste tun genau das, was sie sollen: Sie kümmern sich nicht. Haargenau.
Das tragische ist nun, dass sich Anwender/Kunden um die Details bei Software aber zu unrecht keine Gedanken machen, weil es bei Software kein rechtliches oder ingenieursmäßiges "Sicherheitsnetz" gibt.
Von Butter über Fernseher bis Airbus mache ich mir als Anwender auch keine Gedanken über die Details und esse, schaue, fliege damit gut. Denn meine Interesse an guter Qualität, das ich zweifelsfrei habe, wird durch Gesetzgebung, Prüfungsinstanzen und Berufsethos geschützt. Und wenn nicht, dann in einem Rahmen, der mir nicht nachhaltig schadet. Dann wechsle ich halt nur die Marke.
Deshalb ist ein Gammelfleischskandal auch eben ein Skandal. Der zeigt auf seiner Rückseite, welch gute Qualität wir in 99,9% aller Produktfälle bekommen. Wir können uns auf Qualitätskontrollen, die wir voraussetzen, verlassen.
Und genau dieses Vertrauen haben Laien (Anwender, Kunden) nun auch bei der Softwareentwicklung. Sie können sich schlicht nicht vorstellen, dass die Qualität einer wichtigen Dimension (Nachhaltigkeit) so grauslich ist. Sie können sich nicht vorstellen, dass sie viel Geld in Software versenken, weil das "Projektmanagement" nicht softwaregerecht ist.
Das ist mein Punkt. Sie sind nur ärgerlich, können es oberflächlich manchmal nicht fassen, dass eine Software wieder abstürzt oder es so lange dauert, bis ein einfaches Feature eingebaut ist. Aber das erschüttert ihr Grundvertrauen nicht.
-Ralf
Ich glaube, das Problem dabei ist, dass Software so abstrakt ist, und für viele einfach nicht greif- und damit auch nicht vorstellbar.
Bei einem Flugzeug ist jedem klar, dass es aus mehr als einem Rumpf mit zwei Flügeln besteht - dass da wahnsinnig viel Konstrukteursleistung drinsteckt, massenhaft komplizierte Technik, viel Elektronik, und und und ... und selbst wenn das jemand nicht weiß, kann man ihm das auch als Laien so anschaulich erzählen, dass er ein Gefühl dafür bekommt.
Anders bei Software: Mal böse formuliert - was kann man als Entwickler schon spannendes für einen Laien erzählen? Juhuu, ich weiß jetzt, wie ein COM-Surrogate funktioniert?
Software besteht für die meisten Benutzer aus der UI. Sieht die UI gut aus, meinen die meisten Menschen, die Software wäre fertig. Dass die Oberfläche aber eigentlich rein gar nichts mit dem Kern zu tun hat, begreifen die meisten schon nicht. Wie sollen sie da ein Verständnis für die innere Qualität des Kerns entwickeln?
Prinzipiell gebe ich Dir mit Deinem Punkt also vollkommen recht - die Frage ist nur, ob man daran etwas ändern kann, und wenn ja, wie.
@Golo: Natürlich ist Software grundsätzlich anders als ein Fernseher.
Aber ich bezweifle, dass du dir unter der Qualitätssicherung für Butter oder eine Brücke oder ein Medikament wirklich etwas vorstellen kannst.
Oder wenn du dir darunter etwas vorstellen kannst, dann ist das auch nur eine Annäherung an die Realität und gründet sich in sehr abstrakten/allgemeinen Bildern. Du hast davon einfach schon mehr gehört. Dass (!) es dort eine systematische Qualitätssicherung gibt, hast du schlicht öfter gehört.
Wenn du also Butter, Fernsehen, Medikament traust, hat das mit Institutionen zu tun (chain of trust), Darstellungen von "Ritualen" und "Symbolen".
Der Trick ist nun, dass das Vertrauen in Software (jenseits der oft zweifelhaften äußeren Qualität) nicht unmittelbar, sondern nur mittelbar zu sein scheint. Softwarequalitätssicherung wird nie mit eigenen "Ritualen" und "Symbolen" beschrieben (oder "beschworen"). Es ist selbst nur ein letztes Glied in einer chain of trust.
Weil die Qualität von Butter, Fernseher, Airbus so hoch ist und sie Ergebnisse moderner Ingenieurskunst sind, kann doch auch nur die innere Qualität von Software hoch sein als Ergebnis moderner Ingenieurskunst.
Vertrauen in Software ist also das Ergebnis eines Syllogismus.
Das die Prämisse aber falsch ist - was eben der Kunde nicht weiß -, dass Qualität bei Software nicht im mechanischen Herstellungsprozess, sondern im kreativen Designprozess entsteht, und auch nicht so systematisch wie bei Brücken oder Waschmaschinen entsteht, deshalb ist die Konklusion leider falsch.
Warum weiß man nicht, dass die Prämisse falsch ist? Weil, wie du sagst, Software so abstrakt ist. Eine Gesellschaft, bei der es in der Masse hoffähig und normal ist, ohne Scham Unkenntnis der Mathematik jenseits des Dreisatz zuzugeben, will sich einfach mit so abstraktem Zeugs nicht auseinandersetzen (oder kann es nicht).
Ölverschmierte Hände oder geschniegelt im Geldzähleranzug oder im Arztkittel: das ist greifbar, da kommt unmittelbares Vertrauen auf.
Mathematik oder Softwareentwicklung jedoch, die sind nicht unmittelbar greifbar, deshalb ist das Vertrauen dort nur mittelbar. Bei der Mathematik ist das nicht schlimm, weil die keine Produkte herstellt, sondern nur anderen Dienstleisterin ist.
Bei der Softwareentwicklung ist es aber nun ein Problem, wie wir sehen.
Kann man das ändern? Ja, das glaube ich. Das bedarf nur Medieneinsatz. Es müssen Bilder für den schlimmen Zustand jetzt gefunden werden. Das geht, auch wenn es dann nur Analogie/Metaphern sind. Und dann müssen "Rituale" und "Symbole" für eine Softwarequalitätssicherung her. Auch das geht. Die Frage ist nur, wer das will?
Sobald jedoch das status quo mal echt gefühlt worden ist, sobald die Kunden erwachen, gibt es kein Halten mehr. Die Branche lebt aufs Ganze gesehen von einem Image wie die Bestatter vor noch 20 Jahren. Das Image verhindert, dass hinter die Fassade geschaut wird.
Aber das hat sich bei den Bestattern geändert und das wird sich bei der Softwareentwicklung auch ändern.
-Ralf
@Ralf: Das sehe ich ganz genauso.
Aber abgesehen davon, dass Software irgendwie abstrakt ist, ist die Software-Entwicklung als Disziplin ja auch noch sehr jung und deshalb gibt es in vielen Bereichen einfach noch keinen Konsens darüber, wie eine bestimmte Sache am Besten zu bewerkstelligen ist.
Wenn du 100 Programmierer fragst, ob innere Qualität wichtig ist, kriegst du 100mal 'Ja' als Antwort. Wenn du 100 Programmierer fragst, was innere Qualität denn eigentlich ist und wie man sie messen sollte, kriegst du 200 verschiedene Antworten.
Ich denke, was die Software-Entwicklung erst einmal braucht, ist ein kanonisches Konzept von 'interner Qualität'. Etwa so: 'Die Test-Coverage muss mindestens x% sein; die zyklomatische Komplexität darf nirgends höher als y sein; keine Methode darf mehr als z Zeilen haben; usw.'. Als nächstes könnte man dann diese Vorgaben automatisieren, auf einem Build-Server mit entsprechenden Analyse-Tools. Es gibt ja schon alles, was man dafür braucht, entweder frei (z.B. CruiseControl.NET, StyleCop, FxCop, verschiedene xUnit-Frameworks) oder für kleines Geld (z.B. NCover, NDepend, Simian). Technisch ist das also alles gar kein Thema.
Am Ende könnte man dann, wenn man möchte, jedes Software-System mit einem Qualitätsstempel versehen und die innere Qualität mit einer Zahl oder einer Schulnote ausdrücken - klar, das wäre eine grobe und eigentlich unzulässige Vereinfachung, aber das sind andere Produktkennzeichnungen wie etwa die Lebensmittelampel auch. Es geht dabei auch eher darum, diese 'chain of trust', von der du sprichst, für den Kunden greifbar zu machen und ihm zu vermitteln, dass tatsächlich eine systematische Qualitätssicherung stattgefunden hat.
Entscheidend scheint mir aber vor allem, dass interne Qualitätssicherung ein selbstverständlicher Teil der Software-Entwicklung wird, der so selbstverständlich ist, dass man gar nicht mehr auf die Idee kommt, überhaupt darüber zu reden. Wie absurd wäre es, sich einen Verantwortlichen in einer Butterfabrik vorzustellen, der mit seinen Angestellten darüber diskutiert, ob man nun eine bestimmte Tranche nun ausliefern kann, obwohl die Kuh krank war. Aber genau das passiert regelmäßig in Softwareprojekten, wenn gesagt wird: 'Wir räumen den Code später auf. Jetzt müssen wir erstmal den Termin halten.' Ich denke, wir sind erst dann ein gutes Stück weiter, wenn niemand mehr auf die Idee kommt, so etwas auch nur zu denken...
@ Ralf: Natürlich weiß ich nicht, wie der Qualitätssicherungsprozess für Butter oder für eine Brücke aussieht - aber, man kann es einem Laien anschaulich erklären. Während meiner Studienzeit hatte ich einen Nachbarn, der Architektur studiert hat: Er konnte mir - wo ich von Architektur und Bauen nun wirklich gar keine Ahnung habe - spannend und anschaulich erklären, was er macht, womit er sich beschäftigt, wo die Probleme liegen, ... einfach, weil es greifbar ist.
Wie schon gesagt: Bei der IT geht das schlecht, und ob Metriken, wie von Thomas vorgeschlagen, helfen, wage ich zu bezweifeln.
Letztlich läuft es aber immer wieder doch darauf hinaus, was ich schon weiter oben schrieb: "Hier anzusetzen und dem Kunden klarzumachen, dass anfangs höhere Kosten unterm Strich langfristig gesehen Geld sparen, das ist meines Erachtens essenziell wichtig."
Denn kein Kunde würde sagen, dass man die innere Qualität nicht gut umsetzen soll, wenn man ihn fragt - sofern er nicht das Gefühl hat, es wird nur Geld verpulvert für irgendwas, was er weder sieht noch wovon er irgendeinen Nutzen hat.
Und das ist meines Erachtens die große Herausforderung: Dem Kunden klarzumachen, warum manche Sachen vordergründig eben auf die eine oder auf die andere Art gelöst werden können - warum aber nur eine von beidem auch für ihn empfehlenswert ist, auch wenn sie ihn zunächst mehr Geld kostet.
Insofern, um auf Deine Einstiegsfrage zurückzukommen: Nein, ich glaube, Kunden ist schlechte Softwarequalität nicht egal. Aber sie wird nicht richtig kommuniziert und erscheint deshalb oft als nachrangig oder als sekundärer Faktor, der zwar nicht viel bringt, aber jede Menge Geld und Zeit kostet.
@Golo: Natürlich wird schlechte Qualität nicht von den Entwicklern kommuniziert. Die wissen es selbst kaum besser oder haben kein Interesse an der Kommunikation schlechter Quali oder sind unglücklich, es auch nicht besser machen zu können.
Wenn also schlechte innere Quali nicht von der Entwicklung (dem Produzenten) kommuniziert wird, dann kann es nur anders gehen.
Eine Möglichkeit: Der Produzent kommuniziert ganz bewusst gute Qualität.
Andere Möglichkeit: Eine dritte Instant kommuniziert die schlechte Qualität.
You choose.
-Ralf
@Golo: Natürlich sind die Metriken an sich nicht anschaulich, das sind nur technische Details. Die eigentliche Aufgabe besteht jetzt, wie du sagst, genau darin, dem Kunden klarzumachen, was das heißt.
So nach dem Motto: 'Wenn die und die Meßwerte schlecht sind, kommen in den nächsten Jahren schätzungsweise x EUR mehr an Wartungskosten auf Sie zu, und bei der nächsten Erweiterung wird die Hälfte Ihrer Entwickler kündigen.' - Kein Scherz, ich habe tatsächlich schon miterlebt, dass sowas so richtig eskaliert ist.
Grobe Hausnummern bezüglich etwaiger Mehrkosten kann man schon angeben, und die Sprache versteht der Kunde dann ohne weiteres - und er wird da auch seeeehr aufmerksam zuhören, wenn man von Geld redet und nicht von irgendwelchem esoterischen Technikram.
Die Frage ist jetzt eigentlich nur noch, wie Ralf auch anmerkt, ob das auch tatsächlich immer und überall so gewollt ist...
Ich denke das kommt ganz auf das jeweilige projekt an, z.b. wenn man eine Software Programmiert die Hardware ansteuert, so renetiert sich Clean Code ab dem Zeitpunkt ab dem etwas veraendert oder erweitert werden muss. Und ab diesem Zeitpunkt schaetzt der Kunde die Mehrarbeit und den sicherlich erstmals gar nicht so geringen Mehraufwand
Kommentar veröffentlichen