Warum ist Software so schlecht?

Bitte ein Bit

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.

Bitte ein Bit schrieb:

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.

ach, ich hab auch schon überdesignte software gesehen! das ist imho fast noch schlimmer :p

Bitte ein Bit

ach, ich hab auch schon überdesignte software gesehen! das ist imho fast noch schlimmer :p

Da fällt man auch von einem Extrem ins nächste Extrem.

Außer ein paar Bib's (LOKI, MCA) habe ich aber keinere größeren Designbrocken gesehen.

Ich habe schon überdesignte Software gesehen. Ein Informatiker war da schuld dran, er hat von der Datenbank bis zur Software wirklich alles generalisiert. Keiner der drei neuen Mitarbeiter konnte noch erahnen wie die Software, geschweige denn die Datenbank, wirklich aufgebaut war oder funktioniert hat. Auch die ganze Doku und UML-Diagramme halfen da nur bedingt.

Er selbst sagte, er könne gar nicht mehr anders entwickeln und er würde sich freuen mal wieder einfach mal ein Problem ganz quick und dirty in ein paar Minuten runterprogrammieren zu können, weil manchmal einfach nix anderes vom Kunden erwünscht ist.

Er hat immer ewig für irgendeine Aufgabe gebraucht, weil alles bis ins Kleinste wohl überlegt werden musste. Er hat dann irgendwann auch "freiwillig" gekündigt, das passte einfach nicht in eine Softwarefirma die wirtschaftlich denken muss, sondern war eher was für die theoretische Informatik, also kurz für die Praxis unbrauchbar. Das zahlt kein Kunde.

Wie viel tolle Software(voller 55 Tricks 111 DesignPattern) ist denn nach Jahren dann doch den neuen Anforderungen gewachsen gewesen? Das Überdesign führt eher zum Einstellen des gesamten Projektes, wie es bei uns auch geschehen ist. Also, es wird noch betreut aber nicht mehr weiterentwickelt.

Es ist ja nich schlecht auf einiges zu achten, aber entweder haben Leute überhaupt keine Ahnung oder fangen mit einem Überdesign an, weil ja wirklich ALLES sich ändern könnte und flexibel gehalten werden muss. *Kopfschuss

Ein ganz früher Chef hat sogar seine komplette Software in reinem C unter Linux entwickelt, irgendwann Mitter der 90er damit angefangen.
Die Software lebt heute noch und er ist Millionär damit geworden, er stemmt das Projekt von Anfang an selbst und hat sich sogar seine eigene Datenbank programmiert und das ist auch ein Informatiker und nebenbei noch Mathematiker.

Die Software existiert also seit nun fast 20 Jahren sehr erfolgreich und das ohne:

OOP
Projektmanagment(na gut er hat ein paar Textdateien)
Desingpattern
Frameworks oder Libs von Fremdherstellern
externen Datenbanken

Es funktioniert bis heute einwandfrei und hat einiges an Wandel durch. Es ist auf hunderten von Rechnern installiert und wird vernetzt eingesetzt. Ein Teil davon arbeitet selbst auf kleinen Kassensystemem wo er auch selbst die Treiber für schreibt(Drucker, Scanner etc.). Buchhaltung/Personalverwaltung etc. hat es noch nebenbei eingebaut.

Ich will damit sagen, dass man auch ohne den ganzen Quatsch, der hier und anderswo propagiert wird, erfolgreich ein Softwareprojekt betreiben kann, was auch schon sehr oft weiterentwickelt und auch mal fast ganz umgebaut wurde.

Das alles hat EIN Mann in reinem C geschafft und Sicherheit ist da extrem wichtig bei. Also lasst euch hier keinen Bären aufbinden, was man alles tun muss um wartbare, langlebige und erfolgreiche Software zu schreiben. Das kann alles helfen, es ist aber absolut kein MUSS.

Bitte ein Bit

@wahreWorte:

Aha, ein Glaubenskrieg.

Hast du überhaupt den Sinn hinter Softwareengineering verstanden ?

Das soll dich nicht drangsalieren, dir vorschreiben was du zu tun und zu lassen hast und dir erst Recht nicht vorschreiben was du zu denken hast. Und es ist längst kein Silberbüffet.

Wenn ich mir hier so die meisten Kommentare zu geposteten Quellcodes anschauen, baut sich ganz schnell eine andere Meinung auf. Daher dachte ich, es wird so gelehrt und jeder der sich nicht dran hält ist halt ein schlechter Softwareentwickler.

Ich kenne halt das krasse Gegenteil, aus der Realität, welches wunderbar funktioniert und wollte auch diese Sicht, der durchaus erfolgreichen Softwareentwicklung, mal zeigen.

Bashar

Neunzehn schrieb:

Willkommen in der Realität.

Ich hab auch nur die Realität beschrieben.

asc

TyRoXx schrieb:

Es gibt seit Jahrzehnten Computer und fast jeder benutzt welche. Es gibt also eigentlich genug Bedarf und Erfahrungswerte, um vernünftige Software zu produzieren. Alles wird bunter und lauter, aber nicht besser. Was meine ich damit?

Auch wenn ich nicht in jeden Punkt deine Meinung teile, so kann man allgemein sagen das Software (egal wie sauber programmiert und wie gut getestet) niemals "fertig" ist. Ich glaube aber nicht das es heutzutage schlimmer ist als früher, im Gegenteil.

Grundsätzlich: Um so komplexer eine Software ist, um so höher ist die Gefahr für Fehler. Des weiteren spielt die Erfahrung der Programmierer, Zeitdruck, Qualitätssicherungsmaßnahmen etc. eine Rolle.

a) In vielen Unternehmen wird (logischerweise) in erster Linie nach Gewinn entwickelt. Sprich Features müssen schnell umgesetzt werden, Massnahmen die Zeit kosten werden verboten oder eingeschränkt (Das dies im Endeffekt sich rächen wird steht auf einen anderen Blatt).

b) TDD ist ein schönes Stichwort, wird aber in vielen Unternehmen (u.a. wegen Punkt a, oder weil das Thema "relativ" neu ist) nicht umgesetzt.

c) Kunden möchten möglichst wenig zahlen und möglichst schnell geliefert bekommen; sie ignorieren dabei aber in der Regel das Qualität auch mehr Arbeit bedeutet. Auch das Pochen auf ganz feste Zeitpläne mag einerseits verständlich sein, anderseits sollte man diese lockern können, wenn ansonsten die Qualität zu sehr leidet.

Das man auch ohne TDD etc. gute Software schreiben kann, stimmt natürlich. Aber je Komplexer eine Software ist und umso mehr Menschen an einen Projekt arbeiten, umso klarer müssen Codeteile getrennt werden und umso mehr sollte man auch automatisieren. Der Größte Feind der Qualität ist aber immer noch der Zeitdruck.

Man sollte auch kein Programm wie Windows mit einem kleinen Texteditor etc. vergleichen. Selbst das Programm von uns, das eher noch klein ist, liegt bei etwa 400000 Codezeilen. Das Programm woran ich vorher dran gearbeitet habe lag bei etwa dem zehnfachen.

asc

Marc++us schrieb:

...Da kann man dann auch erkennen, wie getestet wurde... nämlich ein Prüffall war "ungültiges Datum erkennen", ein anderer Prüffall war "Datum aus Picker richtig übernehmen". Aber es gab wohl kein Testszenario für "Benutzer gibt Datum ein".

Es ist völlig normal das Testfälle vergessen werden (sonst werde TDD und Co perfekt), man testet in der Regel die Fälle die einem in dem Moment einfallen. Und wer z.B. vorrangig mit der Maus arbeitet, vergisst gerne mal die Tastatureingabe und umgekehrt.

In unserer Firma gibt es auch regelmäßig solche Fälle. Da Ändert man ein paar Felder in einem Fenster und vergisst z.B. so etwas "banales" wie z.b. ob die Tabulatorreihenfolge noch passt. Das ist auch keine Absicht, sondern kommt halt von Zeit zu Zeit vor. Oder aber man testet ein Fenster recht gut durch, übersieht aber einen Fall der nur eintritt wenn jemand in einer ganz anderen als der erwarteten Reihenfolge Daten eingibt.

Marc++us schrieb:

Bei solchen Fällen würde ich den Fehler daher weniger im Management suchen,...

Jeder der an einem Projekt beteiligt ist wird Fehler machen, ganz gleich auf welcher Ebene. Um so mehr Leute an einem Projekt arbeiten um so eher passiert dies. Um so unbekannter eine andere Arbeit ist, um so mehr "Reibungsverluste" entstehen. Und zu guter Letzt hat jeder einen eingeschränkten Blickwinkel, egal wie sehr er sich auch bemüht.

Marc++us schrieb:

Aber die Prüfungen wurden aus Sicht eines Programmierers erstellt nach der Vorgabe "egal was kommt, da darf nie ein illegales Datum stehen". Aber es wurde nicht aus Sicht des Nutzers gedacht.

Das will ich so nicht unterschreiben. Selbst wenn man aus Sicht eines Nutzers testet, wird man dennoch nicht aus Sicht aller Nutzer testen. Das ist schlicht unmöglich (auch wenn im Falle eines Datumscontrols die Testfälle wohl noch relativ überschaubar sind.

Marc++us schrieb:

...Zur Sicherheit heißt das also: während des Scanvorgangs nicht weiterarbeiten. Da hat man dann eine Multicore-CPU, die problemlos mit sowas im Hintergrund klarkommt, aber leider macht die Software das kaputt.

Auch hier würde ich nicht sagen das nicht aus Sicht eines Nutzers getestet wurde, vielmehr ist hier einfach der Fall dass das Zusammenspiel zwischen Verschiedenen Programmen nicht getestet wurde. Niemand kann alles testen und man übersieht immer etwas.

Marc++us schrieb:

Auch sowas sehe ich weniger als Problem eines Managements, sondern als Versagen der Testcases...

Stimmt. In der Regel sind dafür Fehler im Management wesentlich schwerwiegender (selbst wenn diese vielleicht seltener sind). Fehlentscheidungen die ganze Projekte zugrunde richten habe ich schon miterlebt (z.B. durch unterschlagen von wichtigen Kundenmeldungen...).

Marc++us schrieb:

Wobei sich da einiges durch die App-Märkte tut, wenn da was nicht geht in Bezug auf Usability schreien einige 100 User, und es wird auch bei großen Firmen eher rasch gefixt - man kann sich nur wünschen, daß das auch beim PC-Markt bald mal Einzug hält.

Beim App-Markt kann man durch die Bewertungen wirklich einiges erreichen, auch wenn ich manche Bewertungen rigoros löschen würde: Wer bei wirklichen Niedrigstpreisen ein Stern vergibt, weil die Software ja nicht kostenlos ist, oder weil der Appstore nicht das gewünschte Zahlungsmittel unterstützt (wofür der Appentwickler ja nun einmal gar nichts kann) oder keinerlei Hinweise gibt was den schlecht ist...

Anderseits sind Apps häufig auch wesentlich kleiner und unkomplizierer in der Herstellung und Wartung, so das ein Fehler auch häufig schneller behoben werden kann.

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.

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.

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.