Warum ist Software so schlecht?
-
Marc++us schrieb:
... - diese Kosten können aus Geld, Zeit oder Qualität bestehen.
dazu fällt mir das Magische Dreieck ein... Demnach gibt es optimale Qualität nur bei unendlicher Zeit und enormen Kosten.
-
@dgvfdgfhfghf
Kann es sein dass du dich momentan mit einem, vielleicht etwas arroganten, Entwickler von der Uni herumschlagen musst, welcher nur Java gelernt hat, aber kein C++ und nun meint sein Code wäre besser ?Stupse ihn doch mal auf seine Fehler. Ähh, warum funktioniert delete xy().getT() nicht ? Oder warum meckert valgrind, cvtdbg.h bei deinem Code ? Oder warum verursacht &xy().getT() = xy() einen Fehler ?
Mir fällt halt nur auf, dass viele Informatiker recht verschwenderisch mit der Rechenleistung umgehen.
Ich kenne da Entwickler, welche sich so einiges leisten. Da existiert nur eine C Datei mit mehreren tausend Zeilen Code, in denen keine Funktionen mit Parametern erkennbar sind, alles über globale Variablen funktioniert, Funktionalitäten von Registry Zugriff, Datei Handling, GUI Zugriff, Hardware Zugriff in dieser Datei gepackt sind. Ein Klassiker, wenn auch nicht so schlimm, ist die Beschränkung der Größe eines Strings, s.d. bei doch größeren Strings das Programm abstürzt.
Oder ein C++ Projekt, in denen über 500 Klassen per Codegenerator erzeugt wurde, bei denen Klassennamen abstruse trugen und die Funktionimplementationen nicht lesbar, wartbar waren weil die Funktion mittels 10-100 Parameter etwas ausrechnete und dabei ein Array unbekannter Größe verwendete welches auch noch mittels eines ArrayInidzes - Array addressiert wurde. Doku fehlte komplett, ebenso wie der Codegenerator.
Einige verwechseln Programmierung mit Kryptographie.
Für mich bedeutet Design an morgen zu denken, daran zu denken dass sich evt. der Entwickler ändert, daran zu denken dass man auch dem Entwickler es leicht machen sollte seinen eigenen Code zu benutzen, daran zu denken dass sich gewisse Dinge im Code auch ändern könnte, ...
-
Eigendlich jedes größere Softwareprojekt wächst mit der Zeit. Und bei allen Projekten, an denen ich mitgearbeitet habe, ändern sich während der Entwicklung Anforderungen. Egal ob von Kunden- oder Projektmanagement-Seite. Als Programmierer versucht man ja seinen Code so abstrakt wie möglich zu halten und mögliche Änderungen vorauszusehen/einzuplanen.
Das funktioniert alles bis zu einem bestimmten Punkt sehr gut. Irgendwann lassen sich aber Änderungen oder komplett neue Anforderungen nicht mehr sauber in die aktuelle Projektstruktur einbauen.
Also Refactoring! Im Idealfall - Leider musste ich oft genug erlegen, dass es vom Projektmanagement dann hieß: "Nein, das zahlt der Kunde nicht. Wir machen das jetzt dreckig und hacken das schnell rein. Später können wir das das optimieren." Leider kommt dieses Später oft nicht und so schleppt man diese Altlasten und Hacks mit jeder neuen Version mit.
Ich glaube genau solche Probleme machen Software schlecht.
-
__Herrmann schrieb:
Als Programmierer versucht man ja seinen Code so abstrakt wie möglich zu halten und mögliche Änderungen vorauszusehen/einzuplanen.
Es gibt Extreme in der Abstraktion Code schlechter macht. Die Schwierigkeit ist einen Weg zu finden der einerseits Erweiterung erlaubt, anderseits aber den Overhead nicht ins Extrem steigert.
__Herrmann schrieb:
Also Refactoring! Im Idealfall - Leider musste ich oft genug erlegen, dass es vom Projektmanagement dann hieß: "Nein, das zahlt der Kunde nicht. Wir machen das jetzt dreckig und hacken das schnell rein. Später können wir das das optimieren." Leider kommt dieses Später oft nicht und so schleppt man diese Altlasten und Hacks mit jeder neuen Version mit.
Das wiederum kann ich so nur Unterschreiben. Und zwar nicht als "oft genug" sondern eher als "fast immer". Ich habe von 4 (eigentlich 3) Firmen nur eine erlebt in der Refactoring erwünscht ist, und bei der der Chef sich in der Regel festen Stichtagen verweigert (oder sie so setzt, das er eine sehr hohe Sicherheit hat).
__Herrmann schrieb:
Ich glaube genau solche Probleme machen Software schlecht.
Ich glaube das liegt auch daran das bei Software wesentlich extremere Änderungen zur Entwicklungszeit kommen können, wie z.B. im Bau. Man geht im Bau nicht davon aus das aus einer einfachen Holzhütte, nach und nach ein verchromter Wolkenkratzer wird. Bei Softwareprojekten ist dies nicht so unüblich wie man denkt.
Beispiel: Kunde will Minimalsoftware, ist auch nicht einmal bereit für Handbuch, Test etc. Geld in die Hand zu nehmen (Selbst wenn wir natürlich trotzdem in gewissen Rahmen getestet haben). Diese Software war von vorne herein niemals auf Erweiterbarkeit etc. ausgelegt, weil es nur schnell und billig erfolgen sollte...
...Einige Zeit später: Ähnliches (wenn auch komplexeres) Programm von einem Kunden gewünscht, unsere Firma meinte wir haben da doch noch etwas das wir als Grundlage nehmen könnten...
Und bei solcher Software rentiert sich selbst Refactoring nicht unbedingt (Neuschreiben kann in diesem Fall tatsächlich merklich billiger sein).
In einer Firma war ich etwa 90% der Zeit an der Fehlerkorrektur (und in der Regel waren das nicht meine Fehler, sondern die durch das schlechte Design verursachten). Da wurde so häufig das Design geändert und keinerlei Refactoring betrieben, das es der oben angedeutete Wolkenkratzer war, der im Kern einen morschen und zerfressenen Holzrumpf hatte. Ich habe noch nie so wütende Kunden erlebt, wie die, die diese Software auch einsetzen mussten.
-
Marc++us schrieb:
Glaube bitte nicht, daß der Kundenwunsch nach einer anderen Form des Buttons so ungewöhnlich und softwarespezifisch wäre... beim Bau kommt einer um die Ecke und will plötzlich 3 Pissoirs statt 2. Dann reißt man die Armaturen teilweise raus und macht die neu.
Das sind ja noch reichlich kleine Beispiele. Kleinkram wie ein paar Buttons oder das Layout sind ja auch nicht das Problem bei der Softwareentwicklung, sondern vielmehr, dass man am Anfang häufig gar nicht genau weiss wo man hinwill und sich das auch in langen Kundengesprächen nicht hinreichend klären lässt. Ich weiss ja nicht, ob man eine Fabrik so baut - erstmal eine Halle in die Landschaft setzen und den Kunden durchlaufen lassen, der sich dann überlegt, dass das Dach zu niedrig ist.
Aber es ist sicher auch ein Wahrnehmumgsproblem beim Kunden. Software kann man eben nicht anfassen, da scheint es weniger aufwändig zu sein, mal eben fertiges wegzuwerfen. Etwas fertig gebautes wieder abzureissen ist da schon eine andere Sache, auch wenn am Ende beides gleich viel Geld kostet.
-
maximAL schrieb:
Ich weiss ja nicht, ob man eine Fabrik so baut - erstmal eine Halle in die Landschaft setzen und den Kunden durchlaufen lassen, der sich dann überlegt, dass das Dach zu niedrig ist.
In den Typischen Projektverläufen wird es eher so sein, das nicht nur das Dach zu niedrig ist, sondern die Halle das ganz falsche Format hat (Beispiel aus der Praxis: Kunde sagt pro Tag müssen maximal 10 Rechnungen mit maximal um 100 Positionen [wenige Kilobyte] verarbeitet [Aufgeteilt nach komplexen Schlüsseln auf verschiedenste Kostenstellen] werden - Dann auf einmal kommen mehrere Rechnungen im 3 Stelligen Megabytebereich rein.
Getestet wurde das System mit den Vorgaben (Pro Tag wenige Kilobyte Rechnungsdaten). Ein Tester hatte zwar mal einen Lasttest gemacht, dort wurde aber abgewunken, das die niemals so kommen wird (muss ich wissen, ich war der Tester ;p).
Das ist so als wenn der Kunde sagt er brauch eine kleine Fabrikhalle mit 1000m^3 Abstellfläche, in der Realität aber täglich alleine die 10.000 fache Fläche benötigt wird. Ganz zu schweigen davon, das der Kunde dafür noch wesentlich mehr Infrastruktur wie ein Güterbahnhof etc. benötigt - die die Anfahrtswege nicht für so einen Durchsatz ausgelegt waren, und vielleicht auch nur ein Werktor zur Warenannahme eingeplant war.
Dem Kunden helfen auch Diagramme nicht viel. Ebenso nützt ein Prototyp nichts, wenn die, die realistisch mit der Software arbeiten müssen, diese erst am Ende des Prozesses sehen. Das ist leider ebenso in den meisten Fällen Realität.
-
Ich glaube ein Problem warum Software sich schlecht entwickelt ist, das jeder reinreden will und glaubt seine Änderungswünsche müssten doch ganz schnell umsetzbar sein, er hat schließlich auch schon mal was programmiert und sein Sohn kann das auch.
Der Fehler den die Softwareentwickler oder deren Chefs machen, sind die fehlenden Eier in der Hose. Sie müssen ziemlich exakt sagen können was was kostet und um wie viel es teurer wird wenn sich was ändert.
Was uns aber wieder zu einem Problem der Softwareentwicklung führt, so gut wie keine kann sagen wie lange er wirklich braucht für Planung, Ausführung, Dokumentation, Tests. Auch hier gibt es wieder keine Standards an denen man sich richten könnte.
Softwareentwicklung ist wirklich was für jemanden den es nix aus macht immer der Arsch zu sein, der zu lange braucht und sich verschätzt hat. Lobe wie in anderen Branchen üblich sind wohl eher Mangelware, genau wie eine angemessene Bezahlung dafür dass sich IT alle paar Monate ändert und keine wirklich so genau weiß wo es hingeht.
IT ist ein einzelnes Chaos, mit viel Stress, wenig Anerkennung und wenig Geld.
-
Bill Gates und Steve Ballmer sowie Steve Jobs verdienen/verdieten damit aber viel Geld.^^
mhhm oder auch nicht.^^ Ich glaub kaum das die noch selbst an der Software rumgewerkelt haben als die Unternehmen liefen da durften die sich dann bestimmt mit BWL ausseinander setzen.
-
Ist ja toll, wenn man alles auf die Kunden schieben kann, aber die konkret angesprochene Software hier (siehe Ursprungsposting und das von Marc++us) ist keine Individualsoftware und trotzdem scheiße.
Das Thema ist schon ein bisschen komplexer. Vielleicht muss man sich mal gute Software(existiert sowas?) und die Umgebungen, in denen sie entsteht, genau anschauen. Ich vermute allerdings, dass es kein Stück Software gibt, bei dem sich sowohl Benutzer als auch Entwickler einig sind, dass es gut und nachahmenswert ist. Oder?
-
Oo schrieb:
Bill Gates und Steve Ballmer sowie Steve Jobs verdienen/verdieten damit aber viel Geld.^^
hast jetzt ein paar aus der champions league rausgepickt? gut gemacht
eig. sieht man daran schon wie schwer es ist, es werden ja immer die gleichen namen genannt. bei 50-100 hat man auch nicht die riesen auswahl
-
hallo
bei software, die schon unzähligen user genutzt wird (windows, firefox,...) wird es immer dinge geben, die den einen nerven und der andere gut findet. auf der liste sind da auch viele dinge dabei. für den einen ist es ein feature, für den anderen ein bug.
chrische
-
__Herrmann schrieb:
Also Refactoring! Im Idealfall - Leider musste ich oft genug erlegen, dass es vom Projektmanagement dann hieß: "Nein, das zahlt der Kunde nicht. Wir machen das jetzt dreckig und hacken das schnell rein. Später können wir das das optimieren."
Das ist bei uns auch so und das finde ich gut. Klar, aus Entwicklersicht ist frickeliger Code grausiger Horror, aber es macht Zeit-/Nutzenmäßig eben selten Sinn zu refactorn. Gibt man einem Entwickler genug Freiheit und Zeit, wird durchgehend ge-refactor-t, das bringt aber keinen weiter.
Natürlich gibt es irgendwann den Punkt, wo sich die Geschichte umdreht und es langfristig besser ist, wenn man vor den kommenden Features den vorhandenen Code optimiert/reduziert. Dieser Punkt wird von Entwicklern aber meiner Erfahrung nach völlig falsch eingeschätzt.
-
fdfdg schrieb:
Dieser Punkt wird von Entwicklern aber meiner Erfahrung nach völlig falsch eingeschätzt.
Du willst sagen, daß die voraussichtliche Lebenszeit der meisten Anwendungen diesen Punkt nicht erreicht?
-
chrische5 schrieb:
bei software, die schon unzähligen user genutzt wird (windows, firefox,...) wird es immer dinge geben, die den einen nerven und der andere gut findet. auf der liste sind da auch viele dinge dabei. für den einen ist es ein feature, für den anderen ein bug.
Stimmt, mit der Eingangsliste habe ich aus diesem Grund auch bei einigen Punkten Probleme. Es ist nicht möglich etwas so perfekt herzustellen, das niemand etwas daran auszusetzen hat (das gilt auch jenseits der Softwareentwicklung). Das Ergebnis sollte den Kunden passen, und wenn der Kundenbereich groß ist, sollte es zumindest 80-90% zusagen (80:20 oder 90:10 Regel oder wie die auch immer heißen mag).
Ich widerspreche auch der pauschalen initialen Aussage das Software "schlecht" ist. Wenn ich Software wirklich als schlecht ansehe, nutze ich sie nicht. Es mag Bereiche geben die mir nicht gefallen, aber die Frage ist wie relevant diese Bereiche in meinem Anwendungsfall sind.
Was macht gute Software eigentlich aus? Hier wird jeder etwas anderes sagen, und tatsächlich werden sich wohl die meisten irren was für den Kunden wichtig ist. Ich habe als ich hier angefangen habe eine Anwendung vorgefunden, die so richtig altbacken herkam. Nicht etwa das wirklich von vielen gewünschte Feature xyz ist den Kunden positiv aufgefallen, sondern die optischen Überarbeitungen des Programms.
Ich würde sagen eine Software ist dann gut, wenn der überwiegende Teil der Kundengespräche ruhig und sachlich ablaufen und sich am Telefon positiv äußern, trotz gelegentlicher Fehler. Fehlerfrei ist auch jenseits der Software unmöglich, die Frage ist aber wie auf Fehler reagiert wird, und wie schwer diese sind.
-
audacia schrieb:
fdfdg schrieb:
Dieser Punkt wird von Entwicklern aber meiner Erfahrung nach völlig falsch eingeschätzt.
Du willst sagen, daß die voraussichtliche Lebenszeit der meisten Anwendungen diesen Punkt nicht erreicht?
Nein, ich will sagen, dass man als Entwickler zu oft dazu neigt, Code aufzuräumen. Es gibt genug Szenarien, wo es einfach nicht nötig ist. Sei es, dass es ein dickes, unordentliches 1-Datei-Skript ist, das nur einmal im halben Jahr minimal angepasst wird, oder ein dass es ein unwichtiger Teil der Anwendung ist. Lebenszeit kann auch ein Argument sein, wenn ein Modul oder gar die ganze Software bald überflüssig werden.
Refactoring ist ja nicht nur zeitintensiv, sondern auch fehlerträchtig - und das Resultat gefällt einem im schlimmsten Fall ein halbes Jahr später auch nicht mehr.
-
fdfdg schrieb:
Nein, ich will sagen, dass man als Entwickler zu oft dazu neigt, Code aufzuräumen. Es gibt genug Szenarien, wo es einfach nicht nötig ist...
In der Regel hat man als Entwickler doch häufig gar nicht die Gelegenheit zum aufräumen. Und es gibt viele Szenarien bei denen es sich rächt. Gerade wenn man mal die "Projektschiene" verlässt und langlebige Software betrachtet. Wenn man schlechten Code immer weiter mit sich herum schleppt, so wird es in der Regel immer schwerer diesen auszubessern.
fdfdg schrieb:
Refactoring ist ja nicht nur zeitintensiv, sondern auch fehlerträchtig...
Refactoring ist in erster Linie Umstrukturierung bei gleichzeitiger Beibehaltung der Originalfunktionalität. In sofern darf dies eigentlich vom Prinzip her nicht sonderlich fehlerträchtig sein, sofern man es etappenweise durchführt und testet.
Und wenn du einmal eine langlebige (10+ Jahre) Programmentwicklung mitgemacht hast die auch über eine gewisse Komplexität verfügt wirst du deine Aussagen recht schnell überdenken.
Selbst wenn einem beim Refactoring mal Fehler unterlaufen können, ist die Fehlerquelle bei schlechten Code auf die Dauer wesentlich höher. Sobald du einmal den Fall erlebt hast das 90% deiner Tätigkeit nur noch das ständige Flicken an solch Software ist, weißt du wovon ich rede.
Sicher kann man alles übertreiben, aber untertreiben ist ebenso möglich.
-
Bashar schrieb:
Das Thema ist schon ein bisschen komplexer. Vielleicht muss man sich mal gute Software(existiert sowas?) und die Umgebungen, in denen sie entsteht, genau anschauen. Ich vermute allerdings, dass es kein Stück Software gibt, bei dem sich sowohl Benutzer als auch Entwickler einig sind, dass es gut und nachahmenswert ist. Oder?
Rein erfahrungsgemäß werden hervorragende Programme dort geschrieben, wo ein gutes Hardwarverständnis da ist und die Liebe zur Sache. Das ist einfach oft so, siehe Intelcompiler, Cuda, Programmiersprache C. Also Hardwareentwickler, Hardwareprogrammierer, Visionen, Know How. Das konnte man vor allem auch bei Synthesizer"Software" sehen bzw. eher hören. Werksoundbibliotheken waren meist überdurchschnittlich gut. Von da an recht lineare (?) Decline.
Von der Idee, dass der Kunde der "Schuldige" ist, würde ich auch lieber Abstand nehmen. Dann doch eher die Kommunikation als Angriffspunkt. Hm...war die Kommunikation bei Diablo 3 schlecht? Oder bei Sacred 1? (viele Spielspaß mindernde Faktoren - sind die den Programmieren nicht aufgefallen?)
Haskell (auch Lisp, Modula 3)kommt nicht (selber) bis Windows und Gui, das haben sich Typen ohne Hardwareverständnis ausgedacht. Wie man in der Praxis sieht, kommt man damit nicht weit. Windows selbst, also nur Abstrakt, ohne Dos war auch ein Witz, und mit Directx noch instabiler als sowieso schon. Das (mit Directx) hat sich erst mit der Zeit gebessert, vorher Prädikat "Katastrophal".
Bei Sun dagegen hatte man ein Hardwareverständnis, und deswegen läuft Java auch auf dem Handy.Auch die Typen, die Lisp und Basic mit Dialekten in den Wahnsinn getrieben haben, hatten kein Hardwareverständnis.
-
nachtfeuer schrieb:
Rein erfahrungsgemäß werden hervorragende Programme dort geschrieben, wo ein gutes Hardwarverständnis da ist und die Liebe zur Sache.
So formuliert würde ich deine Aussage unterschreiben: "Rein erfahrungsgemäß werden hervorragende Programme dort geschrieben, wo man mit Liebe (vielleicht besser: mit Herzen) an die Arbeit geht."
Du schränkst dies auf eine Personengruppe ein, in der genauso viel Gutes wie Schlechte wie Anderswo in der Entwicklung passiert. Die besten Programme waren immer die wo man nicht unter Dauerdruck, mit Herzen an die Arbeit gegangen ist und Selbst hinter der Sache gestanden hat.
Frust und Dauerdruck erhöht die Fehlerrate beachtlich, ebenso wenn man nicht hinter einem Projekt steht, sondern dies nur lieblos abarbeitet.
-
Marc++us schrieb:
Projekte gehen schief, weil der Kunde etwas ausschreibt, von dem er keine genaue Vorstellung hat aber viele Wünsche, die nicht so explizit in der Spezifikation stehen sondern nur im Kopf. Der Lieferant gibt das niedrigst kalkulierteste Angebot ab um den Auftrag zu bekommen, und legt alle Wünsche restriktiv aus, andernfalls wird er nicht billig. Im Laufe des Projekts erkennt der Kunde, daß seinen Wünsche nicht 1:1 kommen, und er will diese trotzdem, wodurch es dann Change Requests mit Kostensteigerungen und zeitlichen Verzögerungen ohne Ende gibt.
Glaube bitte nicht, daß der Kundenwunsch nach einer anderen Form des Buttons so ungewöhnlich und softwarespezifisch wäre... beim Bau kommt einer um die Ecke und will plötzlich 3 Pissoirs statt 2. Dann reißt man die Armaturen teilweise raus und macht die neu. Software ist natürlich eine Spur schlimmer, weil man sich da bildlich gesprochen auch fliegende Pissoirs wünschen darf, das macht man beim Bau nicht. Dafür wird bei Software oftmals vom Lieferanten oder Programmierer mangels Professionalität nicht klargemacht, daß eine Änderung in irgendeiner Form zu "Kosten" führt - diese Kosten können aus Geld, Zeit oder Qualität bestehen. Viele Softwarefirmen machen bei den Änderungen beliebig lange mit, solange es noch Budget gibt, und verweigern die Mitarbeit erst bei "Ende vom Geld". Das ist natürlich zu spät.
Da sind die klassischen Ingenieure schon weiter, wenn jemand beim Bau eine andere Fliesenfarbe haben will, kommt sofort die Rechnung mit Angabe des Zeitverzugs. Die Autoleute arbeiten da ähnlich.
Also doch ein Management Problem.
-
Eigentlich ist Software im Vergleich mit anderen Sachen doch ziemlich gut. So gut wie fast jedes Programm hält mehr an Fehlbedingungen aus als Hardware (nicht nur elektronische). Wenn man bei elektronischen Bauteilen eine zu große Spannung anlegt, sagt keiner das es ein Bug ist, wenn das Bauteil danach nicht mehr geht. Bei SW erwartet man, dass sie sowas abfängt. Wenn man bei einem Auto ständig mit Vollgas fährt und die Kupplung schleifen lässt, sagt auch keiner, dass das ein Bug ist, wenn das Auto kaputt geht, bei SW erwartet man, dass jeder DAU alles damit machen kann ohne das was passiert.
