Warum ist Software so schlecht?
-
dgvfdgfhfghf schrieb:
...
Du redest, wie ich mir bei der Erwähnung von ETechnikern schon fast dachte von embedded Systemen. Und ja, die muss man ganz Anders programmieren. Ich verdiene zwar mein Geld mit Software, würde aber niemals behaupten das ich embedded Systeme programmieren könnte - 2 völlig verschiedene Welten. In der Entwicklung großer Unternehmenssoftware wiederum ist Abstraktion und saubere Trennung widerum bei mehreren Millionen Codezeilen sehr wichtig.
P.S. Ungeachtet von dem schlechten Code im Beispiel.
-
Fakt ist: Die IT steckt noch in den Kinderschuhen, wie die Chirurgie früher mit ihren unsterilen Knochensägen, das konnte man auch studieren und stolz drauf sein, aber der große Chirurg war man deswegen nicht. Genauso gibt es heute nicht einen guten Softwareentwickler.
In vielleicht fünfzig oder hundert Jahren wird man sogar in der Ausbildung über die Methoden mit recht sich halbtot lachen und nur mit den Kopf schütteln. Aber natürlich auch sagen, die wussten es halt nicht besser. Bis ein Herr X in die Softwarewelt gekommen ist und sie revolutioniert hat, weil er anders an die Sache ran gegangen ist. Darauf hin wurde fast das gesamte Studium umgestellt und vor allem getrennt. Einmal in den selten gebrauchten aber hochspezialisierten Softwarearchitekten und dann noch den auch zur Leitung gebrauchten Softwareproduzenten. Der Informatiker war wirklich nur noch für die mathematischen Modelle hinter der Soft- und Hardware zuständig. Dann gab es noch das Arbeitstier, den Programmierer für den es "nur" eine 4 Jährige Ausbildung bedarf. Für alle Stufen den Softwareentwicklung gibt es mindestens einen genormten Standard, den wirklich jeder aus der Branche kennt und sofort anwenden kann. Alle anderen experimentiellen Wege werde subventioniert um seine Möglichkeiten zu erschließen und dem Kunden das Produkt billiger zu verkaufen. Hat sich etwas über Jahre etabliert wird es in den Standard aufgenommen.
...
-
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.
