Warum ist Software so schlecht?

[dgvfdgfhfghf]

Bitte ein Bit schrieb:

Für ein wenig OOP-Design und dessen Implementierung braucht man bei 90% der ganzen Softwareentwicklung(Web eingeschlossen) keinen Informatiker, sondern Leute die schnell loslegen auch wenn das Produkt dann Schrott ist. Solange die Kunden das bezahlen und nicht viel mehr, wird sich daran auch nix ändern.

Was ist das jetzt ?

Ein Flamewar zum Thema wozu braucht man Dipl./Bach/Master Informatik ?
Ein Thread zum Thema, wie kotze ich Code möglichst perfekt hin ?
Ein Thread zum Thema "Never Change a Programming Style" ?

So mancher Code, von so manchem Fachfremden, welche ich gesehen habe, war meines Erachtens buggy hoch zehn. Im wahrsten Sinne des Wortes: In Code gegossene Algorithmen, C Programmierung auf Assembler Niveau, Code der Form Weiterentwicklung unerwünscht. Alles Design Fehler.

Apropo, wir reden noch wenig zum Thema Fehler sondern eher von Mängel in dem Bedienkonzept.

Hab das auch schon anders erlebt: Nämlich dass Software viel zu abstrakt ist, wenn sich reine Informatiker austoben.
Design Patterns machen ja Sinn und helfen SW übersichtlich zu gestalten. Aber wenn dann für jeden Scheiß eine abstrakte Basisklasse, Polymorphismus, Facaden, Factories und ähnliches verwendet werden, dann hat derjenige vielleicht Ahnung von SW-Entwicklung, aber sicher nicht von der Funktionsweise von Computern.
Habe schon oft erlebt, dass Elektrotechniker mit C++ viel robusteren und schnelleren Code schreiben als Informatiker. Liegt vielleicht auch daran, dass man beim ET Studium mit ASM und C schwache Computer (z.B. µController) programmiert, während sich Informatiker mit Java austoben dürfen.

Und zum eigentlichen Thema: SW ist ein komplexes Thema, auch wenn man ausgiebig testet werden sich im real-life Einsatz immer wieder Fehler ergeben. Vielleicht fehlt einigen hier auch die Erfahrung, wie es in der kommerziellen SW-Entwicklung zugeht. Da hat man meist nicht so viel Zeit wie man sich privat nimmt, wenn man ein Projekt angeht. Außerdem: Die meisten Privat Projekte werden nur von den Entwicklern selbst verwendet, und müssen sich nie einem DAU Ansturm stellen. Man hält es nicht für möglich, welche Fehlbedienungen möglich sind.

[asc]

dgvfdgfhfghf schrieb:

Design Patterns machen ja Sinn und helfen SW übersichtlich zu gestalten. Aber wenn dann für jeden Scheiß eine abstrakte Basisklasse, Polymorphismus, Facaden, Factories und ähnliches verwendet werden, dann hat derjenige vielleicht Ahnung von SW-Entwicklung, aber sicher nicht von der Funktionsweise von Computern.

Je nach Anforderungen können Abstraktionsschichten durchaus nötig sein (z.B. bei Test Driven Design) und die Qualität erhöhen. Das es immer eine Kehrseite (potentielles Overengineering) gibt ist auch klar.

dgvfdgfhfghf schrieb:

Habe schon oft erlebt, dass Elektrotechniker mit C++ viel robusteren und schnelleren Code schreiben als Informatiker.

Das habe ich in der Praxis noch nicht erlebt, aber ich muss auch gestehen das ich nur wenige Elektrotechniker in der C++ Entwicklung in meinem Bereich kennen gelernt habe (und diejenigen welchen hatten meist ihren Code "hingerotzt" - jedenfalls war er nicht wirklich wartbar und fehlerfrei).

dgvfdgfhfghf schrieb:

Liegt vielleicht auch daran, dass man beim ET Studium mit ASM und C schwache Computer (z.B. µController) programmiert, während sich Informatiker mit Java austoben dürfen.

Liegt vielleicht auch daran das die Programme für Mikrocontroller auch wesentlich kleiner und überschaubarer sind. Ganz davon abgesehen das Informatiker nicht unbedingt Java lernen (Selbst heutzutage gibt es Hochschulen die z.B. C++ oder vergleichbares nehmen). Wobei Informatiker ohnehin nicht Programmiersprachen sondern eher Konzepte lernen.

dgvfdgfhfghf schrieb:

Und zum eigentlichen Thema: SW ist ein komplexes Thema, auch wenn man ausgiebig testet werden sich im real-life Einsatz immer wieder Fehler ergeben. Vielleicht fehlt einigen hier auch die Erfahrung, wie es in der kommerziellen SW-Entwicklung zugeht. Da hat man meist nicht so viel Zeit wie man sich privat nimmt, wenn man ein Projekt angeht.

Und du unterschätzt vielleicht, wie viele Poster hier auch beruflich in der Softwareentwicklung tätig sind.

[dgvfdgfhfghf]

Je nach Anforderungen können Abstraktionsschichten durchaus nötig sein (z.B. bei Test Driven Design) und die Qualität erhöhen. Das es immer eine Kehrseite (potentielles Overengineering) gibt ist auch klar.

Nur um mal ein Beispiel zu nennen: es geht um ein grundsätzlich flottes eingebettetes System, da muss man sich schon ganz nett austoben um das in die Knie zu zwingen.
Aber dann kommen da Leute von der Uni, die Informatik studiert haben, und sowas in der Art programmieren:

class xy
{
public:
T& getT()
{
if(m_T==0) throw new NullPtrException();

return *m_T;
}
...

private:
T* m_T;
};

Warum zum Teufel gibt man eine NullPointerException zurück? Wenn man schon die Innereien offenbart (Rückgabe per Ref), kann man doch gleich den Pointer zurückgeben.
Dann kommt da noch die Frage, warum man eine Exception mit new wirft?
Teilweise werden da ganz normale Betrisbzustände zurückgegeben, wo also ein Nullzeiger einfach nur anzeigt, dass irgendwas nicht gesetzt ist. Exception sollten ja dann doch eher für "Ausnahmen" im Programmablauf verwendet werden.
Und so weiter...
Und nein, die haben tatsächlich kein C gelernt, sondern nur Java! War normale Informatik, also nix da Wirtschaftsinformatik oder ähnliches!

Natürlich gibts auch Spitzeninformatiker, keine Frage. Mir fällt halt nur auf, dass viele Informatiker recht verschwenderisch mit der Rechenleistung umgehen. Und das aber recht arrogant damit verteidigen, dass so das Design "schöner" ist, dass man das eben so macht, dass das wartungsfreundlicher ist, ...
Was bringt dem Kunden ein intern "schönes" System, wenn er merkt, wie träge das System auf seine Eingaben reagiert?

[asc]

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.

[BitGeschichte]

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.

...

[oO]

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

[oO]

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

[dochKinderschuhe]

Wie lange werden Häuser gebaut?

[oO]

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

[dochKinderschuhe]

Warum sollte wir hier was weglassen und dort nicht? Das ist unlogisch.

[maximAL]

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

[nachtfeuer]

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.

[malsogesagt]

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 ist

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.

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.

[nachgefragt]

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?

[maximAL]

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.

[Marc++us]

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.

[3141]

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.

[Neunzehn]

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.

[Neunzehn]

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.

[Marc++us]

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.