Warum ist Software so schlecht?
-
BitGeschichte schrieb:
Fakt ist: Die IT steckt noch in den Kinderschuhen
naja, mit fast 80 sollte man schon mal langsam rausgewachsen sein.
BitGeschichte schrieb:
Genauso gibt es heute nicht einen guten Softwareentwickler.
kann ich nicht bestätigen. und ich bin mir auch fast sicher, dass sie in zukunft schlechter werden. was daran liegt, dass das feld größer und komplexer wird, wodurch man sich stärker spezialisieren muss was unweigerlich dazu führt, dass man nicht mehr alles wissen kann. was in folge dazu führt, das nach bestem wissen und gewissen angefertigte software immer an der ein oder anderen stelle den falschen alg. wählt.
bsp: früher hatt man einfach einen btree genommen und gut. heute gibts allein von dem teil schon wieder x variationen, und geleg. performt ein hash besser und bei kleinen durch ausnutzung des cache ein sortiertes array. WER SOLL DA NOCH DURCHBLICKEN? und das wird ja nicht mehr besser
-
und wenn wir ada lovelace als erste programmiererin zählen lassen, sind es schon fast 170 jahre. von kinderschuhen kann also langsam nicht mehr die rede sein
-
Wie lange werden Häuser gebaut?
-
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.
