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
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.
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.
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.
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.
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>
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.
♪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.
♪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?
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.
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
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...
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.
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
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...
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..
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.
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.
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.
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.
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
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
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.
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!
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.
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.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.