Warum ist Software so schlecht?
-
dochKinderschuhe schrieb:
Wie lange werden Häuser gebaut?
wenn wir holzhütten und pyramiden nicht dazu zählen, was wir so machen sollten, da wir sonst die mathematik der softwareentwicklung andichten könnten, meint wikipedia:
Als Steinhaus wird primär eine menschliche Behausung aus dem Baumaterial „Stein“ bezeichnet. In Mitteleuropa war bis weit in die Neuzeit hinein das typische Haus auch in Städten aus Holz erbaut.
Die Neuzeit ist dem gängigen geschichtlichen Gliederungsschema zufolge nach Altertum und Mittelalter die dritte der historischen Großepochen Europas und reicht bis in die Gegenwart.
In der Geschichtswissenschaft wird als Beginn der Neuzeit die Wende vom 15. zum 16. Jahrhundert angesetzt
-
Warum sollte wir hier was weglassen und dort nicht? Das ist unlogisch.
-
Der Unterschied zwischen der Softwareentwicklung und anderen Ingenieursdisziplinen besteht doch auch vorallem darin, dass Software in aller Regel individuell ist, d.h. genau so ein Program gab es noch nicht, zumindest nicht vom selben Entwickler. Ein neues Auto dagegen ist eine iterative Verbesserung gegenüber dem Vorgängermodell und keine völlig neue Kontruktion für einen neueartigen Einsatzzweck.
Und wenn andere Ingenieursdisziplinen mal etwas halbwegs neues leisten müssen geht das ja auch oft genug in die Hose, siehe diverse aktuelle Großbauprojekte, bei denen nicht nur 08/15 Architektur gefragt ist
-
Voll der Thread. Kann man das überhaupt so sagen, dass Software schlecht ist?
Warum haben wir Schluckauf?
(Und sind wir deswegen schlechte Menschen?)Mal angenommen:
Ist: der Weg in den Wahnsinn
Soll: ??
Wo sind die Ansätze? (aus der Wissenschaft?)
Bei der Hardware sehe ich was: Risc, Java in Hardware
Naja, keine Optimallösung.
-
maximAL schrieb:
Der Unterschied zwischen der Softwareentwicklung und anderen Ingenieursdisziplinen besteht doch auch vorallem darin, dass Software in aller Regel individuell ist, d.h. genau so ein Program gab es noch nicht, zumindest nicht vom selben Entwickler. Ein neues Auto dagegen ist eine iterative Verbesserung gegenüber dem Vorgängermodell und keine völlig neue Konstruktion für einen neueartigen Einsatzzweck.
Und wenn andere Ingenieursdisziplinen mal etwas halbwegs neues leisten müssen geht das ja auch oft genug in die Hose, siehe diverse aktuelle Großbauprojekte, bei denen nicht nur 08/15 Architektur gefragt istDas ist doch zu 99% Unsinn, er werden doch immer wieder dieselben Algorithmen und Datenstrukturen genommen und auf sehr ähnliche GUI-Frameworks zugegriffen. Soviel neues ist da von Programm zu Programm nicht wirklich bei. Datenbanken sind schon lange durch SQL ziemlich standardisiert.
Das Problem sind fehlende Standards die für alle 0815 Software(Ego-Shooter, Buchhaltung, Verwaltung, Auswertung etc., Bildaufbereitung), wo man keine Ahnung Eingabemaske hat, die validiert, eine Datenbankabfrage bastelt und irgendwie wieder was davon ausgibt in Tabellen, Grafik, andere Masken etc.. Da sind zu 95% immer wieder dieselben Abläufe.
Kein Arsch setzt sich hin und legt mal STandard für die wirklichen STandards fest, alles andere muss gefrickelt werden klar. Aber nur Zusammfrickeln wie es fast alle tun ist doch echt Pfusch.
-
Gibt es hier eine Firma die es richtig macht?
Also der Kunde zahlt keinen überteuerten Preis und bekommt dafür erstklassige, wartbare und dokumentierte Software ohne große Fehler sowohl im Design als auch in der Implementierung?
-
malsogesagt schrieb:
Das ist doch zu 99% Unsinn, er werden doch immer wieder dieselben Algorithmen und Datenstrukturen genommen und auf sehr ähnliche GUI-Frameworks zugegriffen. Soviel neues ist da von Programm zu Programm nicht wirklich bei. Datenbanken sind schon lange durch SQL ziemlich standardisiert.
Bekannte Algorithmen und Datenstrukturen sowie Bibliotheken entsprechen letztendlich auch nur fertigen Einzelteilen von Zulieferern in anderen Bereichen.
Aber nur, weil du prinzipiell fast alle Teile für ein Auto fertig kaufen kannst, ist es noch lange nicht trivial eines von Grund auf zu entwerfen. Warum glaubst du, haben es neue Autohersteller aus Asien (heute China, davor Korea, davor Japan) erstmal sehr schwer und brauchen Jahrzehnte um auf das Niveau von etablierten Herstellern zu kommen? Die essentiellen Teile können die prinzipiell auch alle von den selben Zulieferern kaufen. Aber die nötige Erfahrung daraus ein gutes Auto zu bauen kommt eben nicht von heut auf morgen.
-
maximAL schrieb:
Und wenn andere Ingenieursdisziplinen mal etwas halbwegs neues leisten müssen geht das ja auch oft genug in die Hose, siehe diverse aktuelle Großbauprojekte, bei denen nicht nur 08/15 Architektur gefragt ist
Da stimme ich nicht zu. Ich habe bei einigen Fabrikprojekten mitgewirkt, wo auch die Bauleute dabei waren, und es gibt da schon ein Muster:
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.
-
Ich denke dass Autos eine weit bessere Qualität als die heutige Software haben, auch wenn man der Software viele Jahre zum reifen gegeben hat.
Da ist soooooo ein Graben zwischen der Arbeit von Informatikern und Ingenieuren. Ich kenne kaum ein Gebiet auf dem der Kunde mehr Müll bekommt. Das Studium ist doch für einen Softwareentwickler fast völlig von Arsch, denn zu diesem Thema lernt er so gut wie nix.
Ein Architekt kann sich ausrechnen wann eine Konstruktion kritisch wird, ein Informatiker zuckt da nur mit den Schultern weil es dafür gar keine Modelle gibt.
-
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. 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.
Es kommt noch dazu, dass das dritte Pissoir das Haus nicht zum Einsturz bringen kann und es niemals notwendig ist, das Fundament neu zu gießen nur damit drei Leute im zehnten Stock gleichzeitig pinkeln können.
Bei Software können augenscheinlich kleine Änderungen verherende Auswirkungen haben.
-
3141 schrieb:
Da ist soooooo ein Graben zwischen der Arbeit von Informatikern und Ingenieuren. Ich kenne kaum ein Gebiet auf dem der Kunde mehr Müll bekommt. Das Studium ist doch für einen Softwareentwickler fast völlig von Arsch, denn zu diesem Thema lernt er so gut wie nix.
Zustimmung.
Ich wäre heute kein schlechterer Software-Entwickler wenn ich Mathe oder Physik studiert hätte statt Informatik.
-
3141 schrieb:
Ein Architekt kann sich ausrechnen wann eine Konstruktion kritisch wird, ein Informatiker zuckt da nur mit den Schultern weil es dafür gar keine Modelle gibt.
Software hat da auch immer noch viel Narrenfreiheit - die Erwartungshaltung, daß am Tag X auch wirklich was fertig ist, ist immer noch nicht so richtig gegeben.
-
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.
