Hallo,
Es ändert sich, wie schon geschrieben, nichts grundsätzlich für einen Entwickler.Zitat von SPSAmeise
Wo sich etwas ändern muss, ist in den Ebenen über dem Entwickler!
Bei MS, in der Zeit als es von MS noch gar keine Updates gab, war es so, dass Billy der Überzeugung war, dass nur ganz junge Entwickler neue Ideen haben. Also wurden die meisten direkt ab UNI, oder sogar vor dem Abschluss, bei MS eingestellt.
Weiterhin hat Billy das Datum für die Veröffentlichung z.B. einer neuen Windows-Version festgelegt und dieser Termin musste eingehalten werden. Dabei war es egal ob der Entwickler noch eine Bugliste mit 100ten bekannten Bugs hatte oder nicht. Das Din musste zum Termin raus!
Vieles waren ganz doofe Anfänger-Fehler!
z.B. SASSER. Das Problem lag in der Automatisierungs-Schnittstelle. Per Definition wurden nur Meldungen mit maximal 4kB Grösse verwendet. Also nahm man das Datenpaket von der Ethernet-Schnittstelle und kopierte es in einen 4kB Buffer. Dabei wurde aber vergessen, dass Ethernet Pakete bis zu 64kB übertragen kann und hat die Paketgrösse von der Ethernet-Schnittstelle übernommen, aber nicht auf 4kB geprüft! Somit konnte man rund 60kB hinter den Buffer mit eigenen Daten, bzw. Code, überschreiben. Da diese Schnittstelle natürlich standardmässig freigeschaltet war, genügte es, Windows zu installieren und den PC mit dem Netzwerk zu verbinden.
Durch SASSER kam wenigstens MS so weit unter Druck, dass seither regelmässig Updates von MS ausgeliefert werden. Vorher war die Antwort auf Bugmeldungen: "Kaufen sie die neueste Version!". Wobei nicht garantiert wurde, dass der Bug da behoben ist.
Bei Win-95 gab es 5 verschiedene Versionen (95, 95A bis 95C, 95B gab es in zwei Versionen). Allerdings wurde dies nicht nach Aussen wirklich kommuniziert, kaufen konnte man nur Windows-95, was in der Schachtel war, war nicht wirklich ersichtlich.
Der Active-Desktop war auch so eine "geniale Idee". Dabei hat man über den ganzen Desktop noch eine HTML-Schicht gelegt, war eigentlich ein durchsichtiges Fenster des IE. Um Dinge automatisieren zu können, hat man dann HTML einfach erweitert, sodass man auch vollen Zugriff auf die Festplatten hatte und Programme starten konnte. Leider war das dann ALLES auch über Web-Seiten möglich!
Ähnliches geschah auch mit dem lizensierten Java. Die MS-Variante wurde so erweitert, bis die Sicherheit ganz im Keller war und MS die Lizenz verloren hat.
Windows NT sollte der damals sicherste Kernel werden, dazu hat man einen Entwickler von auswärts geholt. Eigentlich wurde dieses Ziel auch erreicht, bis dann die MS-Programmierer direkte Zugriffe auf den Kernel gemacht haben und somit die Sicherheit umgangen wurde. Der extra geholte Entwickler warf daraufhin das Handtuch und verliess MS.
Das Problem ist, dass heute die Entwicklung nichts kosten darf.
Also macht das möglichst ein Praktikant, welcher keine Ahnung hat. Und wenn es in etwa das macht, was es soll, wird es freigegeben. Irgendwelche Tests würden zusätzliche Kosten verursachen und vor allem Zeit beanspruchen. So kommt es halt, dass der ganze PC bei einem Tippfehler abstürzt.
Stichwort: Bananaware, das Produkt reift beim Kunden.
Vor allem die Amis schaffen es bis heute nicht, mit Umlauten umzugehen. Teilweise klemmt es schon auf der Webseite. Teilweise stimmt alles auf der Webseite, aber wenn ich Post oder eMail bekomme ...
(Zum Glück habe ich nur einen Umlaut im Nachnamen)
Die Jeep-Geschichte funktionierte über die Bluetooth-Schnittstelle der Reifensensoren. Für mich ist das ein Anfängerfehler im Konzept, wenn man über diese Schnittstelle vollen Zugriff auf den CAN-Bus und somit auf alles im Fahrzeug erhält. Ein kleines Filter, welches nur die bekannten Meldungen der Reifensensoren weiterleitet, hätte da genügt! Im Prinzip kann ein defekter Reifensensor, welcher zufällige Daten versendet, die ganze Kiste lahmlegen oder auch Vollgas geben!
Jeder Entwickler macht seine Fehler, das ist normal. Viele dieser Fehler macht man aber nur einmal im Berufsleben, dann weiss man es, das nennt man Erfahrung. Ein weiterer Punkt ist noch, ob so ein Fehler in die Produktion geht oder schon vorher, z.B. durch Tests, erkannt wird.
Für einen guten Entwickler ändert sich nichts grundlegendes!
Manche müssen lernen, nicht nur an Funktion ihres Produkts zu denken, sondern auch ein Augenmerk auf das Fehlverhalten zu werfen.
Zudem muss er Zeit für Tests einplanen.
Grundsätzlich müssen die Prozesse dahin geändert werden, dass, nicht nur auf dem Papier, mehr getestet und geprüft wird und man sich nicht einfach auf die Anderen verlässt.
Meine Erfahrung mit ISO 900x war anfänglich, dass die Qualität schlechter wurde, obwohl ISO eigentlich eine Verbesserung bringen sollte.
Aus meiner Sicht war hier das Problem, dass beim Hersteller eine Ausgangs- und beim Empfänger eine Eingangskontrolle vorgeschrieben wurde. Da dachte sich jeder, dass er sich das sparen kann, weil ja der Andere schon kontrolliert, schlussendlich wurde dann gar nicht kontrolliert
MfG Peter(TOO)
- - - Aktualisiert - - -
Hallo,
Das kenne ich auch so!
In den 80/90er Jahren, wollten einige Auftraggeber, dass ich fertige Interface-Steckkarten verwende. Da war dann das Problem, dass wenn der PC ausgefallen ist, die neuen keine ISA oder EISA Steckplätze mehr hatten. Kompatible Steckkarten, mit den neuen Bussen, gab es dann auch nicht mehr. Also musste man die Software komplett neu erstellen und die Kostenersparnis war dahin ...
Selbst entwickelte Hardware konnte man reparieren.
Später habe ich dann eigene Hardware nur noch über serielle Schnittstellen an den PC angebunden, dieses Konzept funktioniert heute noch
Das mit den Updates ist auch immer so eine Sache.
Wenn es keine grundlegenden Fehler gibt und keine benötigten neuen Funktionen geboten werden, macht ein Update keine Not.
Ich habe das bei Freunden erlebt, welche immer der neuesten Version nachgerannt sind!
Die waren eigentlich immer nur am lernen und sind laufend über neue Bugs gestolpert und kamen somit gar nie richtig dazu produktiv zu arbeiten.
Wenn man länger mit einer Version arbeitet, kennt man auch die Bugs und wie man sie umgehen kann, erlebt also weniger Überraschungen, welche einem beim Arbeiten unerwartet aufhalten.
MfG Peter(TOO)
Zitieren
Lesezeichen