Die Kunst des "Fertig Werdens" in der Softwareentwicklung

[CodeScout]

 

Hallo zusammen,

Kennt ihr folgendes Phänomen? Manchmal scheint es, als ob die schnell zusammengezimmerten Projekte, die wir aus der Not heraus fertig machen, am Ende besser ankommen als die, über die wir ewig brüten und die nie wirklich fertig werden. Warum ist das so?

Ist am Ende des Tages "fertig" besser als "perfekt"? Am Ende zählt ja meist, dass die Software funktioniert und die Leute sie nutzen können.

Aber was ist eigentlich wichtig, damit Software erfolgreich ist? Die Software, die langfristig verwendet wird, ist oft nicht unbedingt diejenige mit dem schönsten Code, sondern eher diejenige, die dem Nutzer einen echten Mehrwert bietet.

Ich stelle diese Frage, weil ich oft erlebt habe, wie wir als Entwickler stundenlang über eine perfekte Lösung nachdenken, nur um dann festzustellen, dass sie an den Anforderungen der Stakeholder vorbeigearbeitet haben. Die Stakeholder wiederum ärgern sich darüber, dass das Endergebnis nicht das ist, was sie wollten. Meist endet das in dem immer gleichen Konflikt. 

Laut agilen Baukasten gibt es dafür genug Lösungen in der Praxis funktionieren sie aber meist nur, wenn beide Seiten sehr fit in dem Gebiet sind.

 

 

[bigvic]

Softwareentwicklung sollte - ausser im Hobbybereich - kein Selbstzweck sein. Von daher geht es immer um den Nutzen.
Eine meiner ersten Softwareentwicklungen war 10Jahre+ erfolgreich im Einsatz bei x Kunden und hat dem Unternehmen Millionen gebracht. Der Code war gelinde gesagt einfach eine Katastrophe. Interessierte keine Sau

[CodeScout]

vor 7 Minuten schrieb bigvic:

Softwareentwicklung sollte - ausser im Hobbybereich - kein Selbstzweck sein. Von daher geht es immer um den Nutzen.
Eine meiner ersten Softwareentwicklungen war 10Jahre+ erfolgreich im Einsatz bei x Kunden und hat dem Unternehmen Millionen gebracht. Der Code war gelinde gesagt einfach eine Katastrophe. Interessierte keine Sau

Allerdings gibt es auch immer wieder Fälle, wo etwas nicht fertig wird oder funktionierende Komponenten neu entwickelt werden, weil diese sonst nicht "wartbar" sind. 
 

Bearbeitet 9. Februar von CodeScout

[Brapchu]

vor 5 Minuten schrieb CodeScout:

Allerdings gibt es auch immer wieder Fälle, wo etwas nicht fertig wird oder funktionierende Komponenten neu entwickelt werden, weil diese sonst nicht "wartbar" sind. 

Je nach Einsatzfeld ist wartbarer Code halt eine ziemlich wichtige Sache.

Da kannst wenn ein Problem oder Bug auftaucht oder sich gesetzliche Bestimmungen ändern nicht mal eben X-Monate neu entwickeln. Stellenweise muss es da zack zack gehen.

[Parser]

vor 12 Minuten schrieb bigvic:

Der Code war gelinde gesagt einfach eine Katastrophe. Interessierte keine Sau

Das mag aus pragmatischer und ökonomischer Sicht eine valide Herangehensweise sein. Ich finde aber, wir Softwareentwickler sollten tatsächlich den Anspruch an uns haben, handwerklich gute Software zu entwickeln. Nicht zuletzt deshalb geistert ja auch seit einiger Zeit der Begriff Software Craftsmanship durch die Lande, wo man u.a. auch was vom Berufsethos der Softwareentwickler liest. 

[CodeScout]

vor 2 Minuten schrieb Brapchu:

Da kannst wenn ein Problem oder Bug auftaucht oder sich gesetzliche Bestimmungen ändern nicht mal eben X-Monate neu entwickeln. Stellenweise muss es da zack zack gehen.

Aber würde es gerade das nicht dafür sprechen lieber das "alte" zu belassen? Meist geht ist es immer noch schneller und sicherer die bestehende Änderung in den schlecht wartbaren Code zu programmieren als alles neu zu machen. 
Ich glaube als Softwareentwickler muss ich auch den Mut und die Fähigkeit haben anderen Code zu verstehen. Für einen selbst ist die eigenen Struktur immer die Logistische und die der Anderen immer schwer zu verstehen. 

[CodeScout]

vor 3 Minuten schrieb Parser:

Das mag aus pragmatischer und ökonomischer Sicht eine valide Herangehensweise sein. Ich finde aber, wir Softwareentwickler sollten tatsächlich den Anspruch an uns haben, handwerklich gute Software zu entwickeln. Nicht zuletzt deshalb geistert ja auch seit einiger Zeit der Begriff Software Craftsmanship durch die Lande, wo man u.a. auch was vom Berufsethos der Softwareentwickler liest. 

Aber was bringt mir super saubere Software, wenn sie nicht "fertig" wird. Ich glaube manchmal sieht sich ein Softwareentwickler zu sehr als Künstler und liefert deshalb lieber kein Ergebnis ab als ein nicht Perfektes. 

Geld verdienen tut man effektiv nur mit "Fertiger" aber nicht mit Schöner Software. 

[Parser]

vor 3 Minuten schrieb CodeScout:

Geld verdienen tut man effektiv nur mit "Fertiger" aber nicht mit Schöner Software. 

wie @Brapchu bereits bemerkte, kann es für das Unternehmen richtig teuer werden, wenn man Software am Start hat, die nicht wartbar und/oder nicht erweiterbar ist. Man hat zwar dann für den Moment eine funktionierende "fertige" Software, ist aber - im schlimmsten Fall - zwei Monate später insolvent weil man wie gesagt die Software nicht warten/erweitern kann. 

[Parser]

Diese Fallstricke von handwerklich schlechter Software zu erkennen, das halte ich für einen Teil unserer Aufgabe, wofür wir auch nicht unerheblich wenig Geld bekommen. Wenn du so willst: Strategisches und langfristiges Denken. 

[Brapchu]

vor 6 Minuten schrieb CodeScout:

Aber was bringt mir super saubere Software, wenn sie nicht "fertig" wird. Ich glaube manchmal sieht sich ein Softwareentwickler zu sehr als Künstler und liefert deshalb lieber kein Ergebnis ab als ein nicht Perfektes. 

Geld verdienen tut man effektiv nur mit "Fertiger" aber nicht mit Schöner Software. 

In manchen Branchen ist deine Software nie "fertig".

Das kann sie aus Prinzip nicht sein.

Software im medizinischen Sektor zum Beispiel.

Da kommen alle paar Monate neue Features die erwartet werden von Kunden oder bestehende müssen schnell angepasst werden.

vor 11 Minuten schrieb CodeScout:

Aber würde es gerade das nicht dafür sprechen lieber das "alte" zu belassen? Meist geht ist es immer noch schneller und sicherer die bestehende Änderung in den schlecht wartbaren Code zu programmieren als alles neu zu machen. 
Ich glaube als Softwareentwickler muss ich auch den Mut und die Fähigkeit haben anderen Code zu verstehen. Für einen selbst ist die eigenen Struktur immer die Logistische und die der Anderen immer schwer zu verstehen. 

Wenn du ein Immediate auf dem Tisch hast und es um eventuellen Personenschaden geht betest du das der Code gut wartbar ist. Da hast du keine Zeit dir Zeit zum "verstehen" zu nehmen.

[CodeScout]

vor 1 Minute schrieb Parser:

Diese Fallstricke von handwerklich schlechter Software zu erkennen, das halte ich für einen Teil unserer Aufgabe, wofür wir auch nicht unerheblich wenig Geld bekommen. Wenn du so willst: Strategisches und langfristiges Denken. 

Ja da hast du Recht. Allerdings ist man als Softwareentwickler nicht alleine und kann als selbst entwickeln. Zumindest nicht ohne Burnout ;). Meist hat man im Team auch viele Unerfahrene Entwickler die erstmal lernen müssen, was sauberer Code ist. 

Zum anderen ist leider "wartbar" ein sehr subjektiver Begriff. Viele Programmierer halten nur ihren eigenen Code für wartbar weil sie dort die Gedankengänge verstehen

[CodeScout]

vor 7 Minuten schrieb Brapchu:

In manchen Branchen ist deine Software nie "fertig".

Oh da habe ich mich ungünstig ausgedrückt. Ich meinte mit fertig. Das Features oder Anpassungen ausgeliefert werden. Nicht, dass ich ein Softwarestand habe, den ich einfrieren kann. 

[CodeScout]

vor 12 Minuten schrieb Brapchu:

Wenn du ein Immediate auf dem Tisch hast und es um eventuellen Personenschaden geht betest du das der Code gut wartbar ist. Da hast du keine Zeit dir Zeit zum "verstehen" zu nehmen.

Ich glaube ich bete eher, dass ich einen fähigen Entwickler habe, der weiß, wie man sich in Altsystemen zurecht findet. 

Klar gibt es Abstufung beim Risiko. Und bei Software, wo potenziell Personen gefährdet sind, habe ich natürlich eine ganz andere QA, als wenn ich eine Bewertungsplattform betreibe. 

Aber zum Beispiel eine Woche an einer einfachen Kommentarfunktion zu sitzen weil man über jeden Datentypen und jeden Variablennamen eine halbe Stunde nachdenkt kann denke ich auch nicht die Lösung sein. 

Bearbeitet 9. Februar von CodeScout

[0x00]

vor 39 Minuten schrieb Parser:

Diese Fallstricke von handwerklich schlechter Software zu erkennen, das halte ich für einen Teil unserer Aufgabe, wofür wir auch nicht unerheblich wenig Geld bekommen. Wenn du so willst: Strategisches und langfristiges Denken. 

Die wirkliche Kunst ist zu erkennen, wann Software gut genug ist. Manchmal muss sie wirklich schön strukturiert, gut aufgebaut, wartbar und was weiß ich noch alles sein, manchmal tut's aber auch der Code, den man schnell zwischen zwei Meetings nebenbei zusammengehackt hat.

Da muss man dann auch mal als SWE über seinen eigenen Schatten springen können und schlechten Code shippen, anstatt sich ewig in Details, die eh keinen interessieren, zu verkünsteln.

Wie immer: Es kommt drauf an.

[hellerKopf]

"Ein Optimist sagt: Das Glas ist halb voll. Ein Pessimist sagt: Das Glas ist halb leer. Ein Entwickler sagt: Das Glas ist doppelt so groß, wie es sein sollte."

vor einer Stunde schrieb 0x00:

Die wirkliche Kunst ist zu erkennen, wann Software gut genug ist

Das ist immer abhängig von der Frage, "für wen fertig?"

Für die Endrechnung an den Kunden.
Den Kunden als Auftraggeber, die Anwender beim Kunden
Nach den jetzigen Anforderungen oder für den Einsatz in noch 5 Jahren......

Oder geht es um die Frage, "wann bin ich(!) zufrieden mit dem das ich gemacht habe ?

Der alte Herr Porsche soll über den Prototypen des 911er gesagt haben "jede Schraube ist genau da, wo sie sein sollte"
Und trotzdem haben sie das Fahrzeug dauernd weiter entwickelt.

Außerdem würde uns perfekte Softwareentwicklung schnell den Grund für Wartungsverträge, Update und Relasewechsel nehmen.  Fertig ist, wenn der Kunde zahlt.

Allerdings, da ich mir nie selber eine Abschlußrechnung schreibe, arbeite ich heute noch an einen Projekt für meinen persöhnlichen Gebrauch, seit 12 Jahren.

[pr0gg3r]

 

Eines meiner Lieblingsthemen  Ich denke, wir müssen das aus mehreren Perspektiven Betrachten.

Erst einmal, gibt es ja verschiedene Arten von Qualitäten. Wenn wir von Anwendungssoftware reden, reden wir auch immer über User-Experience (UX) und hedonische Qualität. Das bedeutet, dass eben eine Software nicht "nur" funktioniert, sondern auch dem Nutzer einen angenehmen und positiven Nutzen bietet. Eine gute UX erreicht man über folgende Stufen: Functional -> Reliable -> Usable -> Convenient -> Pleasurable -> Meaningful (einfach mal nach "UX Pyramid" googeln). Das heißt, wenn eine Software schon nicht macht was es soll, kann man gar nicht keine hohe Gesamtqualität erreichen. Wenn es aber macht was es soll, dabei aber total umständlich ist, hat man auch keine hohe hedonische Qualität. Es gibt auch Studien die sagen, dass eine hohe hedonische Qualität eine funktionale Qualität durchaus kompensieren kann, aber nicht anders herum. Sprich: der Nutzer verzeiht mehr, wenn es sich für ihn gut anfühlt. 

Natürlich kann man jetzt Software hinklatschen, so dass es irgendwie funktioniert wie es soll auch noch eine hohe UX hat. Dabei kann man auch schnell Nutzertests machen und einen schnellen Go-to-market erreichen, was ja auf den ersten Blick gut ist. Allerdings hat das auch ein paar Nachteile. Und zwar können wir jetzt auch die Software-Qualität betrachten: wann ist eine Software qualitativ gut? Grundsätzlich kann man sagen, dass Software eine gute Qualität hat, wenn sie folgendes beinhaltet: Reliability, Maintainability, Testability, Portability, Reusability, ... (einfach nach "Code Quality" suchen). Allerdings ist das schwer zu messen (was sagt einem z. B. eine 100%ige Testabdeckung, wenn das falsche getestet wird?). Von technischen Schulden möchte ich hier gar nicht erst anfangen, das ist ein Thema für sich.

Zusätzlich muss man sagen: "es kommt drauf an". Während für eine Eier-Uhr-App ein schlechter Code noch keinen allzu risikobehafteten Impact hat, sieht es in einem Auto oder sogar in einem Flugzeug ganz anders aus (sowohl bei technischen Fehlern als auch bei Bedienfehlern die durch schlechte Usability entstehen können).

Wichtig ist auch der Punkt, dass eine 100%ige Qualität ein Zustand ist, der nie erreicht werden kann. Allerdings muss man irgendwo Grenzen ziehen, mit welcher Qualität man sich zufrieden geben möchte (z. B. wir machen nicht tausend Test-Cases, aber wir testen mit wenigen Tests die Punkte, die kritisch sind).

Ich muss hier @bigvic recht geben: Ich habe oft gesehen, dass sich Kunden Null um Qualität scheren, schließlich sind sie auch häufig nicht die Experten auf dem Gebiet und wollen auch Kosten sparen (Usability-Test? Wieso? Warum ein paar Tage für Unit-Tests bezahlen, es funktioniert doch?, etc.). Und bei Hobby-Projekten habe ich durchaus mehr Quick-and-dirty-Stellen wo ich denke "da muss man bei Zeit nochmal ran" als auf der Arbeit.

Da hier in dem Thread (wie häufig in letzter Zeit) agile Softwareentwicklung genannt wurde: eine agile Arbeitsweise bedeutet nicht automatisch, dass die Qualität leiden muss. Ich würde behaupten, Unternehmen die keinen Wert auf Qualität legen machen das weder agil noch nicht agil. Und Unternehmen die Wert drauf legen, können das auch agil. Das ist kein Wiederspruch.

Und dann fehlt noch der wirtschaftliche Faktor: auf der einen Seite kostet hohe Qualität Zeit (und somit Geld). Aber einen Bug beim Kunden zu fixen, ist viel teurer (z. B. wenn zig Autos für ein Software-Update zurück in die Werkstatt müssen oder Kunden abspringen, weil das was sie brauchen nicht gut funktioniert). Je früher ein Fehler gefunden wird, desto besser. Man kann jetzt aber auch nicht unendlich Zeit brauchen und unendlich Geld verbrennen. Auch hier muss man irgendwo eine Mitte finden.

Viel schlimmer finde ich, wenn Unternehmen wissen, dass ihre Software Schrott oder halbfertig ist und dann trotzdem veröffentlichen. Die Spieleindustrie ist hier ein gutes Beispiel.

 

[CodeScout]

@pr0gg3r Danke für die ausführliche Antwort. Ich glaube das beleuchtetet die Thematik sehr gut.

Man sollte aber auch den Führungssicht berücksichtigen:

Als erfahrener Entwickler der schon viele Projekte oder Features erfolgreich Produktiv gebracht hat hat mich glaube ich ein Gefühl dafür.

Interessant wird es, wenn Software im Team entwickelt wird. Da gibt es  häufig Entwickler  die eigentlich sehr gut sind aber alles überperfektionieren. Meist in die Richtung. „Das mache ich am Wochenende lieber neu“

Es ist immer schwierig die motiviert zu halten aber trotzdem Ergebnisse in angemessener Zeit zu bekommen oder dort Grenzen zu setzen.

Besonders kritisch wird es, wenn sie anfangen zu merken, dass genau die wichtigen Dinge fehlen. Dann gibt es oft Konflikte weil die Anforderungen nicht klar waren.

Zudem hat man bei diese zu kritische Sichtweise häufig das Phänomen, dass die Leute in eine Art Führungsposition rutschen und andere Entwickler nicht mehr eigenständig arbeiten und sich rückversichern. 

[Rabber]

Ist eine Grauzone ohne klare und richtige Antwort.

natürlich ist Code Qualität wichtig. Aber es ist ebenso richtig, dass sie kein Selbstzweck ist und Grenzen haben muss. Ebenso beim Unit Testing. Die goldene 80/20 Regel trifft es da schon ganz gut.

Ist in der Tat ein heißes Thema bei vielen Entwicklern. Gerade bei denen, die für die Thematik als solche brennen. Die übertreiben nur all zu gerne und verlieren aus den Augen, worum es eigentlich geht. Wiederum andere sind schlicht faul und produzieren grottigen Code, den man so nie in Produktion bringen dürfte.

Bearbeitet 13. Februar von Rabber

[Velicity]

Ich denke häufig ist das Problem die Größe. Diese schnell zusammengezimmerten Sachen, die sich ewig halten und funktionieren sind eben meist sehr konkrete Sachen, die nix sind als Implementationsdetails. Keine große Konfiguration, keine vielen Sonderfälle, vor allem eben keine Generalisierung. Da wo solche Sachen genutzt werden können, sind sie sicher auch mehr als angebracht.

Am 9.2.2024 um 15:51 schrieb CodeScout:

Aber was ist eigentlich wichtig, damit Software erfolgreich ist? Die Software, die langfristig verwendet wird, ist oft nicht unbedingt diejenige mit dem schönsten Code, sondern eher diejenige, die dem Nutzer einen echten Mehrwert bietet.

Das ist bei Software, an der nicht viel geändert wird auch relativ egal. Die ist hässlich, die hat nur derjenige verstanden, der sie geschrieben hat, sich da neu reinzudenken dauert ewig aber sie funktioniert, macht keine Probleme und soll nie geändert werden. Ja sieht beschissen aus, ist aber egal.

Am 9.2.2024 um 15:51 schrieb CodeScout:

Ich stelle diese Frage, weil ich oft erlebt habe, wie wir als Entwickler stundenlang über eine perfekte Lösung nachdenken, nur um dann festzustellen, dass sie an den Anforderungen der Stakeholder vorbeigearbeitet haben.

Das ist wohl eher ein Kommunikationsproblem. Leider weiß selbst der Kunde häufig nicht, was er eigentlich will und selbst wenn er es wüsste, spricht er eine andere Sprache, kann es ggf. nicht ausdrücken oder lässt einen Teil weg, weil er denkt, dass ist doch normal für diese Art von Software. Der lebt auch in einer gewissen Bubble.

Gerade wenn die Anforderungen nicht so klar sind, sich das Projekt offensichtlich noch entwickelt usw. ist es auch schwer eine gute Lösung zu erstellen und da die richtigen Generalisierungen rein zu bringen, wenn nicht unmöglich. Ich glaube da macht man es sich mit einer einfachen schmutzigen Lösung deutlich einfacher als zu probieren für alles eine perfekte Abstraktion zu finden, ohne das Problem zu verstehen. Das funktioniert einfach nicht und sorgt für noch viel mehr Probleme.

Denke mal Rest ist dann Erfahrung des Entwicklers unterscheiden zu können was ordentlich muss, was nicht. Was sich ändert, was nicht, ob man das voneinander trennen kann usw. Klar eine Glaskugel hat keiner. Und man muss natürlich auch damit leben können. Gibt durchaus Leute, die schreiben Software für sich, die wollen daraus was Größeres machen, als es ist.