Warum ist Software so schlecht?



  • Tim schrieb:

    Und wenn ich mal überlege was ich mit meinem Desktop/Notebook so alles mache, fällt mir spontan _nichts_ ein, was ich mit einem Tablet/Smartphone/etc besser oder bequemener machen könnte.

    Doch, das ganze auch dann machen, wenn der PC grad aus ist, man auf der Couch sitzt oder im Bett liegt.

    Nicht für alles, was ich mache, bräuchte ich auch den PC. E-Mails checken, was im Internet nachsehen, schnell was zusammenscribbeln. Dafür will ich nicht immer den PC anmachen müssen

    Selbst ein Notebook ist manchmal zu viel



  • Wie soll den gute Software entstehen?

    Der Markt ist sehr launisch, und schnelllebig.
    Sich ständig anzupassen um nicht unter zu gehen ist schon schwer.

    Die großen hängen an der börse und sollen ständig immer größere Gewinne
    einfahren.
    Für die kleine ist überleben eh schwer.

    Die Leute wollen für Software kein Geld ausgeben.

    Gute Software soll schnell entwickelt werden um günstiger zu sein und der
    Konkurenz ein Schritt voraus zu sein.

    Mit Verbreitung des Internets und den schnellen Leitungen sind wir zu Beta-
    Testern geworden. Halt nen Patch hinterher schieben...(wenn der bedarf groß
    genug ist)

    usw usw usw usw usw usw usw usw...........
    Das sind so viele Faktoren, die es einfach mal unmöglich machen
    wirklich gute Software zu entwickeln.



  • Mit Verbreitung des Internets und den schnellen Leitungen sind wir zu Beta-
    Testern geworden. Halt nen Patch hinterher schieben...(wenn der bedarf groß
    genug ist)

    Warum sollte ein großer Publisher der teure AAA Spiele herstellt auch ein Spiel, welches sich schlecht verkauft hat, weitersupporten, wenn die Kundenanzahl dieses Spieles so klein ist, dass man deren Verlust locker verkraften kann?
    Zumal Gamer süchtiges Konsumvieh sind und es nur ein anderes gutes AAA Spiel bedarf und schon hat man die verlorenen Kunden wieder an der Leine.



  • @TyRoXx:
    Vieles was du geschrieben hast sind einfach Feature Requests.

    Informatik ist aber ein interdiziplinäres Fach. Stell dir vor ein Pianist müsste einen Cutter (Metzgerei) bedienen. Oder ein Bauarbeiter müsste von heute auf morgen löten.

    Ok das müssen die einzelnen Personen nicht unbedingt. Aber jeder möchte einen Computer bedienen. Und wieviele sitzen vorm Rechner und können nicht einmal die notwendigsten Grundlagen des PC's ?

    Gute Software ist nun die Kunst eine Software zu entwickeln so dass alle möglichen Bevölkerungsgruppen sich damit zurechtfinden. Also auch solche welche meinen Computer sind giftig und solche die meinen Computer sind essbar. Ein Freund hatt mal diesbezüglich aus Angst vor einem Virus versucht ein Programm zu löschen, in dem er hingegangen ist und den Eintrag aus dem Startmenü gelöscht hat.

    Als Entwickler steht man vor einem Problem, da man sich selbst in einen solchen Kundenkreis eindenken muss, man es aber aus Betriebsblindheit oft nicht tut. Wenn ich alle *.bak dateien auf einem Verzeichnis löschen möchte, öffne ich eine Konsole und gebe *.bak ein. Logisch, aber nicht für jedermann. Konsole was ist das ? Man muss sich förmlich als Entwickler immer wieder sagen: Wie würde das der Benutzer machen ?

    Und einigen Fälle sind auch nicht trivial, wenn beispielsweise X % das Feature gefällt, aber Y % nicht, Experten als auch Laie die Software nutzen wollen, Anwender die Sofware in nicht vorgesehener Weise nutzen, Neue Features eingepflegt werden soll was aber das Design nicht zulässt (Dateiformate)...

    Windows: Man muss Treiber zusammensuchen und installieren

    😃 Wie soll ein Betriebssystem das besser machen sollen bei diesem Wildwuchs an Treibern ??? Wie stellst du sicher dass Treiber XYZ kein Rootkit ist oder dir das System nicht abschießt ?

    Windows: Ja, ich weiß, dass der Akku fast leer ist verdammt nocheins!! (bei 9% (~ 15 Minuten) oder so wird ein Notebook dann ungefragt heruntergefahren)

    Weil wohl 9% Akkuleistung soviel Energie sind, um ein System sicher herunterzufahren. Ansonsten droht wohl Datenverlust.



  • Bashar schrieb:

    Es sei denn das ist eine kleine Klitsche, wo jeder macht, was er für richtig hält.

    Bashar schrieb:

    Und du meinst, das hat ein kleiner Programmierer oder Supporter unter den Tisch fallen lassen? Nein, die haben das in ihre Problemdatenbank eingetragen, und das Problem ist -- vom Management natürlich -- nicht ausreichend priorisiert worden, um angegangen zu werden.

    Ich arbeite in so einer "kleinen Klitsche".
    Problemdatenbank und Bugtracker? Kann man das essen?
    Das Management ist sich der Probleme bewusst? Das Management weiß die meiste Zeit nicht einmal, an was wir arbeiten und kennt die Software die wir bauen manchmal nur oberflächlig! Unser Management weiß nichts von Software-Entwicklung, handelt nach 30 Minuten Gespräch mit Kunden einen Festpreis aus (nachdem einer der Programmierer die Zeit eingeschätzt hat, natürlich total geraten und mit Information, die nichtmal einen Notizzettel füllen würde) und schon geht das fröhliche Entwickeln los. An der Stelle klinkt sich das Management meistens auch wieder aus. Von Zeit zu Zeit erzählt man woran man arbeitet ("wie, immer noch?", "was war das nochmal für ein Projekt?" ... nein, das ist kein Witz. Das ist hier die Regel).

    Tja und was ist dann mit beschissener Usability? Hat das irgendeine Priorität? Nö, wenn der Müll läuft und nicht ständig abstürzt ist die Sache erledigt, in der Projekte-Queue warten schon neue Aufträge.

    Auch mit wenigen Leuten kann man relativ große Programme bauen. Meine größeren Projekte die ich alleine Baue haben etwa 50-100kLoc eigenen Code. Ich würde wirklich nicht davon ausgehen, dass hinter der Mehrheit der Software, mit der man so tagtäglich in Berührung kommt, ein ganzes Team von Entwicklern steckt die State of the Art Software bauen. Neee, eher so völlig ungeführte Frickler wie wir. (Es liegt nichtmal an fehlender Motivation. Bei spannenden Problemen kniet man sich wirklich rein. Aber man ist in dieser Klitsche komplett führungslos. Mein "Abteilungsleiter" (auch Programmierer), hat sich in den 3 Jahren exakt keinmal eine Software von mir angesehen, von Code ganz zu schweigen. Lol ... naja ich nehme ich auch nicht mehr als Abteilungsleiter wahr...)
    Tja was mache ich dann als Einzelkämpfer, wenn mich eine Kundenbeschwerde erreicht? Das ist ehrlich gesagt ganz abhängig von der Tageslaune und ob der Kunde sich wie ein Arsch benimmt oder sympathisch wirkt. Die meisten kleinen Probleme (wie z.B. eine von Markus angesprochene Eingabe des Datums) sind nervtötend zu beheben und zu verbessern. Sowas fällt zu 99% unter den Tisch weil kein Programmierer bock hat sich mit solchen Dingen zu beschäftigen.

    Willkommen in der Realität.



  • Exakt so habe ich es schon in drei Firmen erlebt. Die armen Schweine die Informatik studiert haben und dann denselben Mist für fast dasselbe Geld machen müssen wie ein Quereinsteiger-Programmierer. Alles persönlich erlebt.

    Die IT ist heute so, als würde man auf den Baustellen die Architekten Wände mauern und zu spachteln, für das gleiche Geld wie ein Maurer natürlich.

    Ist auch kein Wunder, kaum eine Bude braucht wirklich einen reinen Informatiker, da nur ganz selten das Rad neu erfunden werden muss und in der Regel nicht selbst Frameworks oder neue Programmiersprachen entwickelt werden, sondern nur welche zusammen geklatscht und angepasst werden.

    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.

    Ich würde heute keine Informatik mehr studieren, sondern eher was mit wirklicher beruflicher Anerkennung und gutem Verdienst.



  • Neunzehn schrieb:

    Ich würde wirklich nicht davon ausgehen, dass hinter der Mehrheit der Software, mit der man so tagtäglich in Berührung kommt, ein ganzes Team von Entwicklern steckt die State of the Art Software bauen.

    lol! nicht dein ernst, oder? es gibt ein paar libs, die von einzelnen geschrieben werden. aber hinter jedem richtig großen ding >100ksloc arbeitet normalerweise mehr als einer 😉 teilweise arbeiten auch firmen/universitäten gemeinsam an programmen. ijemand muss die ja auch bezahlen von der hand im mund lebt da keiner die haben alle ganz gute stellen! auch bei open source 😉

    Neunzehn schrieb:

    Neee, eher so völlig ungeführte Frickler wie wir.

    dass du in einer scheiß firma bist, dafür kann keiner was. den 'ungeführten Frickler' gibt es in der realität nicht. bei open source ist es so, dass einer anfängt, und das dann so lange macht, bis er keinen bock mehr hat, oder er das gefühl hat, dass das jmd. besser kann. alle die da mitmachen wollen, haben sich gefälligst daran zu halten, was von oben angesagt wird. wenn ihnen das nicht passt gibt es einen split/branch oder wie das teil auch immer heißt und das gleiche spiel geht von vorne los.

    Willkommen in der Realität.



  • Was laberst Du denn von OpenSource?

    Und ja, es ist mein voller Ernst. Ich glaube eher Du bist noch nicht mit der Situation in vielen kleinen und mittelständigen Klitschen in Berührung gekommen.



  • Neunzehn schrieb:

    Was laberst Du denn von OpenSource?

    naja, das war das einzige was auch nur im ansatz zu 'ungeführte Frickler' gepasst hat. in firmen gibts das nicht. zumindest nicht in erfolgreichen 😉



  • oO schrieb:

    in firmen gibts das nicht. zumindest nicht in erfolgreichen 😉

    LOL



  • 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



  • 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.



  • @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.



  • Neunzehn schrieb:

    Willkommen in der Realität.

    Ich hab auch nur die Realität beschrieben.



  • 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.



  • 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.


Anmelden zum Antworten