Ich arbeite seit Mitte des Jahres für einen Großen in der Branche, habe vorher bei einem Zulieferer für embedded-Produkte (hardware und firmwarw) gearbeitet und habe so meine Probleme, mich in den neuen Job reinzudenken. Anders als bei meiner alten Firma wo es auf Effizienz ankam, haben wir als Endhersteller einen sehr ausgeprägt formalen Herstellungsprozess für unsere Produkte und dieser umfasst auch die firmware. Nach den Aussagen der Kollegen ist dieser Prozess in den letzten 2 Jahren 3x upgedatet worden - zuletzt im Frühjahr. Seither müssen fast doppelt so viele Dokumente ausgefüllt und unterschrieben werden, bis es mit der Programmierung losgeht, als früher. Die Sache ist so strange, dass einige Entwickler praktisch ausschließlich damit befasst sind, Dokumente zu schreiben und zu prüfen und 2 sollen das auch zum Anlass genommen haben, zu kündigen. Auch ich bin angeblich für jemanden eingetreten, der das Handtuch geworfen hat und wieder entwickeln will. Nachdem ich mich jetzt etwas eingearbeitet habe und das Ganze überschaue, stelle ich fest, dass auch bei mir praktisch 2/3 der Zeit für Dokumente, Planung und Besprechung draufgeht und dies vor allem deshalb, weil nach fertiggestellter Planung wieder einer kommt und alles umwirft. Jetzt zum Oktober hat es nochmal eine Änderung gegeben und es sind nochmals 3 neue Dokumente zu machen, bis man programmieren darf. Das eben gestartete Projekt hat sich aber schon fast 2 Monate hingezogen, bis alle Unterschriften da waren und jetzt wird es sich nochmal länger, wenn was gestartet wird. Das kann doch nicht sein, denke ich mir. Auch anderen stößt das sauer auf und jetzt hat wohl schon wieder einer gekündigt und die Firma verlassen. Wird Software heute nur noch auf dem Papier gemacht? Leider mangelt es mir an Erfahrung und ich kann das nicht so einschätzen, deshalb wollte ich hier fragen, wie das bei euch ist. Wie läuft ein Softwareprozess bei euch üblicherweise ab? Was ich z.B. aus der vorherigen Firma nicht kannte: - Compatibility Check : Die einzusetzende Software wird daraufhin geprüft, ob sie fähig ist, eine firmware für die zu nutzende Hardware zu erzeugen und ob sie da auch für künftige hardware kann - dabei sind allemöglichen Enventualitäten zu prüfen - Cross Usage Check : Die zu erstellende Software wird daraufhin analysiert, ob sie zu der alten passt, zu welcher Hardware sie passt und wie man Module strukturieren müsste, damit zukünftige Module zu zukünftiger hardware passen, dabei wird sie meistens nur für eine einzige Hardware und nur zu diesem zweck entwickelt - Module Re-usage Check : Alle Softwareteile werden geprüft, ob sie mal wiederverwendbar sind oder durch bereits erstellte Module erstellt werden kann, um Zeit zu sparen, dabei sind meisten alles kleine Insellösungen - Third-Sourcing Check: Alles wird geprüft, ob man Teile davon kaufen kann und was das für Integrationsaufwände bedeuten könnte. Das ergibt in der Regel eine Riesensuche ohne Ergebnis und wenn, da zu unmöglichen Konditionen und Preisen mit gewaltigen Anpassungsaufwendungen - Outsourcing Check : Alle Module werden daraufhin geprüft, ob sie so gut beschreibbar sein werden, dass sie im Fall eines Projektverzugs auch outgesourced werden können, obwohl so gut wie nie was outgesourced wird und so geht es in dem Modus weiter. Ich meine, es sind bis zu 20 Dokumente, die für das Projektmanagement erstellt werden müssen, um sicherzustellen, dass nicht zu wenig und nicht zu viel gemacht wird und alles muss immer upgedatet werden, sobald irgendjemand an den Lastenheften was ändert. Auf diese Weise wird die Software quasi in der Theorie für mehrere Wege durchgeplant, um dann zu sehen, dass ein anderer Weg der billigere wäre und alles wird wieder umgeschmissen und alles wieder neu gemacht. Gefühlt dauert alles 3x länger, als es müsste.
Wie es aussieht, schreibst Du gerne. Dann ist das doch genau das richtige für Dich.
http://en.wikipedia.org/wiki/Cover_your_ass ...it describes "the bureaucratic technique of averting future policy accusations of policy error or wrongdoing by deflecting responsibility in advance". It often involves diffusing responsibility for one's actions as a form of insurance against possible future negative repercussions.It can denote a type of institutional risk-averse mentality which works against accountability and responsibility, often characterized by excessive paperwork and documentation, which can be harmful to the institution's overall effectiveness. The activity, sometimes seen as instinctive, is generally unnecessary towards accomplishing the goals of the organization, but helpful to protect a particular individual's career within it, and it can be seen as a type of institutional corruption working against individual initiative.
Hallo, ich arbeite zwar noch nicht wirklich, aber auch ich habe mitbekommen, dass sobald ein neuer/unerfahrener Chef kommt, an allen Ecken und Enden Zeit gespart werden soll, was ungefähr den 10fachen Zeitaufwand ergibt...
Sowas kommt halt raus wenn "von Oben" "Verbesserungen" eingeführt werden, von Leuten die noch nicht mal ein Hello World hinbekommen, also BWL-Erbsenzähler, "Berater" und anderes nutzlose Esser. Da hilft nur eines: schnell wieder weg.
So einfach ist das nicht mit dem "schnell wieder weg" bin ja gerade erst eingetreten. Was ich eher im Sinn habe, wäre Veränderungen einzubringen, bzw konkrete Umgehensweisen, wie man solche Prozesse lebt, ohne sich kaputtzumachen und trotzdem noch voranzukommen, was ja erwartet wird. Ausserdem: Um wegzukommen, müsste man auch erst was Besseres finden.
Ich arbeite in einer kleineren Firma, wo sich die Situation faktisch gegenteilig darstellt. Sprich Chaos herrscht... Spezifikationen werden am Laufband geändert, etc... Ich hätte gerne mehr Planung, aber was du schreibst tönt auf die andere Richtung sehr abschreckend... der golde Mittelweg wäre eine gute Sache...
> Schade, dass es hier nur hirnlose Schwötzer gibt, die nicht die Frage > beantworten, sondern nur dumme Kommentare abgeben. werfe nicht mit Steinen im Glashaus, die gelöschten Postings meinst du aber nicht? dann ist dir nicht mehr zu helfen, arbeite + mache Fehler + lerne daraus und du kommst am Ende zu den Weisheiten die du hier anprangerst. Nennt sich dann Lebens- und Berufserfahrung, und versuche nicht etwas zu verbesseren wo du ganz unten stehst, das will keiner von dir und wird keiner von dir akzeptieren, aber du wirst dich aufreiben, einsetzen und am Ende frustriert sein, wofür und weshalb bitte? Regeln erlernen, nicht die technischen, Regeln einhalten und danach Handeln und Leben! Nur welche sind die richtigen?
Was möchtest du denn ändern? 2/3 für Planung und Dokumentation zu 1/3 Implementation halte ich für ein recht gutes Verhältnis. In meinem eigenen Bereich rechne ich nur rund 25% für die Implementation. Wenn die Gefahr besteht, dass sich das Lastenheft ändert, und die gesamte Einwicklung mehr als nur wenige Wochen dauert, ziehe ich dann aber iterative Modelle vor. Damit kann ich zum Einen immer wieder abklopfen ob sich alle Beteiligten noch "einig" sind und zum Anderen kann ich mich den in kürzeren Abständen mit der Implementation befassen.
@ELO : Ich sage ja, Du bist ein Schwätzer. Einer wie wir in der oberen Etage haben. Die Frage hast Du nicht beantwortet, weil ihr offenbar sowas gar nicht habt, es nicht lebt, oder euch nicht darum kümmert. Oder es kümmert nur Dich nicht, oder Du bist auch ein Anfänger. In all diesen Fällen kannst Du nichts zur Frage beitragen. Warum trollst Du nicht woanders rum?
Die Idee hinter diesen Prozessen ist häufig, dass man auch mit schlechten Programmierern schwere Fehler vermeiden möchte. Sprich man versucht so künstlich ein formales Nachdenken über das Tun zu erreichen. Das Ergebnis ist, so weit wie ich das bislang gesehen habe, nicht gerade gut, aber auch nicht furchtbar. Dadurch dass man da so viel Papierkram machen muss, und gleichzeitig zu aufwändige Architekturen heraus kommen, brauchen solche Firmen sehr viel mehr Mitarbeiter als im alternativen Modell. Das alternative Modell ist das "Heldenmodell". Man hat einen oder eine Hand voll Helden, und die machen das einfach. So wurde zum Beispiel C entwickelt und UNIX, oder LISP, oder sogar der Anfang von Linux. Wenn die "Helden" gut sind, kommt dabei was richtig Gutes heraus. Sind die "Helden" aber schlecht, so kommt absoluter Mist dabei heraus. Ein gutes Beispiel für das "Heldenmodell" war die Firma Cray. Die haben mit 2 Dutzend Leuten Supercomputer gebaut. Einer hat die Architektur gemacht und die logischen Funktionen geschrieben, die anderen haben die in ECL implementiert und sich um Kabellängen und die Kühlung gekümmert. Die verbleibende Hälfte bestand aus dünnen Frauen die die Rechner verkabelt haben. Ich glaube er spricht über diese Art der Projektarbeit hier in diesem Vortrag: http://www.youtube.com/watch?v=vtOA1vuoDgQ
@Neueinsteiger: Sag mal, geht's noch?! Wenn du hier einen Thread eröffnest, musst du auch die Antworten akzeptieren, selbst wenn sie vielleicht nicht das enthalten, was du gerne hören willst. Elo hat völlig recht, wenn er schreibt: Elo schrieb: > werfe nicht mit Steinen im Glashaus, Ich bemitleide deine erfahrenen Kollegen, die müssen sich von dir Grünschnabel wahrscheinlich anhören, was sie alles falsch machen und wie du die Prozesse viel besser gestalten würdest.
Christian Berger schrieb: > Die Idee hinter diesen Prozessen ist häufig, dass man auch mit > schlechten Programmierern schwere Fehler vermeiden möchte. Die Programmierer müssen noch nicht mal schlecht sein - es reichen schon viele Beteiligte, wechselnde Beteiligte, unterschiedliche Firmen, Abteilungen, Interessen, Prioritäten etc.
> @ELO : Ich sage ja, Du bist ein Schwätzer. danke fürs Gespräch, der zweite Poster hat es ja schon auf den Punkt gebracht, der Schwätzer ist der TO also du, > Einer wie wir in der oberen Etage haben. kann nicht sein, mich gibt es in oberen Etagen nicht, ich bin EK nicht ohne Grund, > Die Frage hast Du nicht beantwortet, du hast die Antwort nur nicht verstanden ...! dein Problem > weil ihr offenbar sowas gar nicht habt, es nicht lebt, oder euch nicht > darum kümmert. doch ich habe auch solchen Kram um mich herum, nur ich bestimme was das Ziel ist und was ich dazu brauche, mehr nicht - eher weniger, Punkt! Kümmern muß ich mich selber um Alles, aber wirklich alles, und kontrollieren und Anleiten muß ich solche wie dich, leider sind die mir nicht disziplinarisch und abhängig unterstellt, Morgen muß ich ein Wörtchen mit der BNA in BN oder Bln. plaudern, mal sehen wie weit ich dort so komme! Solche kleinen Problemchen wie du sie hast erledige ich in der Pause oder zwischendurch als Ablenkung - nicht als Erholung! > Oder es kümmert nur Dich nicht, oder Du bist auch ein Anfänger. ja genau, ich bin ein Anfänger, und mich kümmert mein Dasein überhaupt nicht, nur gut dass ich daran noch nicht verzweifelt bin. > In all diesen Fällen kannst Du nichts zur Frage beitragen. lerne zu Verstehen und zu Begreifen, aber du hast ja mit deiner Arbeitsaufgabe schon so viel um die Ohren, andere erfahrene Leute haben sich das nicht mehr antun wollen, dafür gibt es solche Frischlinge wie dich, die kann man noch hinhalten und verheizen, solange die an dem Papierkram rumdoktorn hat man die unter Kontrolle und bekommen die auch keine höheren Aufgaben. > Warum trollst Du nicht woanders rum? fragt der Obertroll dieses Treads! Gratulation für deine Weitsicht und deinen Großmut! Stimme dem nur zu, da kannst du Drehen und Wenden was du willst, du hast ein Problem nicht wir! Dir ist nicht zu helfen, aber schmeiß ruhig weiter mit Dreck und Ausdrücken, passt so richtig gut auf die ganzen unfähigen Frischlinge! Den Fakt muß ich dann mal überleiten in den Nacbarthread, da ist auch so ein Jüngling mit großen Aufgaben und Ideen, der denkt er wäre der Macher und Lenker!
Elo schrieb: > Den Fakt muß ich dann mal überleiten in den Nacbarthread, da ist auch so > ein Jüngling mit großen Aufgaben und Ideen, der denkt er wäre der Macher > und Lenker! Na hoffentlich sind das nur unrühmliche Ausnahmen und nicht die viel zitierte "Generation Y" - ansonsten Gute Nacht, Deutschland...
Woher resultiert eigentlich deren Wille etwas zu verbessern oder zu verändern? Die kennen doch weder die Basics noch die Zusammenhänge, also die wirklichen sozialen und der ganzen Hirarchie! Früher war ebend alles anders und etwas besser, für den Einzelnen wie die Gesellschaft. Weil man durch Härte und Gehorsam an sich zum Individum erkoren wurde, nicht durch Klicki Bunti und Herrschaft über Bits und Bytes u. Frickelei. Leider muß sich die heutige Generation um die 40 bis 55 mit den ganzen Bubis herumschlagen, und den soziales wie leistungsangpasstes Verhalten beibringen. Den einen Chef freuts wenn er solche Nerds füttern kann, nur begreifen diese Typen nicht ihre Lage. wirklich nur schlimm, ging schon kurz nach meinen Jahrgang mit ähnlicheh Eskapaden los, Bauchpinselei + Analakrobatik, nur dumm dass solche Verhaltensmethoden auch noch funktionieren, man braucht halt immer wieder irgendwelche abhängigen moralisch minderen Individuen um gewisse Aufgaben zu erledigen.
Bei mir ist es ähnlich. Die Dokumente, die du nennst, kenne ich nicht. Aber wir haben anderen. Und Papier Aufwand macht etwa 80% der Entwicklungszeit. Und mit der Programmierung darf erst angefangen werden, wenn Dokumente vertig sind. Ich glaube das hängt von der Branche ab. Für WebApp ist halt nciht so wichtig, wenn das Programm Bag hat und nicht mehr wartbar ist, wenn der Autor mal kündigt. Im embedded Welt mit kritischen Software denkt man mehr über die Sicherheit und darüber, "was wir machen werden, wenn...".
Neueinsteiger schrieb: > So einfach ist das nicht mit dem "schnell wieder weg" bin ja gerade erst > eingetreten. Kündigungsfrist einhalten und wech. Schon mal was von Probezeit gehört? > Was ich eher im Sinn habe, wäre Veränderungen einzubringen, Eher chancenloses Vorhaben, als Neuling und machst dich eher unbeliebt und wenn du noch in der Probezeit bist.... > bzw konkrete Umgehensweisen, wie man solche Prozesse lebt, ohne sich > kaputtzumachen und trotzdem noch voranzukommen, was ja erwartet wird. Entweder mir passen die Vorgehensweisen oder nicht, dann ziehe ich die Konsequenzen. Klingt irgendwie nach "Wasch mit den Pelz aber mach mich nicht nass" > Ausserdem: Um wegzukommen, müsste man auch erst was Besseres finden. Hast du schon angefangen zu suchen? Nein? Dann ist die Situation auch nicht so schlimm.
Neueinsteiger schrieb im Beitrag #3830862: > Schade, dass es hier nur hirnlose Schwötzer gibt, die nicht die Frage > beantworten Was war jetzt eigentlich deine Frage? Bei deiner Textwand ganz oben weiß doch niemand so recht, was du willst.
Elo schrieb: > Weil man durch Härte und Gehorsam an sich zum > Individum erkoren wurde, nicht durch Klicki Bunti und Herrschaft über > Bits und Bytes u. Frickelei. In welcher Firma arbeitest du?!
Christian Berger schrieb: > Kabellängen und die Kühlung Hab mir das auf youtube angesehen. Aussen war ein Ring von Elektronik, und innen waren die Verbindungskabel. Sah aus wie Steinwolle , oberschenkeldick übereinandergeschichtet auf ca. 100cm. Nur dass es keine Steinwolle war sondern dünne Kabel die quer durch den Rechner liefen. Wenn da mal ein Kabel abriss ... ein Alptraum. Mir ist ganz komisch geworden.
sehr netter link mit der firma Cray, danke. ich glaube, dieses beispiel zeigt die problematik deutlich: solange etwas von 3 leuten gemacht wird und sie ewig dran bleiben, kann die ganze orga auf kleiner flamme gekocht werden. heutige grossfirmen sind aber aktienorientiert und müssen bilanzen schönen, deshalb können sie nicht einfach investieren sondern müssen budgetieren, zudem sind sie riesengross und zu leicht zu steuern wie tanker deshalb brauchen die kapitäne irgend ein system, mit dem sie feedbak von unten holen und das sind eben die zahlen also liefern wir ihnen zahlen, powerpoint folien, dokumente und alles was sie wollen ein punkt muss aber gesehen werden: firmen die wie cray in den 70ern in der garage produziert haben, hatten keine dokumentations anforderungen, keine zulassungs normen und keine abfall entsorgungsrichtlinen, es gab kein emv und sonstiges. das was diese garagenfirmen zusammengeschustert haben, wäre heute nicht zuzulassen und auch nicht zu verkaufen deshalb braucht es mehr leute für die gleiche sache
Ich habe das in ähnlichem Ausmass zuletzt in den USA erlebt. Da haben wir ein Projekt gemacht, welches etwa 18 Monate dauerte. Aufgrund von Fluktuation war von den US-Mitarbeitern von etwa 20, die das Projekt gestartet hatten, am Ende noch einer übrig, alle anderen hatten die Firma verlassen, dafür kamen dann andere. Wobei "verlassen" in der Regel ein 24 Stunden Zeitraum bedeutete. Ohne diese extreme Dokumentationspflicht wäre das Projekt gescheitert, so wurde es trotz der erheblichen Fluktuation zwar etwas verspätet, aber doch erfolgreich abgeschlossen. Die neuen Mitarbeiter hatten damit zumindest die Chance, sich in die Ergebnisse der gegangenen einzuarbeiten und es wurde nicht jedesmal von vorne angefangen. Vor dem Hintergrund machen solkche Regeln durchaus Sinn, ob man das 1:1 nach Deutschland übertragen sollte, ist eine andere Frage. Gruss Axel
Ich lebe noch im Elfenbeinturm. Wie wird da draussen eigentlich ein richtiges embedded System (vllt. sicherheitskritisch) dokumentiert? - Formale Methoden ala UML/SysML? - Textformate (Office)? - alles in Anforderungsmanagementtools (Kann man da Zwischenergebnisse dokumentieren?)? - Vor allem Codedoku ala doxygen und git? - Spezielles Tool in jeder Firma? - Papier und Bleistift? Die Frage ist erst gemeint und interessiert mich wirklich.
Ein richtiges Embbedded-System wird nicht dokumentiert, es "steht ja alles im Code". (Zitat: Software-Entwickler bei uns)
Moin heißt euer Kunde zufällige Volksw... . Kommt mir so bekannt vor. Ich hatte auch von einer kleinen Firma zu einem großen Zulieferer gewechselt. Ich dachte auch am Anfang noch zu entwickeln und jetzt nur noch Papier und BlaBla. Meine Kollegen haben auch ein Problem damit, entweder man macht das Beste daraus oder sucht sich eine neue Herausforderung. Leider ist es nicht mehr gewollt in Deutschland zu entdecken, kommt mir jedenfalls so vor. In diesem Sinne noch eine schöne Woche.
Hannes schrieb: > Ein richtiges Embbedded-System wird nicht dokumentiert, es "steht ja > alles im Code". > (Zitat: Software-Entwickler bei uns) Ja, guter Code ist selbsterklärend. Wusste garnicht das das eine neue Erkenntnis ist, steht auch so im Buch "Weniger Falsch programmieren": http://download.e-bookshelf.de/download/0002/2323/69/L-G-0002232369-0004258120.pdf MfG,
OK. Ich meinte eher das Projekt. Es sind ja bis zu 80% Dokumentationsaufwand... Alles Codekommentare??
Karl Klarsicht schrieb: > Hannes schrieb: >> Ein richtiges Embbedded-System wird nicht dokumentiert, es "steht ja >> alles im Code". >> (Zitat: Software-Entwickler bei uns) > > Ja, guter Code ist selbsterklärend. > Wenn er fehlerfrei wäre. Ist er aber nicht. Gruss Axel
Hannes schrieb: > Ein richtiges Embbedded-System wird nicht dokumentiert, es "steht ja > alles im Code". > (Zitat: Software-Entwickler bei uns) Solche Leute kann man getrost entlassen; die Firma wird dadurch keinen Schaden erleiden. Karl Klarsicht schrieb: > Ja, guter Code ist selbsterklärend. Das funktioniert vielleicht in der Theorie, aber nicht in der Praxis. Außerdem geht es bei Code-Kommentaren eher nicht darum, was der Code macht, sondern was eigentlich der Sinn dahinter ist. Warum wurde etwas so umgesetzt und nicht anders.
:
Bearbeitet durch User
Zu den Helden kann man vielleicht noch etwas sagen. Es gibt Helden und einsame Helden. Die Helden leisten zusammen mit wenigen Kollegen in guter Zusammenarbeit viel. Die einsamen Helden sind die typischen merkwürdigen Typen die sich tagelang einschließen, die ausflippen wenn jemand anderes ihren Code anfasst, die meist irgendeine sehr dubiose, selbst ersponnene Software-Architektur und ranziger Programmiersprache als die einzig wahre ansehen und auf der bestehen. Nicht teamfähig, unbelehrbar, usw. Es gibt immer noch eine ganze Menge kleiner Klitschen die um einen einsamen Helden herumgebaut sind. Da hat es der einsame Held geschafft, sich unentbehrlich zu programmieren und/oder alle anderen weggebissen. Das geht manchmal so weit, dass der einsame Held den einzigen Rechner in der Firma mit der richtigen Konfiguration hat, auf der sich die Software bauen lässt. Mit irgendeiner Schrott-IDE. Da sind mir Firmen, bei denen zu 2/3 Dokumentation geschrieben wird lieber, als so einen Satansbraten an der Backe zu haben.
Mark Brandis schrieb: > Hannes schrieb: >> Ein richtiges Embbedded-System wird nicht dokumentiert, es "steht ja >> alles im Code". >> (Zitat: Software-Entwickler bei uns) > > Solche Leute kann man getrost entlassen; die Firma wird dadurch keinen > Schaden erleiden. Man verliert halt "nur" die Programmierer die das was Systemarchitekten spezifiziert und die Projektmanager durchdrücken in verkaufbare Produkte umsetzten... Wobei Dokumentation ein weiter Begriff ist der auch die Spezifikation und Test/Verifikationsprotokolle enthält. Diese gehören natürlich nicht als comment in den Code sondern extra festgehalten. > > Karl Klarsicht schrieb: >> Ja, guter Code ist selbsterklärend. > > Das funktioniert vielleicht in der Theorie, aber nicht in der Praxis. > Außerdem geht es bei Code-Kommentaren eher nicht darum, was der Code > macht, sondern was eigentlich der Sinn dahinter ist. Warum wurde etwas > so umgesetzt und nicht anders. Doch das funktioniert sehr gut - Programmierer denen verboten wird ihren Code irgendwo anders zu erklären als im Code selbst schreiben besser wartbaren/verständlichen Code - iss ja klar die wollen sich nicht selbst ins Knie schiessen. Und wenn man code übernimmt oder weiterpflegt wie z.B libraries oder VHDL-Code verrät ein Blick in den Quellcode schnell was wirklich drin ist. Ein parallel geführte Code-beschreibung dagegen ... lückenhaft, bezieht sich auf einen anderen Revisionsstand enthält nicht die letzten Bugreports/workarounds ... Ehrlich, wenn ich wissen will was bspw. in den Arduinolibraries abgeht dann schau ich mir deren Quelltext an und nicht die Beschreibung. MfG,
Elektroniker schrieb: > ein punkt muss aber gesehen werden: firmen die wie cray in den 70ern in > der garage produziert haben, hatten keine dokumentations anforderungen, > keine zulassungs normen und keine abfall entsorgungsrichtlinen, es gab > kein emv und sonstiges. Naja, also erstens waren in den 1970gern die EMV-Richtlinien in den USA noch deutlich höher als heute, die Dinger durften quasi nichts abstrahlen, zweitens sind die Crays wahrscheinlich sehr gut dokumentiert, schließlich wurden da ja unterschiedliche Teile des Designs von unterschiedlichen Leuten gemacht. Das Entscheidende bei Cray war, dass die die Geräte so einfach wie möglich gebaut haben. Der Cray I besteht aus 3 Typen von ICs. (OK 4 weil ein Typ auch in einer selektierten Version vor kommt) Damals musste auf den Kisten nicht unbedingt das Betriebssystem laufen, dass irgendjemand mal in einer völlig anderen Situation für passend befunden hat. Da musste man keine internen Normen erfüllen, die keine Vorteile bieten.
Mark Brandis schrieb: >> Ja, guter Code ist selbsterklärend. Etwas, was ich immer wieder höre und leider am Thema vorbei geht. Die Dokumentation soll das erklären, was der Code nicht erklärt. Will man Code so ausdrücklich und klar formulieren, also immer mit funktionellen Begriffen, wird er ebenfalls unlesbar. Und noch ein weiterer Punkt: Im Code steht nur, was gemacht wurde. Um es zu testen zu verstehen und vor allem implizite Einschränkungen zu erkennen, die gemacht oder unterlassen wurden, ist es nötig, auch zu wissen, was gemacht werden sollte. Ohne eine ausdrückliche Vorgabe ist ein Code nicht klassifizier- und testbar. Und mit einer klaren Vorgabe, ist die Funktion des Codes schon dokumentiert :-)
Wenn ich zu einem Projekt komme, das vor die Wand gefahren wurde, liegt der entscheidende Fehler häufig in fehlender Dokumentation. Bei solchen Aufträgen höre ich dann "Der Programmierer/Elektriker/Schlosser/usw. kommt nicht klar. Das ist die Anlage, bring mal zum laufen." Zum großen Schrecken von Einkauf, Kunde und Bauleiter beginnt das "bring mal zum Laufen" häufig mit einer Doku, anhand der ich offene Punkte finden und beheben kann. Ohgoto, ein Tag Stillstand im Projekt! Daß damit aber viele Unwägbarkeiten und sinnloses Rumdoktern vermieden werden, wird im Lauf des Projektes offensichtlich.
:
Bearbeitet durch User
Früher, zu reinen HW-Zeiten, hat ein Schalt- oder noch dazu
Funktionsplan völlig ausgereicht.
Da aber heute nix mehr rein HW-implementiert wird, also alles in der FW
und SW > Code drin steckt, hat das nicht nur Vorteile.
Die Leute, welche mit solchen Umständen tägl. kämpfen müssen, sollten
sich dessen doch bewußt sein.
Ohne wirklich gute und reale Doku ist jede HW durch die komplette
Abhängigkeit zum Code in der SW nur noch Grütze wert.
Also sollte man aus der Erkenntnis doch verstehen warum das ganz von
Nöten ist.
Dass solche trockenen Übungen und Papier- wie Dokumentationskram auch
gemacht werden muß ... wen trifft das denn dann immer > Neuzugänge und
untere Stufen in der Hirarchie.
Also das Beste daraus machen und versuchen da weg zu kommen.
Es gibt da auch noch ein Sprichwort und eine bis heute durchgehende
Weisheit
> Dummheit schafft Freizeit < , vllt. ist das die Lösung zu ner anderen
Beschäftigung?
Als ich ins Berufsleben gestartet bin wollte ich auch nur eins: Programmieren, C-Code hacken, möglichst elegante Lösungen finden, beweisen dass ichs (technisch) drauf hab. Ich war entsetzt wie wenig Zeit eigentlich fürs Programmieren aufgewandt wird. Meine Schätzung sind: 20%, wenn ein neues Feature implementiert werden soll (wobei die Anforderungen schon stehen!) und vielleicht 2-3% wenn ein Bug gefunden und gefixt werden soll. Der Rest ist Papierkram und Analysen/Tests. Aber, dadurch unterscheiden wir uns halt von den Bastlern. Mittlerweile halte ich den Weg, der hier gegangen wird, für den richtigen. Übertreiben sollte mans aber mit dem Papierkram auch nicht. Wie immer, ein gesundes Mittelmas machts.
Helge A. schrieb: > Wenn ich zu einem Projekt komme, das vor die Wand gefahren wurde, liegt > der entscheidende Fehler häufig in fehlender Dokumentation. Bei solchen > Aufträgen höre ich dann "Der Programmierer/Elektriker/Schlosser/usw. > kommt nicht klar. Das ist die Anlage, bring mal zum laufen." Zum großen > Schrecken von Einkauf, Kunde und Bauleiter beginnt das "bring mal zum > Laufen" häufig mit einer Doku, anhand der ich offene Punkte finden und > beheben kann. naja da brauchst de keine Software-Doku sondern eine Inbetriebnahmeanleitung oder ein Manual, oft hilft auch eine produktspezifikation. Und bei Software gibt es immer Source - ist der selbsterklärend brauchts keine parallel gepflegte Doku. oder man schreibt den source so das eine Doku/Schnittstellenbeschreibung daraus tollgestützt extrahierbar (bspw. doxygen) ist. MfG,
Wenn es außer dem Quelltext keine Doku (also auch keine schriftliche Anforderung) gibt, heißt das doch, daß jemand anhand einer mündlichen Anweisung programmiert? Arbeiten aufgrund von Gerüchten... Hört sich nicht gerade professionell an.
Moinsen, Ich finde es echt süß was Ihr hier über ein paar Dokumente klagt. Ich entwickle sicherheitskritische Software für Medizintechnik. Stichworte: IEC62304, FDA, sFDA, MPG, Was meint Ihr was da alles für Dokumente geschrieben werden müssen um überhaupt in bestimmten Ländern verkaufen zu können. Das gehört zumindest in unserer Branche zum Alltag dazu. Man sollte sich vorher informieren in welcher Branche welche Arbeitsweisen etabliert sind. Die Luft- und Raumfahrt, Automobil-Branche steht dem sicher in nichts nach da auch hier entsprechende Vorschriften (Standards) zu finden sind. (Verwaltete Sicherheit) Grüße
>naja da brauchst de keine Software-Doku sondern eine >Inbetriebnahmeanleitung oder ein Manual, oft hilft auch eine >produktspezifikation. Und bei Software gibt es immer Source - ist der >selbsterklärend brauchts keine parallel gepflegte Doku. oder man >schreibt den source so das eine Doku/Schnittstellenbeschreibung daraus >tollgestützt extrahierbar (bspw. doxygen) ist. Man merkt, dass du schon länger keine Doku mehr geschrieben hast ;-) Solltest Du mal üben.
Elo schrieb: > Nennt sich dann Lebens- und Berufserfahrung, <irony> Wer braucht sowas ? Kann man doch bestimmt outsourcen ;-) </irony> Grüße Andreas
alter sack schrieb: > Kündigungsfrist einhalten und wech. Schon mal was von Probezeit gehört? Der Kündigungsschutz beeinflusst nur das Handeln des Arbeitgebers und auch nur wenn es genug Beschäftigte gibt. Ein Arbeitnehmer kann JEDERZEIT fristgerecht kündigen, egal ob Probezeit oder nicht. Allenfalls macht es einen ungünstigen Eindruck, mehr nicht. Hannes schrieb: > Ein richtiges Embbedded-System wird nicht dokumentiert, es "steht ja > alles im Code". Ja, Wunschdenken von Programmieren, nur das jeder, wirklich jeder, da seinen eigenen Stil hat. Karl Klarsicht schrieb: > Ja, guter Code ist selbsterklärend. Wenn man sparsam aber effektiv mit Kommentaren umgeht. Axel Laufenberg schrieb: > Wenn er fehlerfrei wäre. > > Ist er aber nicht. Das kann man nicht generell sagen, aber man kann eine zweite Meinung einholen und wenn kein Fehler gefunden wird, stehen die Chancen für Fehlerfreiheit nicht schlicht.
Autor: Andreas H. (ahz) Datum: 09.10.2014 12:09 schrieb > Elo schrieb: >> Nennt sich dann Lebens- und Berufserfahrung, <irony> Wer braucht sowas ? Kann man doch bestimmt outsourcen ;-) </irony> Grüße Andreas Hi Andreas, bei dir ist die Orthografie > Rechtschreibung wohl auch schon outgesourcet? Irony mit Y , alles klaro, oder hat deine Tastatur nur ein Problem? Das Smilie am Ende inkl. Ironie ..... doppelte Verneinung? Zu dem anderen Fakt > Auslagern von Lebens- u. BE > scheint schon bei Vielen so zu sein, oder noch nie welche wirkl. gehabt zu haben, denn was man nicht hat, braucht man auch nicht, und muß man nicht Auslagern! Nur mit den Folgen des Defizites muß dann jeder selber oder seine Mitmenschen leben. Manchen verhilft das zu einem sehr ruhigem Arbeits- also Berufsleben, aber meist klappt das nur in größeren Firmen mit dem richtigen BR u. leistungsfähigen wie tolleranten Kollegen, wenn die das so lange mitmachen. Zu dem ganzen Dokumentations- und Nachweiswahn, ist ja nichts anderes wie in der Buchhaltung und der IOS 0815. Die Firma / das Projekt soll nicht abhängig von ihren fähigsten Leuten sein, denn die brauchen sowas eigentlich nicht. Klaro schrieb zu Hannes Beitrag > Ja, Wunschdenken von Programmieren, nur das jeder, wirklich jeder, da > seinen eigenen Stil hat. wie überall im Leben privat oder berufl.: wer nicht mitkommt braucht immer was zu Lesen um so zu tun als würde er es verstehen.
Elo schrieb: > Hi Andreas, > bei dir ist die Orthografie > Rechtschreibung wohl auch schon > outgesourcet? > Irony mit Y , alles klaro, oder hat deine Tastatur nur ein Problem? http://dict.leo.org/#/search=irony&searchLoc=0&resultOrder=basic > Das Smilie am Ende inkl. Ironie ..... doppelte Verneinung? Nein, eher im Sinne von "smirk". Aber wenn Du das nicht verstanden hast macht es auch wenig Sinn es explizit zu erklären. Gruesse Andreas
Elo schrieb: > Dass solche trockenen Übungen und Papier- wie Dokumentationskram auch > gemacht werden muß ... wen trifft das denn dann immer > Neuzugänge und > untere Stufen in der Hirarchie. Na DASS kann es aber jetzt nicht sein, dass ausgerechnet den unerfahrenen Anfängern die Doku zugeschoben wird. Jeder hat seine Doku selber zu machen und die wichtigste davon, die planende, hat von den Systemern zu kommen.
Klaro schrieb: > Hannes schrieb: >> Ein richtiges Embbedded-System wird nicht dokumentiert, es "steht ja >> alles im Code". > > Ja, Wunschdenken von Programmieren, nur das jeder, wirklich jeder, da > seinen eigenen Stil hat. Wenn sich der eigene, individuelle Stil zufällig mit den Vorgaben des Styleguides im Projekt deckt, wäre mir das recht. Aber auch nur dann :-)
Elo schrieb: > Zu dem ganzen Dokumentations- und Nachweiswahn, ist ja nichts anderes > wie in der Buchhaltung und der IOS 0815. Die Firma / das Projekt soll > nicht abhängig von ihren fähigsten Leuten sein, denn die brauchen sowas > eigentlich nicht. Da frage ich mich immer wieder, warum diese ach so fähigen Helden, die sonst ja keine Gelegenheit auslassen, ihre eigene Überlegenheit zu betonen, ausgerechnet diese Möglichkeit, ihre Fähigkeiten unter Beweis zu stellen, scheuen wie der Teufel das Weihwasser.
Elo schrieb: > Zu dem ganzen Dokumentations- und Nachweiswahn, ist ja nichts anderes > wie in der Buchhaltung und der IOS 0815. Die Firma / das Projekt soll > nicht abhängig von ihren fähigsten Leuten sein, denn die brauchen sowas > eigentlich nicht. Zu einem Problem wird es dann, wenn fast nichts dokumentiert wird. Die fähigen Leute können ja auch mal abwandern und dann ist die ganze Sch.... am dampfen. Selbst ganz fähige Leute haben sicher auch Probleme nach 1-2 Jahren nach zu vollziehen, was sie damals so angestellt haben. Mit der Dokumentation kann man es auch übertreiben, stimmt.
Klaro schrieb: > > Axel Laufenberg schrieb: >> Wenn er fehlerfrei wäre. >> >> Ist er aber nicht. > > Das kann man nicht generell sagen, aber man kann eine zweite Meinung > einholen und wenn kein Fehler gefunden wird, stehen die Chancen für > Fehlerfreiheit nicht schlicht. Ich habe ja schon so einige Reviews hinter mir. Das Gesamtbild eines Projektes oder einer komplexeren Funktion haben, wenn überhaupt, nur sehr wenige. Allenfalls wird man im Review einen Teilbereich in sich auf Schlüssigkeit prüfen, ob der im Kontext funktioniert, kann man kaum prüfen. Und wenn dann im Code steht , dass 1+a gerechnet wird, wird das im Review durchgehen (Code ist ja bekanntlich selbsterklärend und da steht, dass 1+a gerechnet wird, was dann wohl so ist) , auch wenn eigentlich 1+b richtig gewesen wäre. Ein Kommentar an der Stelle, in dem erklärt wird, was der Sinn der Rechnung sein soll, führt dazu, dass solche Fehler wahrscheinlicher gefunden werden. Ein anderes Beispiel sind Funktionen, die nötig werden um Fehler in Hardware (PCB Version 0.9, längst ersetzt durch PCB 1.0 ohne den Fehler, aber wer will das schon wissen) oder Eigenheiten von speziellen Interfaces zu korrigieren und die oft in sich vollkommen sinnlos erscheinen. Nach zwei Jahren weiß kein Mensch mehr, warum die da drin sind, dann hat man die schöne Situation, dass man sich an solche Software nicht mehr traut, weil keiner (inkl. des Programmierers) mehr weiß, wozu das gut war und was passiert, wenn man es weglässt. Dann kann man aus dem Code sehr schön lesen, was der macht, aber warum der das macht, versteht kein Mensch mehr. Das sind dann die Situation, wo Code komplett neu geschrieben wird, weil der alte ja komplett unübersichtlich ist. Gruss Axel
Axel Laufenberg schrieb: > Und wenn dann im Code steht , dass 1+a gerechnet wird, wird das im > Review durchgehen (Code ist ja bekanntlich selbsterklärend und da steht, > dass 1+a gerechnet wird, was dann wohl so ist) , auch wenn eigentlich > 1+b richtig gewesen wäre. Das sieht dann so aus:
1 | c = 1+a; // addiere 2 zu b |
Oliver
Oliver schrieb: > Axel Laufenberg schrieb: >> Und wenn dann im Code steht , dass 1+a gerechnet wird, wird das im >> Review durchgehen (Code ist ja bekanntlich selbsterklärend und da steht, >> dass 1+a gerechnet wird, was dann wohl so ist) , auch wenn eigentlich >> 1+b richtig gewesen wäre. > > Das sieht dann so aus: > c = 1+a; // addiere 2 zu b > > Oliver ;) ich glaub, das war anders gemeint
mec schrieb: > Oliver schrieb: >> Axel Laufenberg schrieb: >>> Und wenn dann im Code steht , dass 1+a gerechnet wird, wird das im >>> Review durchgehen (Code ist ja bekanntlich selbsterklärend und da steht, >>> dass 1+a gerechnet wird, was dann wohl so ist) , auch wenn eigentlich >>> 1+b richtig gewesen wäre. >> >> Das sieht dann so aus: >> c = 1+a; // addiere 2 zu b >> >> Oliver > > ;) > ich glaub, das war anders gemeint Das war zwar anders gemeint, aber solche Dinge gibt es auch. Ursprünglich richtig geschrieben, zum debuggen schnell mal ein paar Werte geändert und dann einen davon vergessen zurückzuschreiben. Redundanz ist nicht das Schlechteste. Spielt natürlich alles keine Rolle, wenn man sowieso einen Updateserver hosten muss, weil Qualität keine Rolle spielt. Gruss Axel
Hallo Leute, also gleich mal vorweg: Im Berufsleben sollte es vor allem darum gehen, Spaß zu haben. Da Ihr 8 oder mehr Stunden im Büro verbringt, ist das ein großer Zeitraum in eurem Leben und es wäre doch wirklich schlimm, wenn man diese lange Zeit in Tristesse verbringen würde. Wenn Ihr nach Hause kommt, seit Ihr meistens zu Müde, noch etwas Vernünftiges anderes zu machen. Vor kurzem habe ich mit einem jungen Studenten geredet. Der hat mir doch allen ernstes erklärt, was er in seiner Hochschule gelernt hätte: Die Softwareentwikcklung soll modularisiert werden, Techniken aus der Fließbandprodkuktion werden in der Softwarentwicklung eingeführt. Jedes Softwaremodul soll so einfach gehalten werden, dass es auch ein relativ unqualifizierter Entwickler bearbeiten kann. Die Dokumentation jedes Moduls soll so gut sein, dass man den Entwickler auch leicht durch einen anderen Entwickler ersetzten kann ( gerne auch per WebEx in Inidien ). Dafür sind Prozesse notwendig, die diese Fließbandarbeit strukturieren. Der Student war sehr stolz auf das gelernte und begierig darauf, bald in so einem Prozess arbeiten zu dürfen. Da ich noch aus einer Zeit kommen, in der das Programmieren eine Art Kunstform war, in der eine Enwickler seine Kreativität ausdrücken konnte, habe ich mir folgendes gedacht: Wie dumm konditioniert muss man eigentlich sein, sich freiwillig in das Fließbandleben der Prozessstrukturen zu begeben und dieses auch noch als erstrebenswert zu empfinden? Wie schlau müssen die Erzieher gewesen sein, dieses Leben erstebenswert erscheinen zu lassen. Wie kann man jemandem das Bedürfniss nach einen erfüllten Arbeitstag abtrainieren? Wie bekomme ich die Leute dazu, ihre eigenen Bedürfnisse zu vergessen und sich als Zahnrad in das Produduktionsgetriebe einzufügen und das auch noch als die Ulima Ratio des Berufslebens zu empfinden? Leute ich sage euch: Habt gute Kontakte zu euren Kollegen, habt Spaß an der Arbeit, geht viel Kaffe trinken und löst eurch technischen Details dort. Das bringt für eure Leben, euren Beruf und eure Gesundheit viel mehr als der andere Mist, den man euch glauben machen mag.
@Siegfried (Gast) >Im Berufsleben sollte es vor allem darum gehen, Spaß zu haben. Jain. Brotwewerb ist nicht immer nur "Spaß", wobei das Wort Freude hier passender Wäre. Spaß ist passiv, wenn man z.B. einen lustigen Film anschaut. Freude erlebt man aktiv, wenn man etwas schönes erschafft (Sandburg bauen, Controller programmieren, Firma leiten). > Da Ihr 8 >oder mehr Stunden im Büro verbringt, ist das ein großer Zeitraum in >eurem Leben und es wäre doch wirklich schlimm, wenn man diese lange Zeit >in Tristesse verbringen würde. Wenn Ihr nach Hause kommt, seit Ihr >meistens zu Müde, noch etwas Vernünftiges anderes zu machen. Wohl wahr. >Dafür sind Prozesse notwendig, die diese Fließbandarbeit strukturieren. ;-) Jain. >Der Student war sehr stolz auf das gelernte und begierig darauf, bald in >so einem Prozess arbeiten zu dürfen. Idiot. Oder einfach nur jung und naiv. >Da ich noch aus einer Zeit kommen, in der das Programmieren eine Art >Kunstform war, in der eine Enwickler seine Kreativität ausdrücken >konnte, habe ich mir folgendes gedacht: Naja, vorsicht mit der Verklärung der Vergangenheit. Nicht ganz umsonst sind so Begriffe wie "Softwarekrise" aufgetaucht. Diese "Kunst" war und ist bisweilen arg chaotischer Wildwuchs und Gebastel, das mit solidem Engineering rein gar nicht zu tun hat. Um aber gewisse Qualitätsstandards zu erreichen, braucht es solide Prozesse. Ob es dann so sein muss wie hier beschrieben, sei dahingestellt. https://de.wikipedia.org/wiki/Softwarekrise >Wie dumm konditioniert muss man eigentlich sein, sich freiwillig in das >Fließbandleben der Prozessstrukturen zu begeben und dieses auch noch als >erstrebenswert zu empfinden? Wie schlau müssen die Erzieher gewesen >sein, dieses Leben erstebenswert erscheinen zu lassen. Wie kann man >jemandem das Bedürfniss nach einen erfüllten Arbeitstag abtrainieren? >Wie bekomme ich die Leute dazu, ihre eigenen Bedürfnisse zu vergessen >und sich als Zahnrad in das Produduktionsgetriebe einzufügen und das >auch noch als die Ulima Ratio des Berufslebens zu empfinden? http://www.youtube.com/watch?v=DfGs2Y5WJ14
>Youtube-Video "Charlie Chaplin - Factory Work"
Ein sehr schönes Video. Ich habe es zwar früher schon einmal gesehen,
die Szene mit der Überwachung auf der Toilette war mir allerdings
entfallen.
Da war Charlie Chaplin wohl ganz schön weitsichtig, wenn man die
Programme zur Überwachung der Aktivität der Mitarbeiter durch die
Überprüfung einer Mausbewegung bedenkt. Gottseidank sind diese Programme
nur in den USA aber nicht in Deutschland erlaubt.
Angehängte Dateien:
-
softwareFliessband.jpg
180 KB
In diesem Buch wird der Sinn der Prozessorientierung gut erklärt: "Wege aus der Softwarekrise: Verbesserungen bei der Softwareentwicklung von Patrick Hamilton"
Thread beobachten
Seitenaufteilung abschaltenBitte 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.