Gründe für Pfusch in der Software-Entwicklung ... Warum?
Vorweg: Meine Frage richtet sich an ITler und Leute mit Japanisch-Kenntnissen.
Heute habe ich einen Artikel über den (angeblich!) stark verbesserten Google-Übersetzer gelesen, der jetzt neuerdings mithilfe von künstlichen neuronalen Netzen viel viel besser übersetzen können soll, und sogar mit Japanisch einigermaßen gut klar kommt.
(Exakt das Gleiche höre ich übrigens seit Anfang der 90er von diversen Firmen, die elektr. Übersetzer entwickeln, aber das nur am Rande ...)
Dann habe ich versucht den kürzest möglichen Satz "Küken piepsen." von Deutsch auf Japanisch zu übersetzen:
https://translate.google.com/?hl=de#de/ja/K%C3%BCken%20piepsen.
Warum neigen die meisten Firmen dazu, ihre Software großspurig mit Buzzwords gespickt anzupreisen, und investieren gefühlt 80% des Budgets in Werbung, anstatt fähige Entwickler anzustellen?
Warum kann Google nicht ganz ehrlich sagen: "Ja, unser Übersetzer befindet sich seit über 10 Jahren leider noch in der Early-Alpha und spuckt zu großen Teilen absoluten Mist aus, aber wir arbeiten dran, und rechnen schon im Jahre 2100 mit ersten akzeptablen Ergebnissen." ... das wäre dann tatsächlich mal ehrlich. :)
Der Google Übersetzer war jetzt nur ein Beispiel, welches ich mir raus gepickt habe, aber ähnliches gilt auch für Antivirensoftware, Betriebssysteme, Anwendersoftware, Bibliotheken, Webdienste, etc.
Laien, die sich nicht großartig mit diesen Themen auskennen, fallen auf die falschen Versprechungen herein, und bekommen u. U. im echten Leben richtige Probleme.
Ich bin selbst Software-Entwickler und untersuche oft fremden Quelltext. Und wenn ich eine Sache hasse, dann ist es Pfusch und der Versuch, diesen als Qualität zu verkaufen. Es gibt auch richtig gute Programmierer, aber die müssen gefühlt immer mindestens 10 Trottel irgendwie mit durchs Projekt schleifen.
Ordentliches Testen, zeitnahe Reaktionen auf Bugreports, das beheben von allen (!) gemeldeten Fehlern UND ein Nichtüberschreiten des Budgets ist nichts, was sich gegenseitig ausschließt, sondern einfach nur eine logische Folge / Ergänzung. (vorausgesetzt, man macht es richtig)
Qualitativ hochwertige Software ist möglich, wofür es in freier Wildbahn ja genügend Beispiele gibt, aber mindestens 90% sind totaler Schrott der mit schicken Phrasen versehen und unter die Leute gebracht wird.
Meine Frage richtet sich hauptsächlich an andere Entwickler: Warum wird bei euch in der Firma versucht, total verpfuschten Mist teuer zu verkaufen, anstatt richtig und ordentlich zu programmieren?
Ich rede nicht von 100%iger Fehlerfreiheit (die nicht möglich ist), sondern von Projekten, die vor Antipatterns, Legacy-Abhängigkeiten, Bloatware, Ressourcenlecks, Inkompatibilitäten und Schluderei nur so wimmeln.
Liegt es wirklich zu größten Teilen am "knappen Budget", oder was habt ihr für Erfahrungen gemacht?
Vielen Dank schon mal im Voraus für die Antworten! :)
PS: Zu GF.net habe ich mich weiter oben absichtlich (!) nicht geäußert. :)
Das Ergebnis basiert auf 5 Abstimmungen
10 Antworten
Naja bei den kommerziellen projekten ists meistens so das nur für geld entwickelt wird. Da gibts dann allerdings den zeitdruck der dich halbwegs dazu zwingt schneller und evtl schlampiger zu arbeiten. Da du absolut nix vom projekt hast wirst du dir sicherlich nicht in der freizeit die mühe geben das noch zu verbessern/weiterzuentwickeln.. bei freier software ists da meiner ansicht nach besser. Du bist nicht vom geld abhängig und machst es aus leidenschaft. Hier sind die reaktionszeiten oft vergleichsweise etwas länger aber naja alles im leben hat eben gewisse vor und nachteile
Vielen Dank, für deinen Beitrag! :)
Noch eine kurze Erklärung für alle Mitleser, warum ich ich deine Antwort als Hilfreichste ausgewählt habe:
- Meine Frage habe ich irgendwann so Nachts um 03:00 Uhr gestellt, und sie war aufgrund von leichter Übermüdung dementsprechend schlecht ausformuliert. "LeonardM" hat trotzdem am besten "gerochen", worum es mir eigentlich ging.
- LeonardM hat mir mit seiner Antwort eine Tatsache vor Augen geführt, die ich schon seit Jahrzehnten im Hinterkopf habe, aber die es niemals bis ganz nach vorne in den Frontallappen meines Gehirns geschafft hat: Qualitätativ hochwertige Software ist in kommerzieller Form - mit ganz ganz gaaaanz wenigen Ausnahmen - unmöglich.
Ich habe eine Allergie gegen unsauberes Arbeiten, und investiere exorbitant viel Zeit in die Verbesserung von grundlegenden Programmiertechniken. In letzter Zeit verstärkt C++ vor allem mit den neuen C++14 oder gar C++17 Features, die eine fehlerarme Programmierung teilweise erst komfortabel möglich machen.
Ohne in Details versinken zu wollen: Ich habe für ca. drei kleine Header-Dateien (Templates) mit jeweils ca. 30, 50 und 80 Zeilen ungefähr 12 Wochen verbracht. Fast Vollzeit. Jeden Tag kamen mir Verbesserungen und Optimierungen in den Sinn, bis vor einigen Wochen. Ich erachte meinen Code deshalb als (fast) perfekt, und bei dem winzigen Umfang habe ich nicht nur Grenzfälle testen oder mit Fuzzing arbeiten müssen, sondern konnte für 100% aller möglichen Anwendungsfälle Fehlerfreiheit garantieren.
Zudem wird der gesamte Code zur Übersetzungszeit wegoptimiert und nur in ca. 1% aller Fälle bleiben von den ganzen Header-Dateien zusammen exakt 2 Byte CPU-Instruktionen übrig, die auf modernen x86-CPUs exakt einen Takt verbraten.
Und deshalb zum wichtigsten Punkt von LeonardM's Antwort: Es ist völlig illusorisch zu denken, dass ein "normaler" Chef seinen Mitarbeitern erlauben würde, ein Viertel Jahr an insgesamt 150 Zeilen Code so lange rumzodoktoren, bis der Compiler dafür nicht mal mehr Code erzeugt, und das ganze sogar noch für 100% aller möglichen Zustände zu testen.
Wie an anderer Stelle schon erwähnt, bin ich selber Chef einer Firma, arbeite aber - verglichen mit anderen aus der Branche - sehr unkonservativ. Die investierte Zeit in die oben angesprochenen Module hat sich extrem gelohnt. Seit deren Verwendung treten beim normalen Testen drei gängige Fehlerkategorien überhaupt nicht mehr auf. Null. Nix!
Trotzdem hätten von Anfang an die meisten Chefs der obigen Entwicklung nicht zugestimmt, da es einfach nicht "wirtschaftlich" wäre. Nur größte Unternehmen mit fettem Budget können sich solche teuren Experimente leisten, deren Ausgang höchst ungewiss ist.
Anders bei Open Source o. auch Freeware: Die Entwickler stecken viel "Liebe" in ihren Code. Garantiert meistens wesentlich mehr Liebe, als es in einem kommerziellen Umfeld möglich wäre. ("Liebe" kann man auch durch "Zeit", "Aufwand", "Ressourcen", usw. ersetzen, aber ich denke, es ist klar, worauf ich hinaus will.)
In den aller wenigsten Firmen werden Mitarbeiter Wochenlang an einer 10-Zeilen Funktion optimieren. Im Hinblick auf das Geschäft ist das m. M. n. auch vernünftig. Und wenn ich an meine eigene Firma denke, kann ich es sogar nachvollziehen. Trotzdem mache ich es anders und fahre seit über 10 Jahren gut damit!
Um auf meine Frage zurück zu kommen: Mich ärgert jetzt sehr stark, dass die meisten Firmen fast nur an ihr Budget denken, das Ergebnis aber verkaufen wollen, als wäre es mit "Liebe" entstanden. Dieses "Verkaufen" ist es, was mich dabei stört.
Das trifft leider meistens nicht zu, und grenzt an Etikettenschwindel. Die Ausrede, dass es (fast) alle so machen, zählt nicht, denn ich mache das in meiner Firma nicht so.
Ich gebe von Anfang an immer deutlich längere Entwicklungszeiten als die Konkurrenz an, und deshalb fällt tatsächlich auch ein großer Teil der Auftrage weg, aber ich habe noch nie (!) bei einem Projekt den Zeit- oder Budgetplan überschritten, sondern war immer etwas darunter.
Im Nachhinein habe ich jetzt nicht nur einmal zu Ohren bekommen: "Ach hätten wir uns damals mal lieber für Sie entschieden.". Wenn ich den BER gebaut hätte, wäre er 2010 eröffnet worden, und läge unter dem anvisierten Budget. :)
Fazit:Entweder man entwickelt "wirtschaftlich" ODER "hochwertig". Das ist - so denke ich - eine ganz wichtige Erkenntnis. Und Ausnahmen bestätigen die Regel! (Bitte den Durchschnitt der verfügbaren Software / Websites / Apps betrachten, auch wenn es auf beiden Seiten der Medaille sowohl Pfusch, als auch Qualität gibt ... auf das Verhältnis (!) kommt es mir an!)
huiuiui ne lange antwort :D 1. danke fürs danke :p 2. ich lese es mir morgen durch ich bin grade gut am lernen :D
hui deine antwort hat mich jetzt echt gerührt :D ich sehe das genauso. ich betreibe ebenfalls ein von grund auf in php geschriebenes webprojekt das den "mitarbeitern" in einem spiel die member einer naja nennen wir es virtuellen arbeit bei der sie sich spielgeld verdienen können einiges an arbeit erleichtern soll. da kommen monatlich mehrere 10.000 einträge zustande. ich bin stetig am nachbessern des Funktionsumfangs und der sicherheit (auch wenn ich nicht ganz so erfahren bin, ich bin grade mal 16 und bin in ner ausbildung zum industriemechaniker mit nem hauptschulabschluss) aber wenn ich das resultat und die zufriedenheit sehe ist das ganze mehr wert als alles andere meiner meinung nach. da habe ich produkte der konkurrenz gesehen die zb aus bequemlichkeit auf etliche libs gesetzt haben und die ressourcen des clients förmlich gefressen haben bis zum browserabsturz
Das ganze auf einen einzelnen Grund festzulegen ist kompletter Unfug. Keine Firma, die länger als 1 Jahr im Geschäft bleibt, wir ein solches Kardinalproblem haben. Es sind vielmehr viele Kleinigkeiten welche zusammen nun mal das Bild der Modernen Softwareentwicklung bestimmen.
Zumeist ist es eben der Konkurrenzkampf. Software muss etwas "besser" können als eine andere, gleichzeitig muss diese auch zu einem bestimmten Zeitpunkt erscheinen, da sich ansonst ein Konkurrent im Markt ausbreitet. Hierfür hat man ein Beschränktes Budget. An dieser Stelle kommt eben das Problem mit dem Gleichgewicht.
Die Entwickler wollen mehr Zeit um das Projekt zu testen und an allen Ecken und Kanten zu polieren. Der Vertrieb will es schon gestern auf dem Markt haben und das Marketing macht was das Marketing machen soll, die Werbetrommel rühren.Termine müssen Festgelegt werden, da man ansonsten die Kunden nicht wirklich Interessieren kann.
"Das Produkt wird irgendwann in der Zukunft erscheinen. Freuen sie sich bereits darauf." ist jetzt nicht gerade etwas, wo die Leute in wilde Euphorie verfallen.
Verpasst man nun einen bestimmen Zeitpunkt(wenn z.B. ein Konkurrenzunternehmen ein ähnliches Produkt präsentiert, dann verliert man Geld. Doch der eigentliche Sinn der Software ist ja Geld zu erwirtschaften. Was macht man denn nu? Eher Raus und mit potentiellen Bugs? Polieren & testen, dafür aber Geld verlieren?
Der andere Faktor ist das berühmte Problem: Die linke Hand weiß nicht was die Rechte tut.
Größere Projekte werden meist von mehreren Teams erledigt. Jedes Team hat verschiedene Stärken und Schwächen. Jedes Team arbeitet unterschiedlich schnell. Das ganze nun optimal zu führen ist sehr schwer. Klar gibt es Vorgehensmodelle, welche das ganze optimieren, aber auch die sind nicht perfekt, so wie Menschen nicht perfekt sind.
Schlussendlich ist aber immer zu sagen: Ein Softwareunternehmen verdient Geld mit dem Verkauf von Software. In den seltensten Fällen steht hierbei die Codequalität an erster Stelle. Ein Projekt, welches unterdurchschnittlich Kapital generiert ist ein versautes Projekt für die Firma. Nicht unbedingt für die Entwickler, aber für das Unternehmen.
Sehr gut auf den Punkt gebracht und selber nicht hätte besser formulieren können. Mich deinen Worten also vorbehaltlos anschließen kann. Ergänzend erwähne das so einige Fehler selbst bei penibelster Kontrolle nicht erkannt werden, weil sie erst unter bestimmten Hardware/Treiber-Konfigurationen zu Tage treten.
LG medmonk
Ich kann deine Kritikpunkte nachvollziehen, aber jemand wie du, welcher in der Softwareentwicklung tätig ist, sollte ja gerade nachvollziehen können warum so etwas überhaupt möglich ist ;)
Bei vielen anderen Bereichen hat der Otto-Normal-Verbraucher ein gewisses Verständnis. Autos, Waschmaschinen und z.B. Fahrräder. Die meisten Menschen können sich darunter etwas vorstellen. Sie begreifen das Funktionsprinzip und wissen was sie in etwa wollen. Die Einschätzung ob etwas gut oder schlecht ist bildet man sich eben durch eigenes (Halb-) Wissen und Erfahrungen.
Bei Software sieht es meist anders aus. Als IT-ler wird man von vielen Leuten als eine Mischung von Magier und Nerd-der-nur-am-Rechner-rumclickt angesehen. Der gesamte Prozess der Entwicklung, die Arbeitsweise oder Qualitätskriterien sind für die meisten Menschen nun mal nicht nachvollziehbar.
Wie oft hab ich den Satz gehört "Ihr tippt doch nur ein paar Sachen in den PC ein und schaut ständig im Internet nach. Ich hab ja auch schon mal eine Webseite gemacht. Ist doch alles nicht so schwer, jetzt stell dich nicht so an." gehört.
Genau dieses Miss- bzw. Unverständnis macht Menschen eben dem Marketing empfänglich. "Die Software ist gut, es sind nur kleinere Fehler drin" Der Fachfremde wird sowas vielleicht glauben. Warum sollte er auch nicht. Für ihn ist das Ding ja sowieso eine magische Kiste die irgendwie funktioniert ;)
Du als jemand vom Fach siehst, dass dort geschlampt wurde.
Der andere große Punkt sind immer die Konsequenzen.
Ist ein Auto fehlerhaft so müssen Rückrufe gestartet werden. Das Unternehmen könnte im schlimmsten Fall verklagt werden. Aufsichtsbehörden fangen an rumzuschnüffeln. -> Will das Unternehmen nicht, kostet ja Geld.
Eine Software hat Bugs. Nun wie genau weist man das nach? Was "genau" wurde denn "Versprochen"? Kleinere Bugs sind ja normal, aber wo genau zieht man die Grenze zu nicht mehr tragbar?
Bisher gibt es meines Wissens nach dazu keine gesetzliche Grundlage, was wiederum bedeutet: Die Unternehmen haben praktisch Narrenfreiheit den Usern alles zu servieren was sie wollen. Sich dagegen aktiv wehren ist schwer.
PS.: Ja ich kenne das Problem mit dem Vergleich. Ich mag an dieser Stelle die Analogie mit einem Buch.
Man stelle sich eine Software wie ein Buch vor.
Kleinere Bugs sind mal ein fehlender Buchstabe oder ein Komma.
Größere Bugs sind das fehlen von ein paar Wörtern oder einem Satz.
Die (heutzutage) typischen day-1 Bugs sind vielmehr das Fehlen von ganzen Seite oder Kapiteln, womit man das Buch zwar noch lesen kann, aber es teilweise keinen Sinn mehr ergibt.
Nochmal danke für die weiteren interessanten Gedankengänge. Du hast natürlich Recht, dass ich mich auch in die Lage von Unwissenden herein versetzen muss. Alles in allem stimme ich dir zu! :)
Da wir gerade so schön bei Analogien sind: Wenn eine Firma ein Wörterbuch verkauft, bei dem die Seiten für Wörter beginnend mit "K" fehlen, fällt das dem Laien und Gelegenheitsanwender nicht sofort auf, einem Studenten beim täglichen Arbeiten aber sehr rasch. Früher oder später stolpert jeder über das Problem, egal ob Otto-Normal oder Profi. Der Nachteil ist für beide der gleiche, wobei ersterer evtl. nur mit den Schultern zuckt und sich denkt: "Na gut, guck ich halt im Netz nach." ... der Student wird sich während dem Unterricht ohne Internet-Zugriff vermutlich mehr ärgern.
Trotzdem hat der Verlag ein Wörterbuch mit offensichtlich gravierenden Mängeln verkauft, und ihm muss das auch beim Erstellen irgendwie aufgefallen sein. Das Produkt jetzt trotzdem als "Riesen-Wörterbuch 2000 Mega Plus Pro mit Aussprache-CD und Vokabelposter" zu verkaufen ist dann schon grenzwertig, da ja die Grundanforderung aller Einträge von A-Z mangels K ja nicht mehr gegeben ist.
Ein weiterer Verlag, der für eine ordentlichere Erstellung mit allen verfügbaren Buchstaben des Alphabets mehr Zeit und Geld investiert hat, und auch keine Mängel mit CD und Poster kaschieren muss, sieht für Käufer auf den ersten Blick weniger ansprechend aus.
Der ehrliche und ordentliche Verlag hat also einen Nachteil ggü. den Pfuschern. ><
OK, das reicht jetzt aber mit den Vergleichen. Ich weiß ja was du meinst, und du kannst - wie es aussieht - auch meine Gedankengänge nachvollziehen.
Schönen Abend noch! :)
Erst mal:
https://translate.google.com/?hl=de#de/ja/K%C3%BCken%20piepsen.
ROFL – LACH – KRINGEL – HAHAHAHA – :'-D
Das war wirklich ein Brüller!
Aber mal zum Thema:
Ja, es ist ein Graus mit der kommerziellen Software-Entwicklung.
Ich denke, dass es am Markt-Druck liegt. Es geht darum, so früh wie möglich die Kunden an sich zu binden und erst hinterher mit Patches und Updates diese dummen Fehler dann auszubessern.
Das beste Beispiel ist Windows. Es ist ein Horror an Bugs und Leaks und jedem erdenklichen Mist. Manchmal frage ich mich, ob die das mit Absicht machen, denn so dämlich kann man doch nicht sein. Aber heute nutzt jeder Windows. Ich bin da auch keine Ausnahme gewesen und bin bereits von Anfang an dabei.
Bisher. Seit die aber mit diesem unsäglichen Kachel-Rotz raus sind, ist bei mir Schicht. Ich dachte noch, "warte mal ab, was die nächste Version bringt" …
Danke, dass wir mal darüber geredet haben – ich bin jetzt bei Linux.
Geht doch!
Lange Rede, kurzer Sinn, es geht nicht um Können, sondern um Kunden-Bindung und wohl auch um das Schröpfen der Kunden.
Ein kleines Beispiel:
Ich habe mal unter VB5-6 eine ganze Sammlung an API-Toolboxes zusammen gebastelt, weil es mir irgend wann einfach zu dämlich war, den ganzen Rotz ständig neu programmieren zu müssen, da der native Befehls-Satz wirklich primitiv war. Das Projekt ist richtig komplex und komplett geworden.
Dann kam .NET auf den Markt, mit ziemlich genau den gleichen Klassen-Strukturen und auch Funktionalitäten. Bis die das allerdings überhaupt zum Laufen bekommen hatten, dauerte es noch einige Jahre und Versionen. Ebenso deren Funktionsumfang war anfangs ziemlich mager. Der Hammer ist aber inzwischen das .NET-Paket, was dann installiert so absurd groß geworden ist, dass ich es nicht fassen kann. Mein Paket hatte nicht mal 100 MB, es wurden nur völlig simple DLL's veröffentlicht (das kann man noch nicht mal "installieren" nennen) und deckte so ziemlich die ganze API (Stand 2001) ab.
Ich habe das dann nicht mehr weiter verfolgt. Ist ja auch witzlos, denn wer würde schon mein Produkt kaufen, wenn er doch .NET haben kann.
Daher würde ich inzwischen auch soweit gehen zu sagen, dass sich hier zwei Dumme gefunden haben: der Hersteller, der es geschafft hat, seine Fehler als Marke anzubieten und der Kunde, der diese Marke bereitwillig aus der Hand frisst. Google ist da auch so eine Marke, mit der mal einfach Translate als "Bonus" gegeben wird, um mit vielen weiteren kleinen Gimmicks die Kunden zu binden.
Ich denke, dass damit auch gezeigt werden kann, dass das Budget
eigentlich kein Hinderungsgrund ist, etwas Ordentliches zu liefern. Gut,
ich habe nie mit unfähigen Kollegen lange arbeiten müssen, denn ich bin
vorher freiwillig gegangen. Dafür bin ich viel zu ehrgeizig, um so was akzeptieren zu können.
Inzwischen mache ich nur noch Freeware. Ich habe die Schnauze voll vom kommerziellen Software-Markt. Damit verdiene ich zwar kein Geld mehr, aber dafür bin ich glücklich, wenn ich ein Produkt fertig habe, das auch wirklich fertig ist. Ich kann das einfach nicht mehr ertragen, so kaputte und verkorkste Ware rauszukloppen. Das geht mir voll gegen den Strich.
Danke für die Antwort, auch wenn ich es an einigen Stellen nicht so ausgedrückt hätte.
Aber ich verstehe sehr gut, was du meinst! Ich habe auch schon öfter Dinge entwickelt, die dann zukünftig in der offiziellen API / Standardbibliothek gelandet sind. Durch diese Vorarbeit hab ich dann sogar Fehler im TR1 von C++17 gefunden, die sehr subtil waren und zu diesem Zeitpunkt noch nicht ausgemerzt waren.
Das gleiche bei Java: Damals noch zu Java 5 Zeiten, einen sehr schicken Wrapper geschrieben, um Swing Komponenten beliebig drehen zu können, ohne die Funktionalität einzuschränken. Dank JavaFX ist das jetzt noch viel viel komfortabler möglich. :)
Den Punkt, den du mit Freeware ansprichst ist fast der selbe, den LeonardM angesprochen hat. (Siehe dazu meinen Kommentar unter der hilfreichsten Antwort.)
Du hast natürlich Recht damit, dass ordentliches Entwickeln meistens "unwirtschaftlich" ist. Nur bei Open-Source oder Freeware kann man genügend "Liebe" in seine Software stecken. Tut man das als angestellter Entwickler, kommt der Chef und drängelt. :)
Also dann, danke auch dir für deine Antwort! :)
Mir scheint, es gibt für diese Misere mindestens 3 Ursachen:
- Nicht selten werden viel zu unerfahrene Entwickler an zentraler Stelle eingesetzt.
- In jedem Entwicklungsprojekt wird Test zwar eingeplant, aber nie auch nur annähernd in dem Umfang durchgeführt, in dem er eingeplant war.
- Wie sinnvoll und vor allem wie effektiv Tester arbeiten, wird durch niemand kontrolliert.
Drei Beispiele zum letzten Punkt:
- Ich kann mich noch gut an ein Projekt erinnern, das unter seinem ersten Projektleiter über 3 Jahre hinweg sehr gut lief (Version 1 der Anwendung ging schon 6 Monate nach Projektbeginn in Produktion und hat tadellos gearbeitet). Erst der zweite Nachfolger des ersten Projektleiters hat es geschafft, das Projekt innerhalb von nur 7 Monaten so in den Graben zu fahren, dass der Auftraggeber die Reißleine zog.
- Besonders interessant: Als es eng wurde, hat man externe Tester hinzugezogen, aber nicht mal der für dieses Projekt zuständige QS-Beauftragte hat gemerkt, dass der Projektleiter diesen Testern noch nicht mal die Spezifikation der SOLL-Funktionalität der zu testenden Schnittstellen bekannt gemacht hat. Gegen welche Vorgaben sie fast 6 Monate lang getestet hatten und wie viele Fehler sie tatsächlich fanden, konnte niemand sagen.
- Ein anderes Beispiel: Kontinuierlicher End-to-End-Test der Kernanwendung eines großen Unternehmens war über einige Jahre hinweg einem knapp 50 Personen starkem Team externer Tester anvertraut, die alle zum selben Auftragnehmer kamen. Meiner Ansicht nach wäre es - gegeben die Größe diesen Teams - wesentlich geschickter gewesen zwei nur halb so große, von einander unabhängige Teams auf dieselbe Aufgabe anzusetzen und genau zu monitoren, welches der beiden im jeweils letzten Vierteljahr mehr Fehler (gewichtet nach Severity) gefunden hat. Der Zwang, sich gegen das jeweils andere Team behaupten zu müssen, hätte gut zu wesentlich effektiveren Testtreibern führen können (es ging in diesem Projekt vor allem um voll automatisierten Test, der sich laufend neueren Versionen der Anwendung anzupassen hatte). Auch diesem Team wurden so gut wie gar keine schriftlichen Spezifikationen der zu testenden SOLL-Funktionalität zur Verfügung gestellt.
Dass heute Software unter die Leute gebracht wird, die alles andere als ausgegoren erscheint (Google Übersetzer und Microsofts Cortana sind da nur zwei Beispiele) kann natürlich auch noch ganz andere Gründe haben.
Der wichtigste hiervon:
Die Hersteller solcher Systeme benötigen extrem umfangreiche Test Cases um anhand unerwarteter Reaktion ihrer Software zu lernen, wie man sie verbessert (oder gar in dem Sinne, dass die Software sich selbst anhand solcher Beispiele trainieren kann, wenn man ihr jeder falschen Antwort die richtige zur Seite stellt).
Mit anderen Worten: Man bringt Prototypen unter die Leute um Tester zu gewinnen, die für ihre Mühe nicht bezahlt werden müssen.
Ich werde oft von anderen Entwicklern belächelt, wenn ich sage, dass unter glatten 100% Testabdeckung kein Kompilat das Haus verlässt, aber jedem der das als überflüssig erachtet, kann ich nur mal ein Experiment ans Herz legen:
Man nehme ein kleines Mini-Projekt, das eine "vermeintlich" ausreichende Testabdeckung von 98% hat. Das heißt, dass auf 10000 Ausdrücke ganze 200 kommen, die überhaupt nicht getestet wurden. Und je nach Programmierer kann man davon ausgehen, dass darin gleich mehrere Fehler stecken werden.
Im Nachhinein habe ich mit Tests, die ich anfangs für unnötig, aufwändig und überflüssig hielt gefühlt in 80% aller Fälle tatsächlich gravierende Fehler gefunden, vor allem so gemeine Dinger wie Heisenbugs.
Wenn ich zum Testen von 100 Zeilen Code eine komplexe Testumgebung mit 2000 Zeilen bauen muss, so kann ich aus Erfahrung sagen, dass sich das meistens lohnen wird. Auch dann, wenn man damit auf Anhieb nichts findet, so hilft es doch beim Sicherstellen der Funktionalität in der weiteren Entwicklung.
Außerdem erachte ich Unit-Tests ausdrücklich als ÜBERHAUPT nicht ausreichend. Dazu gehören Mock-Objekte, möglichst mit Spies.
Dank einem Spy finde ich regelmäßig Fehler, die alle herkömmloichen Unit-Tests passieren würden. Wenn eine Funktion bei der Eingabe 123 den Wert 456 zurück geben soll, und das auch tatsächlich tut, ist der Unit-Test zufrieden, aber ein Spy findet einen eventuell gravierenden sehr verzwickten Fehler.
Wer zum ersten mal einen Spy einsetzt, wird sich die Haare raufen und sich fragen, wie er sich bloß auf seine 100% Unit-Test-Coverage verlassen konnte. Die schockierendste Erkenntnis dabei ist, dass man selbst damit nicht wenige Fehler finden wird.
Programmieren ist eine hohe Kunst. Testen aber auch. In beiden ein Meister zu werden ist erstrebenswert, aber mir persönlich noch lange nicht gelungen. Gefährlich wird es, wenn Leute glauben, sie wären wirklich "gut" in irgendetwas. In so einem Falle hilft immer ein Blick über den Tellerrand, aber ich schweife ab.
Vielen Dank für deine Anekdoten und das Hervorheben von Testing und Qualitätssicherung. All die ganzen Prozesse, die dazu gehören, kann man gar nicht genug hervorheben!PS: Für andere interessierte Mitleser: "Testen" ist WEIT mehr als einen Unit-Test zu schreiben. Unit-Tests stellen einen großen und wichtigen, aber NICHT den größten (!) Teil dar. Richtiges Testen ist sehr sehr kompliziert, auch wenn es am Anfang nicht so scheint. Es gibt sehr gute Gründe dafür, Leute speziell zum Testen einzustellen.
Meistens ist das Testen an sich anspruchsvoller und aufwändiger, als die Arbeit der eigentlichen Entwickler. (Evtl. wie das Verhältnis zwischen Arzt und Krankenschwester, wobei der Vergleich auch wieder etwas hinkt.)
Ich würde fast schon so weit gehen, und behaupten, dass Tester wichtiger sind, als die eigentlichen Entwickler. Ähnlich wie in der Musik ... da sind die Pausen auch mindestens so wichtig, wie die Töne an sich! Ein Lied ohne Pausen kann man nicht mehr als Musik bezeichnen. Aber ich schweife schon wieder ab ... :)
PPS: Für interessierte ... die Begriffe "Dummy", "Mock", "Fake", "Spy", "Stub", uvm. werden gerne durcheinander gewürfelt, und es gibt keine Einheitliche Bezeichnung, nur mehr oder weniger sinnvolle Tendenzen.
In der Literatur werden auch gerne mal neue Begriffe von Autoren "erfunden". Um zu verstehen, was ich mit Spy meine, kommt man leider nicht drum herum, sich intensiver mit dem Thema zu beschäftigen. Aber es lohnt sich extrem! (Eine Erklärung meinerseits würde den Rahmen hier sprengen.)
PPPS: Da wir gerade bei QS waren ... dieser WYSIWYG-Editor hier auf GF wird irgendwann nochmal dafür sorgen, dass ich einen Herzinfarkt bekomme. ><
Tatsache ist auch, dass es - immer abhängig von der Art der Software, die man zu testen hat - unterschiedlich sinnvolle Definitionen für den Begriff 100-prozentiger Testabdeckung gibt.
Noch viel schlimmer ist, dass Testabdeckung in aller Regel gar nicht gemessen wird, wenn der Kunde es nicht explizit fordert und auch bereit ist dafür zu zahlen, dass ein bestimmter Abdeckungsgrad erreicht wird.
Software, die Hardwaretreiber darstellt oder die z.B. Flugzeuge oder den Betrieb in Kernkraftwerken zu steuern hat, ist da natürlich eine Ausnahme. Hier keinen wohldefinierten Grad an Testabdeckung nachzuweisen wäre grob fahrlässig.
Doch schon bei der Produktion von Software, wie sie Großbanken und Versicherungen zur Abwicklung ihres Geschäfts benötigen, habe ich niemals erlebt, dass der Auftraggeber einen bestimmten Testabdeckungsgrad gefordert hätte (oder dass überhaupt jemand Zeit dafür bekam, Testabdeckung zu messen). Nur in einem einzigen Projekt habe ich erlebt, dass der Kunde wenigstens Testentwurf sehen wollte - wirklich im Detail angeschaut hat er ihn sich aber nicht.
Der Satz ist ja klasse uebersetzt worden. Die Kueken kann ich mir noch erklaeren (wenn der Satz zunaechst ins Englische uebertragen wurde), aber woher kommt das 安価?
Ich bin zwar kein ITler, aber ich frag mich, was so ein 'Volltextuebersetzer' ueberhaupt fuer einen Zweck erfuellen soll, selbst wenn er rein von der Bedeutung her irgendwann einmal alles mehr oder weniger auf die Reihe bekommen wuerde. Trotzdem wird er alles, was interpretiert werden muss oder wofuer man kulturelles Verstaendnis, etc. braucht, letztendlich auch dann nicht hinbekommen.
Und mal ehrlich: Wer moechte bitte schoen einen maschinenuebersetzten Roman lesen; wichtige Dokumente oder eMail-Verkehr vorgesetzt bekommen, die einfach nur durch den PC gejagt wurden oder sich mit jemandem unterhalten, der einem immer nur das Telefon entgegenhaelt, damit Siri und Co. das Gesprochene jeweils hin und her uebersetzen?
Ich merk ja an meiner Person in der Firma selber, dass ein Uebersetzer sehr viel mehr ist, als einfach nur jemand, der von einer Sprache in die andere uebertraegt. Ich muss mich auch sehr gut mit den Themen auskennen, bei meinen Uebersetzungen darauf achten, dass sich niemand 'beleidigt' fuehlt und dann muss ich auch gut mit allen Beteiligten auskommen. So wurde mein mehr-oder-weniger Vorgaenger quasi abgesaebelt, weil seine Uebersetzungen nicht nur unverstaendlich waren, der Typ an sich auch eher unsymphatisch war....
Google scheint tatsächlich zu versuchen, den Kontext zu beachten. Dass das natürlich nicht funktionieren wird ist klar. :)
Versuch mal das einzelne Wort "Mehlwurm" und den Plural davon zu übersetzen. :)
Er übersetzt in beiden Fällen völlig unterschiedlich, wobei "ゴミムシダマシの幼虫" eigentlich eher ungeläufig ist, und auf allen Tiernahrungs-Verpackungen und sonst auch immer nur "ミルワーム" steht.
Wenn man also Singular und Plural wechselt, verstehen selbst die meisten Japaner die Übersetzung nicht mehr. :)
Ich habe den Verdacht, dass Google die Übersetzung der Wikipedia-Artikel zu Rate zieht, falls vorhanden. Dann ergibt obiges Verhalten sogar ein wenig Sinn. :)
Alles, was du schreibst stimmt und stellt eine gute Zusammenfassung der immer noch real existierenden "Software-Krise" dar. :)
Trotzdem kam es mir mehr darauf an, warum eine Software als das verkauft wird, was sie nicht ist. Ich sage nichts dagegen, wenn die Marketing-Abteilung mal ein bisschen die Realität streckt, aber wenn sich 50% der Marketing-Versprechen als glatte Lügen heraus stellen, dann grenzt das an Betrug. Und so etwas hat man leider viel viel zu oft.
Ein obligatorischer Autovergleich: Wenn dir jemand ein Auto für 2500€ mit Airbag, Gurt, Lenkrad und Reifen verkauft und du alternativ die Wahl zu einem Model für 2000€ hast, bei dem aber Airbag und Gurt fehlen, wofür entscheidest du dich?
Zweite Frage: Würdest du dir im Nachhinein wünschen, dich für das billigere Modell entschieden zu haben, wenn sich raus stellt, dass der Airbag nicht funktioniert, der Gurt - trotz Reparatur - ständig reist, die Reifen täglich massiv an Druck verlieren und das Lenkrad wackelt?
Ich weiß, der Vergleich hinkt, so wie alle Autovergleiche, aber viele Kunden kaufen eine Software, die neben der Grundfunktion über zusätzliche Funktionen verfügt. Der Kunde denkt dann: "Oh, die scheint ja besser zu sein." ... Am Ende funktionieren die vom Kunden benötigten Grundfunktionen aber - im Gegensatz zu der "einfacheren" Variante - nicht richtig, und die zusätzlichen Funktionen sind auch alles andere als ausgereift.
Das Problem der Featuritis frisst also wertvolle Entwicklungszeit, die in wirklich benötigte Grundfunktionalität und Tests hätte investiert werden sollen, aber die Marketing-Abteilung dreht das ganze so um, dass es für den Endkunden "besser" als die Konkurrenz aussieht.
(Daran ist dann zwar auch zu einem kleinen Teil der Kunde "schuld", aber in erster Linie der Hersteller der Blend-Ware.)
Es sind nicht die Fehler in der Software, die mich primär ärgern, sondern diese Unehrlilchkeit, die ich auch knallhart als "Betrug" bezeichnen würde.Trotzdem vielen Dank für deine Antwort! Schöne Zusammenfassung! :)