Forum: Offtopic Hardware Firmware nach ausscheiden des Entwicklers


von Sebastian (Gast)


Lesenswert?

Hallo,

ich beschäftige mich rein aus Hobby mit der Entwicklung von µC 
Programmen- also letztendlich von Firmware.

Selbst bei diesen, im Vergleich zu den Profis, sehr einfachen und wenig 
komplexen Programmen wird es für einen anderen schwierig werden alles im 
Detail nach zu vollziehen, was und warum ich da Programmiert habe, auch 
mit vielen Kommentaren im Quellcode.

Bei Großkonzernen und Sicherheitskritischen Bereichen arbeiten gibt es 
sicherlich Systeme und Vorschriften die dafür sorgen das die 
Entwicklungsarbeit von ehemaligen Mitarbeiter immer Nachvollziehbar und 
damit Nutzbar ist.

Wie ist das aber bei der kleinen "Entwicklungsbude" die irgendwelche 
Einzellösungen für die Industrie entwickelt z.B. irgendeine spezielle 
Steuerung für eine Maschine die "so" nur bei einer Firma genutzt wird ?

Wenn da ein Mitarbeiter die Firma verlässt, wie wird gesichert das die 
Firmware für solche Steuerungen immer noch gewartet und verbessert 
werden kann bzw. Probleme auf Softwareebene behoben werden können.
Der ehemalige Entwickler wird wohl nur soviel Kommentare in seinen 
Quellcode geschrieben haben das er selber nach längerer Zeit alles 
verstehen konnte - gezielte Fehlinformationen oder "leere" 
Programmanteile im Quellcode um zu verhindern das ein Nachfolger das 
Programm gut nachvollziehen kann wird es wohl leider auch im 
professionellen Umfeld geben.

Sebastian

: Verschoben durch User
von WehOhWeh (Gast)


Lesenswert?

Da geht viel Geld flöten, darauf kannst du wetten ;-)

Das Problem, wie z.B. einen Bug beheben, wird in einem solche Fall gerne 
irgendwelchen Entwicklern, vorzugsweise Neulingen vorgeworfen (macht 
mal). Die werkeln dann da Monate hin.

Sowas zu ändern ist harte Arbeit:
Man muss entweder den Quelltext verstehen, die Firmware komplett neu 
schreiben, oder das Firmwareproblem durch eine Hardwareänderng beheben.
Wie die Quoten genau liegen, ist mir nicht klar. Persönlich habe ich 
schon alle 3 Möglichkeiten erlebt.

Mein Lieblingsprojekt bei einem ehemaligen Arbeitgeber ist ein 
kompletter Softcore für FPGAs (ein 32-Bit-Prozessor immerhin), in dem 
keine einzige Kommentarzeile vorkommt und zu dem kein einziges Dokument 
existiert. Kein einziger Entwickler in der Firma geht da dran, also wird 
das Teil seit 10 Jahren unverändert verwendet.
Die flanschen lieber ein externes RAM an jedes einzelne FPGA, statt den 
VHDL-Code so zu ändern, dass (ausreichend vorhandene) interne RAM-Blöcke 
des FPGAs verwendet wereden können. Das traut sich nämlich keiner. Das 
kostet einen 4-5-Stelligen Betrag im Jahr für RAMs...
Der zuständige Entwickler ist in Pension und war Firmengründers 
Liebling, daher ist der Code noch dazu "heilig", kennt man ja.

von Hannes J. (Firma: _⌨_) (pnuebergang)


Lesenswert?

Das ist der sogenannte Heldenansatz, den gerade viele kleine, aber auch 
manche große Firmen pflegen.

Dokumentation, die richtige Art von Dokumentation, bei der Entwicklung 
zu erstellen und diese über Jahre hinweg mit dem Produkt zu pflegen 
kostet Geld. Das sparen sich solche Firmen lieber und beschäftigen 
Helden, die die Software schreiben und warten und arme Würstchen nur zum 
Warten.

Alternativ wird Wegwerfsoftware erstellt. Wenn was Signifikantes 
geändert werden soll wird die ganze alte Software weggeworfen und neu 
gemacht. Das ist bei der Software für Webseiten fast schon der 
Normalfall. Ein Webseiten-"Relaunch" ist nichts anderes als dass man die 
gesamte Webseite, von der Grafik bis zum Code, weg wirft und neu macht.

Es gibt in dem Umfeld noch anderes Verhalten, zum Beispiel die 
Fahrerflucht bzw. Verbrannte Erde. Das ist wenn ein Programmierer einen 
unwartbaren Scheiß zusammenprogrammiert, er das auch weiß, und deshalb 
bei der ersten sich bietenden Gelegenheit die Flucht antritt. Sei es 
eine Versetzung in eine andere Abteilung oder er wechselt zu einer 
anderen Firma, bevor es auffällt was für einen Mist er gebaut hat.

Dann kenne ich noch das "drive by shooting". Das geht so ähnlich. Hier 
kommt ein Berater mal kurz vorbei, richtet ein Codemassaker an und 
flieht mit Höchstgeschwindigkeit vom Tatort. Natürlich nicht ohne sich 
die Taschen mit einem saftigen Honorar vollgestopft zu haben.

von Rolf M. (rmagnus)


Lesenswert?

Sebastian schrieb:
> Wie ist das aber bei der kleinen "Entwicklungsbude" die irgendwelche
> Einzellösungen für die Industrie entwickelt z.B. irgendeine spezielle
> Steuerung für eine Maschine die "so" nur bei einer Firma genutzt wird ?
>
> Wenn da ein Mitarbeiter die Firma verlässt, wie wird gesichert das die
> Firmware für solche Steuerungen immer noch gewartet und verbessert
> werden kann bzw. Probleme auf Softwareebene behoben werden können.

Ein gängiger Weg ist, dass der Mitarbeiter seinen Nachfolger einlernt. 
Je nach Kündigungsfristen und der Dauer, bis man einen Nachfolger 
gefunden hat, funktioniert das mal mehr, mal weniger gut.

> Der ehemalige Entwickler wird wohl nur soviel Kommentare in seinen
> Quellcode geschrieben haben das er selber nach längerer Zeit alles
> verstehen konnte - gezielte Fehlinformationen oder "leere"
> Programmanteile im Quellcode um zu verhindern das ein Nachfolger das
> Programm gut nachvollziehen kann wird es wohl leider auch im
> professionellen Umfeld geben.

Im Idealfall gibt es nicht nur einen, der sich mit der Software 
auskennt.
Die Erfahrung zeigt, dass es auch für den Mitarbeiter von Nachteil ist, 
wenn er der einzige ist. Kann ja auch mal sein, dass was dringendes 
anfällt, wenn derjenige eigentlich Urlaub hat oder einfach schon mit 
anderen genauso dringenden Themen ausgelastet ist. Dann kann man 
entweder sagen: "ist mir egal" und dann schuld dran sein, dass es nicht 
funktioniert und der Kunde Terror macht, oder man hat viel zusätzlichen 
Stress.

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

Rolf Magnus schrieb:
> Im Idealfall gibt es nicht nur einen, der sich mit der Software
> auskennt.

Die Realität ist einer der erbittertsten Feinde des Idealfalls.

von Ben W. (ben_w)


Lesenswert?

es wird versucht mit agilen methoden ein wenig entgegen zu wirken,
Code reviews mit wechselnden reviewern, wechselnde tasks,

klar klappt das nicht immer in der realität :)

ich bin schon für ein Objektorientiertes Programm mit zumindest einer 
sehr groben erkennbaren Struktur dankbar.

<zitat vieler entwickler (mich eingeschlossen)>
Doku? was ist das? der code dokumentiert sich doch selbst :)
</zitat>

von ♪Geist (Gast)


Lesenswert?

Ich hatte einen Fall, wo der ehemalige Entwickler eine komplexe Firmware 
in Assembler erstellt hat und dann die Firma verlassen. Angeblich war 
Assembler nötig, da man die Firmware in einem Atmega128 nicht anders 
unterbringen könnte.  Als Neuling in der Fa. sollte ich diese ausbauen 
und pflegen. Schön dass ich blöderweise im Studium ebenfalls Assembler 
hatte und das in meiner Bewerbung erwähnt habe...Nach einer Woche 
Befehlssalat ging ich zum Chef und habe vorgeschlagen die gesamte Fa. 
umzucoden und zwar in C. Mein Argument war: entweder 4 Monate 
Einarbeitungszeit in die aktuelle Fw. oder in 3 Monaten hat er die 
Firmware in C, die sich weiterhin pflegen lässt. Gesagt getan. Die 
komplette Firmware hat wegen vielen SCPI Strings gerade Mal 60% des 
Flashs verbraucht.

von Ben (Gast)


Lesenswert?

♪Geist schrieb:
> in 3 Monaten hat er die
> Firmware in C

Wenn das geklappt hat, Gratulation.
Das kann auch böse nach hinten losgehen.

Eine bestehende Firmware neu zu schreiben ist ein Risiko. Der 
ursprüngliche Entwickler hat oft Probleme gelöst an die man selber 
garnicht denkt. Viele Probleme treten auch erst während des Betriebs 
auf.
Nach 3 Monaten gibt es dann zwar eine SW, diese muss aber dann weitere 
Wochen/Monate weiterbearbeitet werden bis sie so zuverlässig läuft wie 
die alte.
Grade die Absolventen unterschätzen solche Aufwände oft massiv. Weil "da 
muss man ja nur..."

Nochmal, wenn das bei dir geklappt hat, Glück gehabt, und Gratulation.

von Scelumbro (Gast)


Lesenswert?

♪Geist schrieb:
> ein Argument war: entweder 4 Monate
> Einarbeitungszeit in die aktuelle Fw. oder in 3 Monaten hat er die
> Firmware in C, die sich weiterhin pflegen lässt.

Lass das nicht den Moby lesen. Oder war es gar Moby (oder ein geistig 
Nahverwandter) der diese Firmware verbrochen hat?

von Freddy (Gast)


Lesenswert?

Hallo,

das mit dem dokumenterien ist überall ein Problem.
Ausnahmen sind natürlich sicherheitskritische Bereiche.

Auch kann man nicht immer die Kollegen dazu zu überreden ausreichend zu 
dokumentieren, oder aber die Dokumentation ist irgendwann veraltet.
Dann muss der Chef oder Abteilungsleiter schon direkt dahinter stehen 
und die Leute zwingen.
Aber wir haben gute Erfahrung damit gemacht, dass es eine 
Bug&Feature-Liste gibt (ob manuell, oder im Bugtracker ist egal) mit 
einer Bug-ID und einer kurzen Beschreibung. Im Quellcode ist dann an den 
jeweiligen Stellen ein Kommentar mit der Bug-ID im Kommentar. Wenn dann 
noch mit einem Versionierungs-Tool gearbeitet wird, kann man 
zumindestens nachvollziehen warum bestimmte Dinge geändert wurden.

Genau, die oben genannten Besonderheiten in der History sind bei einer 
Neuprogrammierung häufig nicht vorhanden. Einige treten vielleicht nicht 
auf, werden nicht mehr benötigt, etc. Aber bei manchen Features fällt es 
es viel Später auf, was nicht berücksichtigt wurde.

In unseren VHDL Modulen soll jeder Entwickler anstatt zu dokumentieren, 
zumindestens eine vernünftige Testbench mit aussagekräftigen Wave-Files 
ablegen. Das hilft ganz gut beim Verstehen des Moduls, und falls man was 
geändert hat, kann man dagegen simulieren. Ist meiner Meinung fast 
besser als eine Dokumentation bzw. viele (sinnlose) Kommentare im VHDL 
Code.
Macht leider aber auch nicht jeder Entwickler.

In der Software-Entwicklung setzt sich das mit dem 
Test-driven-devolopment leider noch nicht durch.

von Georg (Gast)


Lesenswert?

Sebastian schrieb:
> ei Großkonzernen und Sicherheitskritischen Bereichen arbeiten gibt es
> sicherlich Systeme

Sebastian schrieb:
> Wie ist das aber bei der kleinen "Entwicklungsbude"

So schwarz-weiss kann man das nicht sehen. Was wie lange entwickelt und 
gepflegt wird ist ja vorwiegend eine wirtschaftliche Frage, und da 
entscheiden Grosskonzerne genauso oder eher noch rücksichtsloser, was 
aufgegeben wird. Ich habe hier bei Kollegen miterlebt, wie für einen 
Millionenbetrag CAD-Software von HP neu angeschafft wurde, die 6 Monate 
später abgekündigt und eingestellt wurde - da sagt der Schwabe halt Pech 
kett. Entgegen anderslautenden Gerüchten gibt es auch keine gesetzlichen 
Verpflichtungen, Ersatzteile eine bestimmte Zeit lang zu liefern oder 
Reparaturen durchzuführen, die über die Gewährleistung hinausgehen. Man 
kann auch über mögliche zukünftige Entwicklungen keine vernünftigen 
Verträge abschliessen. Wenn Ubuntu sagt, 14.04 LTS wird länger gepflegt, 
ist das rein freiwillig, es dürfte auch schwierig sein, das einzuklagen.

Bei kundenspezifischen Projekten kann man sich bei Kleinfirmen oft 
absichern, indem z.B. der Sourcecode hinterlegt wird und im Fall einer 
Insolvenz oder aus anderen Gründen dem Kunden zugänglich wird. Auf so 
etwas würde sich eine Firma wie Siemens nie einlassen.

Dass erhebliche Kosten durch die Einarbeitung anderer Mitarbeiter 
entstehen ist aber einfach unvermeidlich. Dass es auch Programmierer 
gibt, die ihren Code so weit wie möglich verschleiern, ist auch nicht zu 
bestreiten, aber sowas darf der Chef niemals zulassen, schon im eigenen 
Interesse.

Georg

von Franz (Gast)


Lesenswert?

Georg schrieb:
> Dass es auch Programmierer
> gibt, die ihren Code so weit wie möglich verschleiern, ist auch nicht zu
> bestreiten

Das liest man ja öfter hier (sich wichtig machen in dem Code nicht 
dokumentiert oder verkompliziert wird).
Allerdings, kennt da jemand wirklich ein Beispiel aus der Praxis?
Irgendwie wüsst ich nicht wie ich hier (oder in den Firmen die ich sonst 
kenn) solch fragwürdigen Code durch die Reviews kriegen will...

von Freddy (Gast)


Lesenswert?

Wir hatten mal so einen Entwickler.
Hat alles in eine einzige Datei gepackt weil er der Meinung war das wäre 
übersichtlicher. Auch seine Variablennamen waren mehr durchnummeriert 
als hatten sie Namen.
Ob das Absicht war, oder einfach nur Unwissenheit. Er ist dann auch 
schnell gegangen und ich war dann der Dumme der die Problem dann beim 
Kunden ausbaden durfte.

von Georg (Gast)


Lesenswert?

Franz schrieb:
> wie ich hier (oder in den Firmen die ich sonst
> kenn) solch fragwürdigen Code durch die Reviews kriegen will...

Erfahrungen mit solchen Programmierern sind ja der Grund, warum solche 
Reviews eingeführt wurden. Deswegen sind die auch vom Aussterben 
bedroht, in der guten alten Zeit waren sie jedenfalls viel häufiger. Oft 
verbunden mit langen Haaren, Jesuslatschen und selbstgewählten 
Arbeitszeiten vom Spätnachmittag bis nach Mitternacht.

Georg

von Gerd E. (robberknight)


Lesenswert?

Franz schrieb:
> Irgendwie wüsst ich nicht wie ich hier (oder in den Firmen die ich sonst
> kenn) solch fragwürdigen Code durch die Reviews kriegen will...

ich denk das ist der Trick: in der Firma einen ordentlichen 
Review-Prozess implementieren und dafür sorgen daß der auch wirklich für 
alles verwendet wird und funktioniert.

Wenn eine Firma mit 1 oder 2 Mann anfängt geht das noch nicht. Wenn die 
aber langsam wachsen dann wird es bald Zeit sowas einzuführen. Manche 
erkennen die Notwendigkeit, andere nicht...

von Pandur S. (jetztnicht)


Lesenswert?

Es ist nicht immer der entwickler, der keine Doku machen will. es kann 
auch der Verkauf sein, der Projekte als gemacht verkauft, die noch nicht 
mal angefangen wurden. Weil ... es ist ja nur dieses Projekt plus dieses 
Detail ...
Der Entwickler ist so immer unter Druck, moeglichst schnell etwas zu 
liefern. Und wenn der Verkauf nicht eine satte Menge des Prototypen 
verkaufen konnte, lohnt es sich auch nicht zuviel Aufwand in Doku zu 
stecken. Wenn kein Folgeauftrag kommt, braucht's die Doku auch nicht...

.. und wenig spaeter, wenn alle alles vergessen haben beginnt das 
Produkt zu laufen..

von W.S. (Gast)


Lesenswert?

Gerd E. schrieb:
> Wenn eine Firma mit 1 oder 2 Mann anfängt geht das noch nicht. Wenn die
> aber langsam wachsen dann wird es bald Zeit sowas einzuführen. Manche
> erkennen die Notwendigkeit, andere nicht...

Du schreibst von ziemlich reinen Softwarebuden. In der Realität bei 
Maschinenbauern, Apparateherstellern, Energie, Automobil und Meßgeräte 
sieht das völlig anders aus. Da ist Software für 99% der Firma eine Art 
Nebenangelegenheit und völlig außerhalb jeglichen Interesses. Guck dich 
mal auf der Hannovermesse um, da siehst du, worauf die Leute dieser 
Sparten denn so Wert legen. Und vergiß nicht, die Jeans daheim zu lassen 
und nen schwarzen Anzug zu tragen.

W.S.

von MaWin (Gast)


Lesenswert?

Freddy schrieb:
> Hat alles in eine einzige Datei gepackt weil er der Meinung war das wäre
> übersichtlicher.

Ist es auch.

> Auch seine Variablennamen waren mehr durchnummeriert als hatten sie
> Namen.

Nun, das vielleicht nicht.

von rmu (Gast)


Lesenswert?

Georg schrieb:
> Wenn Ubuntu sagt, 14.04 LTS wird länger gepflegt,
> ist das rein freiwillig, es dürfte auch schwierig sein, das einzuklagen.

Da kann man von Haus aus vermutlich gar nichts erfolgreich einklagen. 
Wenn man einen Wartungsvertrag mit Canonical hat, und die stellen die 
Wartung vertragswidrig ein, dann hätte man was in der Hand.

von Gerd E. (robberknight)


Lesenswert?

W.S. schrieb:
> Du schreibst von ziemlich reinen Softwarebuden. In der Realität bei
> Maschinenbauern, Apparateherstellern, Energie, Automobil und Meßgeräte
> sieht das völlig anders aus. Da ist Software für 99% der Firma eine Art
> Nebenangelegenheit und völlig außerhalb jeglichen Interesses.

Wer heutzutage Software als "Nebenangelegenheit" sieht, muss vor so 
Dingen wie "Industrie 4.0" und der Konkurrenz ganz schön Angst haben und 
sollte sich mit Hochgeschwindigkeit daran machen seinen Laden auf die 
Höhe der Zeit zu bekommen.

von PC-Verbinder (Gast)


Lesenswert?

Die Probelematik ist doch meistens die, dass immer wieder misachtet 
wird, wiviel Arbeit die Dokumentation macht. Also macht man alles 
zusammen, ein bischen proggen ein bischen was aufschreiben und ab und an 
ändern. Das sieht immer schneller aus und ist am Ende langsamer, wenn 
geändert werden muss.

Würde man Konzepte machen, alles sauber aufschreiben, wäre es am Ende 
besser, stabiler und testbarer. Den Vorteil hätten aber andere 
Abteilungen und andere, spätere Entwickler und das will keiner leisten 
oder bezahlen, weil alle unter grossem Zeotdruck stehen.

Das ist ein Problem, dass man nie lösen wird können und das auch nich an 
den Entwicklern liegt.

Entwickler müssten sich durchsetzen und knallhart nach Prozessen 
arbeiten. Dann würde alles erstmal länger dauern und man hätte aber 
einen Benefit davon.

Aber die die sich das trauen, werden als Querulaten abgetan, man 
schreibt ihnen Trägheit vor und lagert das Ganze aus an eine schnelle 
flexible Diesntleisterfirma.

Und die schmiert es dann wieder schnell hin. :D

von Gerd E. (robberknight)


Lesenswert?

PC-Verbinder schrieb:
> Also macht man alles
> zusammen, ein bischen proggen ein bischen was aufschreiben und ab und an
> ändern. Das sieht immer schneller aus und ist am Ende langsamer, wenn
> geändert werden muss.
>
> Würde man Konzepte machen, alles sauber aufschreiben, wäre es am Ende
> besser, stabiler und testbarer.

Erst ein großes, tolles Konzept bis ins Detail zu machen, das genau zu 
dokumentieren und dann erst umzusetzen funktioniert meist nicht. Denn 
trotz des tollsten Konzepts hast Du immer irgendeinen Aspekt übersehen 
oder falsch eingeschätzt. Und das erkennst Du erst, wenn Du es 
tatsächlich umsetzt oder gar das erste Mal in der Praxis einsetzt. Oft 
ändern sich auch die Anforderungen des Kunden oder der weiß eigentlich 
noch gar nicht so genau was er braucht und erkennt erst beim Arbeiten 
mit einem Prototypen was ihm fehlt.

Natürlich musst Du am Anfang ne grobe Idee haben wie das ganze aufgebaut 
werden soll. Dann solltest Du aber möglichst schnell einen irgendwie 
lauffähigen Prototypen hinbekommen um die Praxistauglichkeit zu 
beweisen. Und den dann in weiteren Iterationen immer weiter verfeinern 
und verbessern.

Die Dokumentation würde ich dabei während der Entwicklung machen und 
möglichst im Code halten. Mit Tools wie Doxygen bekommt man daraus dann 
eine Übersicht extrahiert. Soetwas wie eine High-Level-Doku kann man 
dann zusätzlich z.B. in Markup oder so schreiben. Wichtig ist daß die 
zusammen mit dem Code eingecheckt werden muss (daher nur textbasierte 
Formate, sonst bekommt man keine brauchbaren Diffs) und Teil des 
Review-Prozesses ist (Merge wird abgelehnt wenn Doku ungenügend).

: Bearbeitet durch User
von Geldverdiener (Gast)


Lesenswert?

Naja, der wichtigste Aspekt fehlt hier: Geld.

Es geht immer nur darum, was billiger ist bzw. was ein Kunde bereit ist 
zu akzeptieren und was sich gerade noch möglichst teuer verkaufen lässt.

Industriesoftware muss nicht ewig halten, bzw. wenn die Maschine mal 
läuft, wird die Software relativ selten geändert, und dann nur bei einem 
Umbau der Hardware. Das ist auch der Grund warum auf vielen Maschinen 
wirklich noch alter Mist läuft.

Zumindest war es in der Vergangenheit so. Mit der ganzen 
Vernetzungsgeschichte ändert sich schon einiges und es wird sich noch 
viel mehr verändern. Erste Unternehmen habe inzwischen ernsthafte 
Probleme mit ihrem Softwaremüll, weitere werden folgen, und meiner 
Meinung nach wird das in den kommenden 10 bis 15 Jahren eine ganz schöne 
Marktbereinigung geben.

von DJ T. (Gast)


Lesenswert?

Gerd E. schrieb:
> Die Dokumentation würde ich dabei während der Entwicklung machen und
> möglichst im Code halten. Mit Tools wie Doxygen bekommt man daraus dann
> eine Übersicht extrahiert.
Dies!

von Michael B. (laberkopp)


Lesenswert?

PC-Verbinder schrieb:
> Die Probelematik ist doch meistens die, dass immer wieder misachtet
> wird, wiviel Arbeit die Dokumentation macht.

Eigentlich gar keine.

Schau dir doch mal dein Handy oder Smartphone an.

Ausser einem Blatt auf dem steht wo man Ohrhörer und Ladekabel 
einsteckt, hat es keine Dokumentation.

Es wird weder erklärt, wie man SMS mit T9 tippt und was in den 
Wörterbüchern steckt, noch wird beim Smartphone irgendwas zur Software 
erklärt.

Das war bei den allerersten Handys noch besser, da stand wenigstens drin 
wie man die Menüs bedient, aber spätestens seit dem die Dinger WAP 
konnten war die Dokumentation doch Essig.

Die Hersteller sagen zumindest gegenüber den Kunden: Dokumentation wird 
überbewertet, ohne Doku geht auch.

Bei Waschmaschine, Laptop und Audioanlage ist es doch nicht besser. 
Technische Daten fehlen inzwischen völlig, ausführliche 
Bedienungserklärung jeden Bedienbefehls ebenfalls, und ein Handbuch wie 
bei Windows 3.1, als noch jede Applikation erklärt wurde, findest du 
schon lange nicht mehr. Im Internet findest du Anleitungen zwar 
millionenfach, aber niemals die genau zu deiner Version passende.

Da ist es kein Wunder, wenn auch Sourcen als selbsterklärend bewertet 
werden.

von Le X. (lex_91)


Lesenswert?

Michael Bertrandt schrieb:
> Ausser einem Blatt auf dem steht wo man Ohrhörer und Ladekabel
> einsteckt, hat es keine Dokumentation.
>
> Es wird weder erklärt, wie man SMS mit T9 tippt und was in den
> Wörterbüchern steckt, noch wird beim Smartphone irgendwas zur Software
> erklärt.
>
> Das war bei den allerersten Handys noch besser, da stand wenigstens drin
> wie man die Menüs bedient, aber spätestens seit dem die Dinger WAP
> konnten war die Dokumentation doch Essig.

Brauchts auch nicht. Die Dinger sind hinreichend einfach gehalten, man 
könnte auch sagen "intuitiv zu bedienen". Bin ganz froh dass heutige 
Konsumer-Elektronik nicht mehr solch rießige Papiermüllberge verursacht.
Das gilt auch für Stereo-Anlagen, Fernseher etc...

Und um gleich mal das Argument des älteren, weniger technikaffinen 
Klientels zu entkräften: das Mütterlein, das einen heutigen Fernseher 
nicht intuitiv ohne Anleitung programmieren kann würds mit Anleitung 
auch nicht schaffen. Meist scheitert es am Willen.
Seitdem ich meinen Eltern nicht mehr jeden Mausklick vorkaue sondern sie 
selbst denken lasse kommen die viel besser zurecht...

Michael Bertrandt schrieb:
> und ein Handbuch wie
> bei Windows 3.1, als noch jede Applikation erklärt wurde, findest du
> schon lange nicht mehr.

Schon witzig dass du Win3.1 als Musterbeispiel heranziehst.
Wenn ich mich recht erinnere hatten die Programme die mitgeliefert 
wurden (Paintbrush, Writepad, Dateimanager...) Anleitungen 
(Hilfe-Dateien) in der Größenordnungen von 1-3 Bildschirmseiten.

Da stand dann sinngemäß:
OK - Klicken sie hier um zu bestätigen
Abbrechen - Klicken sie hier um abzubrechen
Datei Speichern - Klicken sie hier um zu speichern...

Völlig nutzlos, Doku um der Doku Willen. Hauptsache Papier erzeugt.

Ne du, früher war nicht besser. Nur anders.

On-Topic:
Doku macht Arbeit, ja. Meist wird die Doku auf später verschoben, aber 
später steht ja schon das nächste Projekt an.

Aussagekräftige Kommentare kann der Entwickler noch relativ einfach 
einstreuen (ganz wichtig: das "wieso" beschreiben. Das "was" steht ja 
schon im Code).

Den größten Nutzen, vor allem auf einem abstrakteren Standpunkt auf 
Systemebene bieten Diagramme.
Flussdiagramme, Klassendiagramme, State-Machines usw.
Auch wenn bunte Bilder verpönt sind und den Opis oft das Grauen bei 
"Buzzwords" wie UML kommt: der Mensch erfasst komplexe Sachverhalte 
immer noch am Besten visuell. Auch lässt sich in Bildform eine Unmenge 
an Informationen auf wenig Raum darstellen.
Aber das macht eben extra Arbeit (Tools besorgen, erlernen, Doku 
anlegen, pflegen...).
Und natürlich muss diese Doku auch aktuell gehalten werden. Da 
scheiterts oft.

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

Hannes Jaeger schrieb:
> Das ist der sogenannte Heldenansatz

> Alternativ wird Wegwerfsoftware erstellt

> die
> Fahrerflucht bzw. Verbrannte Erde

> noch das "drive by shooting"
Einfach wunderbar! Ich finde, du hast die gesamte Problematik richtig 
gut auf den Punkt gebracht.

: Bearbeitet durch User
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.