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.
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.
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.
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.
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.
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.
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:
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.
In diesem Buch wird der Sinn der Prozessorientierung gut erklärt:
"Wege aus der Softwarekrise: Verbesserungen bei der Softwareentwicklung
von Patrick Hamilton"
