Crap Code – Warum gibt es so viel schlechte Software?

Inspiriert vom Artikel von Nils Langner auf phphatesme – Sauber bleiben! Ein paar Ansätze – möchte ich nun aus meiner Sicht ein paar wichtige Gründe aufzählen, warum es so viel schlechte Software in dieser grossen weiten Welt gibt. Es geht hier nicht darum, wie es aus Kundensicht aussieht, sondern was hinter den Kulissen, nämlich dem Sourcecode läuft.

Die Softwareentwicklungsbranche ist noch zu wenig professionell

Einige Personen und Firmen mögen zwar professionell sein, aber sicher nicht die grosse Masse.
Gemäss Clean Code Developer bedeutet

Professionalität = Bewusstheit + Prinzipien

Es muss ein Bewusstsein und ein Wille vorhanden sein, sauberen “schönen” Code aufgrund von Prinzipien zu erstellen. Es muss einem Bewusst sein, was passiert, wenn man sich nicht an die Prinzipien hält und jeder gerade so entwickelt, wie es ihm passt.

Es ist auch mit schlechter Software möglich Geld zu verdienen

Und das nicht mal wenig. Wenn man eine schlechte Applikation ausliefert, welche viele Fehler hat, kann man auch häufig viel Geld für Korrekturen und Erweiterungen verlangen. Somit ermöglicht dies auch eher unprofessionellen Firmen sehr viel Geld zu verdienen und so weiter zu fahren wie bisher.

Kunden haben zu wenig Erfahrung mit Software

Es ist klar das es für viele Kunden schwierig einzuschätzen ist, ob ein Produkt / eine Firma professionell ist. Häufig bindet sich ein Kunde mit hohen Investitionen an ein Produkt / eine Firma. Die nachfolgenden teuren Korrekturen und Erweiterungen sind immer noch günstiger, wie ein Wechsel auf ein anderes Produkt. Daher fährt man mit dem gleichen Kurs weiter. Erst wenn eine hohe Schmerzgrenze erreicht ist, kann sich der Kunde für einen Wechsel entscheiden.

Die Branche entwickelt sich sehr schnell weiter

Was gestern noch richtig war, kann heute schon veraltet sein. Schlechter Code der vor 10 Jahren geschrieben wurde, ist heute immer noch schlecht. Aber Methodiken haben sich mit der Zeit verändert. Softwaredesigns, welche vor 10 Jahren ein absoluter Hype waren, sind heute schon ein bisschen angestaubt.

22 Responses

  1. Eine Software muss ja nicht zwangsläufig schlecht sein, nur weil der Code schlecht ist. Das ist häufig der Fall und bei Erweiterungen oder Anpassungen des Codes wird man relativ oft auf die sprichwörtliche Schnauze fallen, aber solange die Software das macht, was sie soll, kann der Code noch so ätzend sein …

    Ganz abgesehen davon ist der “schlechte Code” natürlich ein Nebenprodukt des “schnell schnell”-Phänomens. Gute Software im Sinne von “auch in Zukunft gut wartbare, erweiterbare, testbare, … Software” ist eben nicht so schnell in den Editor gerotzt, wie der pragmatischste Ansatz, der keinerlei Blick in die Zukunft berücksichtigt.

  2. Hi Benni

    Danke für dein Feedback.

    Wie ich im ersten Abschnitt beschrieben habe, geht es eben nicht darum, wie die Software aussieht oder funktioniert. Das ist ja das, was sehr häufig vorkommt – aussen hui, innen pfui. Längerfristig hat man genau an diesem Problem zu knabbern und die Kosten werden von Feature zu Feature grösser.

    Ich stimme aber ansonsten deinem Feedback absolut zu.

  3. Die meisten Kunden sind doch selbst schuld. Beim Blick auf den Preis schrumpft nämlich ganz schnell das Qualitätsbewusstsein. Dass eine schlecht programmierte Software auf Dauer Mehrkosten erzeugt (SW-Updates und Wartung, Bedienungsprobleme, Betriebsausfälle), sehen die meisten nicht. Und wenn man sagt, das dauert so und so lange oder kostet noch so viel, wird eher abgewunken, weil der Kunde nicht so abstrakt denken _will_.

  4. Hi nik

    Merci fürs Feedback.

    Ich glaube es ist unsere Aufgabe, dem Kunden klar zu machen, dass sich schlechte Qualität eben nicht rechnet.
    Eine ausgeprägte Fähigkeit eines Softwareentwicklers ist ja eben genau das abstrakte Denkvermögen. Wir können nicht vom Kunden verlangen, genau die gleichen Fähigkeiten zu haben.
    Wenn das Qualitätsbewusstsein mit “erzählen” nicht zum Kunden durchdringt, muss man eben eine andere Technik anwenden. Beispielsweise das Visualisieren mittels Graphen der Kosten im Verhältnis zur Zeit für beide Varianten.

  5. … dagegen spricht aber Punkt 2 deiner Aufzählung ;).

    Bei größeren Projekten und Firmensoftware, kommt ja nicht der nette Techniker mit dem abstrakten Denken und (dem eher selten vorhandenen) Präsentationstalent vorbei, sondern der Vertriebler. Der erzählt dann gerne was vom Pferd, damit er die Provision einstecken kann.

    Wenn man dann als Entwickler Bedenken anmeldet, kriegt eben eine andere Firma den Auftrag, die’s günstiger macht.

  6. Hi Chris

    Natürlich werden einem dadurch auch Aufträge durch die Lappen gehen, wenn man ehrlich ist.
    Aber es wird auch Kunden geben, die einsehen, dass dies nötig ist und dafür zahlen. Hat man sich erst einmal einen guten Ruf erarbeitet, bekommt man auch mehr Aufträge. Mit der Zeit hat man ein so gutes und qualitativ hochwertiges Produkt, dass man im Endeffekt sogar günstiger ist, wie die “Bastelfirmen”.

    Ich glaube, dass in den nächsten 10 Jahren viele Firmen, die jetzt unprofessionell arbeiten, eingehen werden, weil sie mit der Effizienz der Firmen, welche auf Qualität gesetzt haben, nicht mehr mithalten können.

  7. Ich denke mal nicht das man mit einer Fehlerhaften Software wirklich Geld verdienen kann. Hier würde normalerweise die Produkthaftung greifen und die Entwickler müssten Fehler auf eigene Kosten beheben.
    Das Problem dürfte eher im “It’s not a bug. It’s a feature” liegen. Fehler, vor allem beim Konzept, den Anforderungen und der Architektur werden dem Kunden in die Schuhe geschoben (Sie wollten das doch so haben, oder nicht!?). Das ist in sofern ein Problem, da man vom Kunden nicht verlangen kann das er sich mit der Materie auskennt. Ansonsten könnte er die Software auch selber entwickeln.
    Hier mangelt es noch deutlich an Aufklärungsbedarf bei den Kunden. Diese müssen lernen zu unterscheiden was ein “Bug” und was ein “Feature” ist. Ebenfalls fehlen unabhängige Gutachter die dem Kunden zur Seite stehen, vergleichbar mit dem TÜV (z.B. für Autos), dem GS Zeichen (z.B. für technische Geräte) oder der Stiftung Warentest. So lange man also Murks als Gold verkaufen kann, wird es auch Firmen geben die dies tun. Vor allem wird es für viele Firmen keinen oder kaum Anreize geben ihre Qualität zu verbessern.

  8. Hi Ralf

    Danke für das Feedback.

    Ich habe schon einige male erlebt, dass der Kunde zur Kasse gebeten wurde, obwohl der Fehler in der Entwicklung gemacht wurde. Der Kunde versteht ja eh nix, also kann man’s gut verpacken und das geht dann schon.

    Wie ich schon in Punkt 3 der Artikels erwähnt habe, haben Kunden zu wenig Kompetenzen, was den Umgang mit Softwareprojekten betrifft. Diese Kompetenz wird in den nächsten Jahren aber immer mehr ansteigen und irgendwann wissen die Kunden, was gute Software ist, auf was sie achten müssen und wieviel diese kostet (zumindest hoffe ich das).

  9. So lange Menschen meinen für einen Gratisdownload ihre Adresse inkl. Bankverbindung angeben zu müssen, kann ich deine Hoffnung nicht teilen. Das ist nämlich in etwa das Level auf dem in vielen Firmen Entscheidungen getroffen werden. Anstatt sich sachkundige und ggf. unabhängige Hilfe zu holen, wird blind eingekauft wo es die meisten Werbegeschenke und höchsten Rabatte gibt.

    Wenn du mit Punkt 3 Versuch macht Klug meinst, dann könnte es stimmen. Aber mal ehrlich, wie viele Versuche hat eine Firma um z.B. eine Webseite in Auftrag zu geben oder eine Software entwickeln zu lassen? Mehr als 2, im Höchstfall 3 Versuche dürften nicht drin sein. Alle Folgeversuche dürften darin bestehen, jemanden zu finden der den Murks der anderen ausbadet. Entweder die Firma ist nach dem 3. Versuch pleite oder lebt mit einem eher mittelmäßigen Kompromiss sprich Flickwerk.

    Die Softwareentwickler die lieber billig&schnell arbeiten leben davon immer neue, unerfahrene Kunden zu gewinnen. Und die wird es leider immer wieder geben. Dann geht das Spiel wieder von vorne los. Billig einkaufen, mangelhaftes Produkt erhalten, jemanden finden der einem aus der Patsche hilft. Das ist halt das Prinzip das die Wirtschaft am laufen hält. Gilt übrigens nicht nur für den Bereich Software, sondern ist in vielen Bereichen zu beobachten.

  10. @Ralf
    Ich stimme deinen Anmerkungen absolut zu.
    Natürlich wird es immer wieder unerfahrene Firmen geben, die einen Fehleinkauf tätigen. Nur glaube ich einfach, dass die Kompetenz der Personen und Firmen mit der Zeit trotzdem grösser wird. Und die Anzahl der Firmen, die Crap Code produzieren, kleiner wird, weil der Markt diesbezüglich kleiner wird.

  11. Ich behaupte mal ganz frech das ist auch ein Entwicklerproblem. Die Ansprüche sind oftmals zu niedrig, und daß es PHP und haufenweise IDEs für Windows gibt hilft dem Anheben von Standards nicht unbedingt.

  12. Als Softwareentwickler habe ich einen hohen Anspruch an Quellcode. Ich bemerke neben den schon angesprochenen Problemen, die Einfluss auf die Code-Qualität haben, noch andere, die teils im fachlich-technischen aber auch im sozialen Bereich liegen.

    Handwerkliche Fehler oder Unkenntniss werden versucht mit Technologie und Organsiationsmethodik in Griff zu bekommen. Die Verwendung von Frameworks vermitteln die Sicherheit, man würde die Software in eine Form gießen.

    Technologien werden aufgrund von Aussagen Schlagworten ausgewählt und unreflektiert eingesetzt.

    Die Verwendung einer OO-Sprache in einem Projekt führt zu der Annahme, man programmiert objektorientiert.

    Es wird funktional mit einer OO-Sprache programmiert, was mit der teilweisen Verwendung von OO-Elementen (z.B. Referenzen) alles noch komplizierter und komplexer macht, als wenn man nur funktional programmieren würde.

    Lange Projekterfahrung wird fälschlicherweise als lange Programmiererfahrung angesehen.

    Lange Programmiererfahrung wird häufig als Totschlagargument gegen wissenschaftliche Erkenntnisse, begründete und offensichtlich richtige Aussagen verwendet.

    Es gibt Programmierer, die nicht ein auf Erkenntnis ausgerichtetes Weltbild besitzen und damit die Modellabbildung der Realität nicht verinnerlicht haben, was zu der Annahme führt, dass jedes beliebige Modell zur Lösung eines Problems verwendet werden darf. Beliebigkeit ist dann das Problem was im OO-Bereich den Tod einer Software bedeutet, weil nur noch der entwicklende Programmierer die Semantiken seiner Objekte kennt.

    Die Aufschäumung von Pseudo-Patterns führt zu der Annahme, dass Clean Code erreicht wird. Im Gegenzug werden noch nicht einmal die von Erich Gamma vorgestellten Patterns korrekt verinnerlicht geschweige denn in passenden Situationen angewendet und korrekt implementiert.

    Das Gerücht, dass man mit der Verwendung von unterschiedlichen Technologien gleichzeitig auch Schichtentrennung innerhalb einer Anwendung besitzt, ist überall verbreitet.

    Einige Programmierer sehen ihre Arbeit nur als Job und nicht als Passion. Der fehlende Enthusiasmus hat seine Konsequenz in der Antriebslosigkeit akribisch alle Eventualitäten von Funktionen zu berücksichtigen. “Das tritt schon nicht auf.”

    Andere Programmierer legen einen Fleiß an den Tag, der sich leider nicht auf korrekte Implementierung von Funktionen bezieht, sondern auf die Einrückung der Codezeilen, der Benennung der Variablen, der Anzahl der Zeilen einer Methode, der Anzahl der Zeilen innerhalb einer Klasse, die Position der Klassen innerhalb einer Paket-Hierarchie und dass jede Methode einen java-doc konformen Kommentar hat.

    to be continued…

  13. Mal ehrlich. Als Entwickler gibt es auch Zeiten, wo man keinen “Bock” auf ein Projekt hat, weil es ohnehin eine Totgeburt ist (unter falschen Vorausstzungen verkauft, oder dergleichen). Dann schustert man schnell was zusammen, damit das Teil “rennt” und vom Tisch ist. Danach kann man sich wieder um die ernsthaften Projekte kümmern. Auch so entsteht schlechter Code, und ich glaube, dass das gar nicht mal so selten ist. Wer kann von sich ernsthaft behaupten, dass er/sie so etwas noch nie erlebt hat?

  14. Mein Vater hat Häuser gebaut, ich Software. Bei Software für den Kunden “schustere” ich nichts zusammen, genauso wie mein Vater beim Bau eines Hauses für jemand anderes nichts “zusammengeschustert” hat.

    Es gibt natürlich einen Lernprozess, den ich niemanden ankreiden werde, wenn jemand noch nicht so weit ist. Aber wenn man einen Auftrag hat, für den man Kohle bekommt (Und das ist in unserem Bereich oft eine ganze Menge, zumindest bei seriöser Server-Entwicklung), hat man den besten Code zu schreiben, den man in der Lage ist zu schreiben. Wer will schon ein Montagsauto haben?

    Ein klitzekleines Code-Snipplet reicht oft schon aus, um zu sehen, ob jemand es Ernst meint mit Softwareentwicklung, oder nicht:

    public void (DataObject do) {
    boolean ok= false;
    if (do == null) return false;
    … // viel weiterer Code, der “ok” bearbeitet
    return ok;
    }

  15. Hab leider keinen Compiler dabei ;).

    public boolean test (DataObject do) {
    boolean ok= false;
    if (do == null) return false;
    … // viel weiterer Code, der “ok” bearbeitet
    return ok;
    }

  16. Das mit dem “nicht zusammenschustern” will ich mal glauben. Die Regel ist das aber nicht.

    Das hat auch nichts mit einem Lernprozess oder der Kohle zu tun, sondern mit Zwängen denen Entwickler manchmal ausgesetzt sind. Nicht jeder Softwareentwickler ist selbständig und kann sich aussuchen welches Projekt er machen will/kann. Und genau dann kommt es zu solchen Situationen wo etwas zusammengeschustert wird, weil man das ungebliebte und aufgezwungene Projekt schnell wieder vom Tisch haben will. Berufsethos hin oder her, Lernprozess hin oder her. Das ist die Realität.

    Zum Code Snippet: Wer seine Karriere mit Pascal begonnen hat… ;-))

  17. BTW: Dass am Bau nichts “zusammengeschustert” wird, glaubt auch nur derjenige der noch nie ein Haus gebaut hat 🙂

  18. Ich habe auch am Bau gelernt und muss Kurt zustimmen. Neben Kosten- und Zeitdruck gibt es auch immer die menschliche Komponente die man nicht vernachlässigen darf. Wenn es Regnet oder schneit, haben die wenigsten Lust sich in Details zu vertiefen. Dann wird auch schon mal schnell was zusammengeschustert.
    Und wenn mir ein Kunde gehörig aufs Scrotum geht, dann bekommt er durchaus auch schon mal was Zusammengeschustertes nur damit ich den so schnell wie möglich wieder los werde.

    Ich bezweifele ernsthaft das es den Übermenschen gibt der immer und jederzeit an seine Prinzipien fest hält und egal was kommt immer sein Bestes gibt. Es ist schlichtweg eine Frage der Umstände bis jemand einbricht. Der eine wird schon hibbelig wenn der Kunde nervt, der andere erst wenn das Büro um ihn herum brennt und die Feuerwehr ihn höflichst bitte den PC aus zu machen.

Leave a Reply

Your email address will not be published. Required fields are marked *