Softwareentwicklung im Maschinenbau

Ing schrieb:
> [...]

Mimimi.

Ing schrieb:
> Anforderungsmanagement durch Scrum ersetzt wird... hatte ich bisher
> einfach nur Pech mit den Firmen oder ist das "branchenüblich"?
Wohl eher branchenübergreifend.

Welche Projekte waren denn das? Warst du als Interner dabei oder als 
Externer?

Ich war schon in einigen Firmen angestellt. Und alle mit ausufernder 
"Vorgehensmodelle, Strukturierungs- und Spezifizierungsprozesse, UML,
Requirements-Engineering, Pflicht- und Lastenheft" kamen nicht inne 
Pötte und haben keine bessere Qualität abgeliefert.

Weniger ist manchmal mehr. Aber gewiss ganz sollte man sowas nicht 
weglassen. Manche übertreiben es mit diesem Bla Bla jedoch ganz 
gewaltig.

Udo S. schrieb:
> Mein persönliches Highlight war mal einer unserer "Berater" der mit
> einem Kunden vereinbart hatte dass wir (SW-Entwicklung) "mal was
> machen", der Kunde es sich dann ansieht und dann sagt wie er es gerne
> hätte.

Ein Traum! Da kann man sich mal ein nettes Projekt ausdenken fern von 
wirtschaftlichen Zwängen, sich ein paar neue Technologien aneignen und 
ausnahmsweise mal nicht Quick-and-Dirty coden. Dass der Kunde dann am 
Ende nichts damit anfangen kann ist sein Problem...

Ing schrieb:
> Und
> dennoch geht die Entwicklung seit Jahren dahin, dass
> Anforderungsmanagement durch Scrum ersetzt wird...

Normal, weil es oft keine genauen Anforderungen gibt. Keiner weiß so 
genau was die Millionen potentielle Nutzer so genau wollen. Bei 
Facebook, WhatsApp & Co wird auch kein Lastenheft geschrieben - es 
werden diverse Dinge ausprobiert, und die die gut ankommen weiter 
ausgebaut. Dann muss man auch den Mut haben, wenig benutzte Features 
wieder einzustampfen, weil die letztlich nur Wartungsaufwand und damit 
Geld kosten.

Ing schrieb:
> Ich bin Softwareingenieur mit mehreren Jahre Beruferfahrung im
> Bereich
> Maschinenbau. Meine bisherige Erfahrung ist, dass selbst in nahmhaften
> Unternehmen dieser Branche komplexe (Hochsprachen-)Software auf
> abenteuerliche Art und Weise entsteht. Es gibt fast keinen
> Designprozess! Aus dem Studium und eigenen Projekten kenne ich viele
> Vorgehensmodelle, Strukturierungs- und Spezifizierungsprozesse, UML,
> Requirements-Engineering, Pflicht- und Lastenheft... nichtmal letzteres
> wird in der Realität konsequent gemacht, zumindest nicht für Software im
> Maschinenbau. Bei Microsoft, SAP und anderen Firmen des
> Nicht-Maschinenbau ist das zumindest besser.

Ist aussserhalb von Microsoft und SAP nicht nur im Maschinenbau so !

> Man mag zu trockenen Planungsprozessen stehen wie man will, ganz ohne
> diese Planung bricht einem ab einer gewissen Komplexität das Dach übern
> Kopf zusammen.

So isses !

> Seit über 25 Jahren sind diese Effekte bekannt! Und
> dennoch geht die Entwicklung seit Jahren dahin, dass
> Anforderungsmanagement durch Scrum ersetzt wird... hatte ich bisher
> einfach nur Pech mit den Firmen oder ist das "branchenüblich"?

Scrum ist halt der heisse Scheiss. Da wird der Bock zum Gärtner gemacht, 
Kritik ist sektenartig nicht erwünscht. Meckern über Scheiss 
Anforderungen ist Vergangenheit, sieh zu wie du ohne klar kommst. Am 
Ende steigt der Druck auf die Entwickler noch mehr, und es wird 
gefrickelt bis der Arzt kommt. Verstehe nicht, wie mancher Entwickler 
das auch noch gut findet.

Das mit dem Designprozess ist toll. Ich hatte mal so ne UML Phase, wo 
ich 10 Jahre an mehreren UML Tools mitgearbeitet hab. Hab ich sehr viel 
bei gelernt.

Kannst aber in der Praxis alles vergessen. Was ich jetzt erlebe ist, 
dass die GeschFü Morgens die Spezifikation umwirft und erwartet, dass 
paar Stunden später eine Version zum Testen bereitsteht. Da ist genau 0 
Zeit, irgendwas zu dokumentieren o.ä.

Neue Funktionen sollen im Stundentakt eingebaut werden. Zum Testen 
bleibt keinerlei Zeit.

FrustrierterComputerBastler schrieb:
> Das mit dem Designprozess ist toll. Ich hatte mal so ne UML Phase,
> wo ich 10 Jahre an mehreren UML Tools mitgearbeitet hab. Hab ich sehr
> viel bei gelernt.
>
> Kannst aber in der Praxis alles vergessen. Was ich jetzt erlebe ist,
> dass die GeschFü Morgens die Spezifikation umwirft und erwartet, dass
> paar Stunden später eine Version zum Testen bereitsteht. Da ist genau 0
> Zeit, irgendwas zu dokumentieren o.ä.
>
> Neue Funktionen sollen im Stundentakt eingebaut werden. Zum Testen
> bleibt keinerlei Zeit.

Ja, aber Clean Coden und es soll auch noch ein vernünftiges OOP Design 
entstehen. Ist ohne Planung nicht möglich, Scrum ist die Pflicht zu 
Frickelei.

Ing schrieb:
> kenne ich viele Vorgehensmodelle, Strukturierungs- und
> Spezifizierungsprozesse, UML, Requirements-Engineering, Pflicht- und
> Lastenheft... nichtmal letzteres wird in der Realität konsequent
> gemacht,

Das es so viele gibt, ist oft ein Zeichen, dass keine gut ist.

Wenn Anforderungen bekannt, konstant und formulierbar sind, dann ist das 
alles ja ganz schön. Wird z b. bei Sicherheit oft gemacht. Oder wenn man 
Programmierer hat, was bei SAP & CO oft der Fall ist.

Aber Innovation, Fortschritt geht so nicht.

Und zusammenbrechen tut es nicht an fehlenden redundanten Dokumenten, 
sondern an schlechtem Design. Egal ob in UML oder Code, es gibt halt 
Leute mit genialen Lösungen und guter Auffassungsgabe und üble Frickler 
(hat mir keiner gesagt, dass ...) und alles dazwischen.

Motzkopp schrieb:
> soll auch noch ein vernünftiges OOP Design entstehen. Ist ohne Planung
> nicht möglich,

Ein gutes Design ist erst möglich, wenn man einen Großteil der 
Anforderungen und Einsatzfälle kennt. Das ist aber bei neuen, 
innovativen Dingen erst im Projektverlauf. Wenn ich XY erfinde, baue, 
dann kann ich noch nicht wissen, was ich mit XY mache, brauche.

Darum ist refakturieren, redesignen, Funktionen wegwerfen, andere 
verbessern wichtig. Das Design muss/kann quasi erst am Ende sauber sein.

Der beste Plan ist wertlos beim ersten Feindkontakt. Oder: vergiss den 
Plan, Planung ist alles.

A. S. schrieb:
>
>
> Wenn Anforderungen bekannt, konstant und formulierbar sind, dann ist das
> alles ja ganz schön. Wird z b. bei Sicherheit oft gemacht. Oder wenn man
> Programmierer hat, was bei SAP & CO oft der Fall ist.

Die Herren aus dem Anforderungs und Produktmanagment usw waren schon 
immer bequem und denkfaul, durch Scrum und diesen Scheiss kriegen sie 
jetzt auch noch ne offizielle Legimitation dazu. Das sind die ersten, 
die der GF erzählen, wie toll das ist, sind ja schließlich damit raus 
aus der Verantwortung.


> Aber Innovation, Fortschritt geht so nicht.

Boa ej, hat man dich auch schon erfolgreich durch die Gehirnwäsche 
durch, oder was ist das fürn Managergeschwafel?

> Und zusammenbrechen tut es nicht an fehlenden redundanten Dokumenten,
> sondern an schlechtem Design. Egal ob in UML oder Code, es gibt halt
> Leute mit genialen Lösungen und guter Auffassungsgabe und üble Frickler
> (hat mir keiner gesagt, dass ...) und alles dazwischen.

Dann zaubere mir mal ein schönes DB und OOP Klassendesign hin, wenn die 
Anforderungen tagesweise bekannt werden und wieder umgeworfen werden. 
Nein, man wird aber nicht zugeben, dass das systembedingt kaum möglich 
ist, Scrum ist nicht Schuld, das liegt an den Leuten !

A. S. schrieb:
> Motzkopp schrieb:
> soll auch noch ein vernünftiges OOP Design entstehen. Ist ohne Planung
> nicht möglich,
>
> Ein gutes Design ist erst möglich, wenn man einen Großteil der
> Anforderungen und Einsatzfälle kennt.

Da sind wir uns einig !

Das ist aber bei neuen,
> innovativen Dingen erst im Projektverlauf. Wenn ich XY erfinde, baue,
> dann kann ich noch nicht wissen, was ich mit XY mache, brauche.
>
> Darum ist refakturieren, redesignen, Funktionen wegwerfen, andere
> verbessern wichtig. Das Design muss/kann quasi erst am Ende sauber sein.

Ja, dann kannst nach agil und CO ständig redisgnen oder neu machen, und 
das soll gut sein? Das ist nur teuer ! Und du glaubst ja wohl nicht, das 
eine funktionierende Frickelkei in der Praxis später noch redesigned 
wird.

> Der beste Plan ist wertlos beim ersten Feindkontakt. Oder: vergiss den
> Plan, Planung ist alles.

Man sollte erstmal das Ziel haben den Plan so gut wie möglich zu machen 
und nicht mit dem Ansatz Pkan geht sowieso nicht, also lassen wir es 
gleich ganz.

Motzkopp schrieb:
> Die Herren aus dem Anforderungs und Produktmanagment usw waren schon
> immer bequem und denkfaul,

Wer sollen denn diese Leute sein?

Wie gesagt, Programmierer sind im Maschinenbaus selten. Eher 
Softwareentwickler / Ingenieure, die etwas neues entwickeln. Zum 
nachbauen haben wir Chinesen, für Änderungen Techniker, nachdem es 
erfolgreich ist und das Design glattgezogen ist. Nur erfolgreiche 
Produkte werden geändert!

A. S. schrieb:
> Motzkopp schrieb:
> Die Herren aus dem Anforderungs und Produktmanagment usw waren schon
> immer bequem und denkfaul,
>
> Wer sollen denn diese Leute sein?
> Wie gesagt, Programmierer sind im Maschinenbaus selten. Eher
> Softwareentwickler / Ingenieure, die etwas neues entwickeln. Zum
> nachbauen haben wir Chinesen, für Änderungen Techniker, nachdem es
> erfolgreich ist und das Design glattgezogen ist. Nur erfolgreiche
> Produkte werden geändert!

Programmierer gibt es bei uns auch nicht und mein Bereich ist nicht 
Maschbau.
Aber sonne Maschine wird selbst nicht nach Scrum konstruiert und gebaut, 
oder ? Warum nicht, ist doch so eine tolle Sache?
Zu der Frage wer diese Leute sein sollen. Ich bin mir sicher, auch im 
Maschinenbau, obwohl nicht mein Bereich, gibt es Leute, die einem sagen, 
was das Ding am Ende können muss.

Motzkopp schrieb:
> Aber sonne Maschine wird selbst nicht nach Scrum konstruiert und gebaut,
> oder ? Warum nicht, ist doch so eine tolle Sache?

Das Design einer Maschine ist z.B. dessen Zeichnung.

Das Design einer Software ist z.B. dessen Quelltext.

Der Unterschied zwischen Maschine und Quelltext ist, dass die Produktion 
eines Prototypen (Maschine, Maschinencode) im einen Fall hunderte 
Stunden dauert, im zweiten Fall nur Sekunden oder Minuten. Darum hat man 
beim Maschinenbau weniger Itterationen.

Ob und wie Maschienenbauer ihr Design üblicherweise entwickeln, weiss 
ich nicht. Ich hoffe aber mal, dass sie auch Dinge ausprobieren, 
gemeinsam besprechen, Ideen im Projektfortschritt aufgreifen etc. Aber 
dass konkret Scrum jetzt nicht passt, ist offensichtlich (es gibt keine 
täglichen Prototypen, Funktionsmuster)

> Zu der Frage wer diese Leute sein sollen. Ich bin mir sicher, auch im
> Maschinenbau, obwohl nicht mein Bereich, gibt es Leute, die einem sagen,
> was das Ding am Ende können muss.

Ja, ähnlich Abstrakt wie Du einem Architekten sagst, wie Dein Haus 
auszusehen hat. Du sagst ihm, ob es Traufenständig sein soll, wie groß 
in etwa, was und welche Zimmer. Und dann macht er einen Entwurf, den Ihr 
verfeinert. Und ja, technische Abläufe der Maschine muss der 
SW-Ingenieur wirklich selber verstehen und dann Umsetzen. Und ja, wenn 
es um z.B. die SPS-SW eine Produktionsstraße geht, dann brauchst Du eher 
Programmierer. Aber eine SPS selber, Maschinen mit embeddedter Steuerung 
und GUI, Eine Druckmaschine oder Spinnmaschine, … da ist die SW Teil der 
Entwicklung.

A. S. schrieb:
> Das Design einer Maschine ist z.B. dessen Zeichnung.
>
> Das Design einer Software ist z.B. dessen Quelltext.

Hä? Der Quelltext IST die Software. Das Design sind Ablauf-, Klassen-, 
Zustands- etc. diagramme

c r schrieb:
> Hä? Der Quelltext IST die Software. Das Design sind Ablauf-, Klassen-,
> Zustands- etc. diagramme

Wenn das so wäre, bräuchte man Programmierer, die die Diagramme in 
Quelltext "übersetzen". Wo das der Fall ist (bzw. von einem Tool gemacht 
wird), hast Du recht. Ein Matlab-Simulink-Stateflow-Diagramm ist das 
Design.

Vielleicht meinst Du eher eine Art "Architektur", "übergeordnete 
Struktur" oder so. Das gibt es natürlich im Maschinenbau auch, dass es 
übergeordnete Zeichnungen, Erklärungen etc. gibt.

Nachtrag: Hier ein Papier dazu:

http://user.it.uu.se/~carle/softcraft/notes/Reeve_SourceCodeIsTheDesign.pdf

Ich fand das genauso bahnbrechend, wie seinerzeit die Ablösung von 
Nassi-Shneydermann und Co durch Hochsprachen.

Software kann man ja runterladen.

Motzkopp schrieb:
> Die Herren aus dem Anforderungs und Produktmanagment usw waren schon
> immer bequem und denkfaul, durch Scrum und diesen Scheiss kriegen sie
> jetzt auch noch ne offizielle Legimitation

Aber wieso kommt man damit durch? Man stelle sich vor ein Haus zu 
beauftragen ohne Planung! "War halt noch nicht klar wo die Fenster und 
Türen rein sollen und wo der Schornstein stehen muss"? Bauteil fertigen 
ohne Zeichnungen/CAD? Das leuchtet jedem sofort ein, dass da etwas nicht 
stimmt. Bei Softwareprojekten ist das Bewusstsein offenbar auf dem Stand 
von 1980 verharrt?!

Ing schrieb:
> Aber wieso kommt man damit durch?

Weil es funktioniert. Die Branchengrößen machen es vor.

Ing schrieb:
> Man stelle sich vor ein Haus zu
> beauftragen ohne Planung!

Ein Haus ist keine Software. Da kann man nicht mit einem Klick auf den 
Stand von gestern zurückgehen.

Ing schrieb:
> Bei Softwareprojekten ist das Bewusstsein offenbar auf dem Stand
> von 1980 verharrt?!

Softwareprojekte sind so komplex, und arbeiten in einer so komplexen 
Umgebung, dass die Entwicklung unmöglich komplett planbar ist. Bei einem 
Haus oder einem Bauteil auf Basis bekannter Technologie ist das was ganz 
anderes.

Komplett spezifizierte Anforderungen zu haben ist utopisch - viele 
Auftraggeber wissen nicht genau was sie brauchen, und was sich im 
Endkundenmarkt durchsetzt ist sowieso unvorhersehbar (klassisches 
Beispiel VHS vs Betamax). Man muss mit dem arbeiten was man hat, 
flexibel auf neue Erkenntnisse - die man vorher unmöglich haben konnte - 
reagieren und das Ziel ständig neu stecken. Scrum hilft dabei.

Wenn man komplette Software-Projekte versucht durchzuplanen und alles 
nach dem ursprünglichen Plan entwickelt, d.h. zwischendurch 
dazugekommene Erkenntnisse und Technologien ignoriert, wird das Ergebnis 
veraltet sein sobald es auf den Markt kommt - daher der Grundsatz, oft 
kleine Versionssprünge zu veröffentlichen, um die Nutzer bei Laune zu 
halten.

Auch bei Häusern ändern sich gelegentlich die Anforderungen 
zwischendurch, und Dinge werden mittendin umgeplant. Das manifestiert 
sich dann gelegentlich in kuriosen Konstruktionen.

Man muss diese typische Ingenieurs-Denkweise ablegen, alles durchplanen 
und dann zusammenbauen zu können - das ist unrealistisch, 
unwirtschaftlich und lässt Möglichkeiten ungenutzt (erinnert an 
Planwirtschaft). Software ist lebending, ist nie fertig und kann 
jederzeit umgebaut werden. Autoren planen ihre Romane auch selten von 
A-Z durch um sie dann nur noch runterzuschreiben - es wird viel 
nachträglich korrigiert und vieles spontan entschieden. In beiden Fällen 
ist das natürlich ein zweischneidiges Schwert - es verleitet schnell zu 
unbeherrschbarem Wildwuchs. Daher gibt es Modelle wie Scrum, um das in 
den Griff zu bekommen, ohne auf eine starre Komplettplanung zurück zu 
fallen.

Motzkopp schrieb:
> Ja, dann kannst nach agil und CO ständig redisgnen oder neu machen, und
> das soll gut sein? Das ist nur teuer !
Billiger als Projekte die nur für die Tonne entwickelt werden, weil man 
sich ändernde Marktsituationen/-Erkenntnisse ignoriert.

> Und du glaubst ja wohl nicht, das
> eine funktionierende Frickelkei in der Praxis später noch redesigned
> wird.
Selbstverständlich werden Proof-of-Concept-Ansätze bereinigt und 
ausgebaut, wenn sie gut ankommen.

Ing schrieb:
> hatte ich bisher
> einfach nur Pech mit den Firmen oder ist das "branchenüblich"?

Ist nicht nur dort so. Wenn der Käufer der Produkte keinen 
Entwicklungsprozess zwingend in die Auftragsbücher diktiert, ist Wilder 
Westen angesagt.

Ing schrieb:
> Aber wieso kommt man damit durch?

Weil es einen Aspekt der Realität in der Entwicklung abdeckt, der von 
den klassischen Methoden nicht abgedeckt wird, nämlich dass sich 
Anforderungen ständig ändern.

> Man stelle sich vor ein Haus zu
> beauftragen ohne Planung! "War halt noch nicht klar wo die Fenster und
> Türen rein sollen und wo der Schornstein stehen muss"? Bauteil fertigen
> ohne Zeichnungen/CAD? Das leuchtet jedem sofort ein, dass da etwas nicht
> stimmt.

Schon mal ein Haus gebaut? Alle paar Tag fällt einem eine Änderung ein. 
Hier noch was ein bisschen anders, da noch was. Wenn man es sich leisten 
kann dann beauftragt man die Änderungen, was viel Geld kostet. Die 
Handwerker freut es und man wäre froh, wenn im Gesamtsystem mehr 
Flexibilität wäre.

Bei großen Bauprojekten ist es noch schlimmer. Jeden Tag Besprechung in 
der man über Fehler in den Plänen diskutiert und mehr oder weniger guten 
Pfusch beschließt.

Es ist übrigens ein Gerücht, dass bei Scrum keine Planung stattfindet 
und es keine Anforderungen gibt. Jeder Sprint wird voraus geplant und 
während eines Sprints wird sich an die Planung gehalten. Änderungen die 
während eines Sprints reinkommen werden frühstens im nächsten Sprint 
berücksichtigt. Damit das nicht zu lange dauert werden Sprints selber 
sehr kurz gehalten.

Scrum bedeutet viel Disziplin.

Das ist das eigentliche Problem. Wenn die Beteiligten undisziplinert 
sind, und die meisten sind es, dann kommt Mist raus. Der Product Owner 
schafft die Requirements nicht ran oder sie sind extrem wage. Der Scrum 
Master sichert nicht den Prozess. Die Sprints werden nicht sauber 
geplant. Mitten in den Sprints wird die Richtung geändert, jeder 
Programmierer macht was er will.

> Bei Softwareprojekten ist das Bewusstsein offenbar auf dem Stand
> von 1980 verharrt?!

Nein, eher von 1950. Undisziplinierte Softwerker brauchen klare 
Anweisungen und Kontrolle. Wer glaubt Scrum ohne Disziplin zum Laufen zu 
bekommen, dem kann ich nur viel Spaß wünschen.

> Softwareprojekte sind so komplex, und arbeiten in einer so komplexen
> Umgebung, dass die Entwicklung unmöglich komplett planbar ist. Bei einem
> Haus oder einem Bauteil auf Basis bekannter Technologie ist das was ganz
> anderes.

Die sind komplex und ja ein Plan Bedarf ständiger Anpassungen. Aber 
erstmal
einen Plan haben !
Und wie Wahrheit ist, dass gute Pläne an folgenden Dingen scheitern:
Zeit und Einstellung der Personen ! Man gesteht der Planung zu wenig 
Zeit zu und die Anforderungsmanager haben kein Bock zu denken, es ist 
halt leichter wenn man schonmal was zum draufklicken hat
und ein paar Dinge ausprobieren kann.

Typisch ist es z.B. dass der Anfoderungsmanager den IST-Zustand gar 
nicht genau kennt, erst der Entwickler sagt ihm beim coden dann, was er 
noch zu berücksichtigen hat. Das muss man bei Planestellung nicht bis 
ins letzte Detail machen, das ist echt aufwendig, aber nen groben Plan 
sollte man haben.


> Komplett spezifizierte Anforderungen zu haben ist utopisch - viele
> Auftraggeber wissen nicht genau was sie brauchen, und was sich im
> Endkundenmarkt durchsetzt ist sowieso unvorhersehbar (klassisches
> Beispiel VHS vs Betamax). Man muss mit dem arbeiten was man hat,
> flexibel auf neue Erkenntnisse - die man vorher unmöglich haben konnte -
> reagieren und das Ziel ständig neu stecken. Scrum hilft dabei.

Oh man, hier haben wir einen der Scrum-Jünger !!! Die Schulungen sind 
Gehirnwäsche.


> Wenn man komplette Software-Projekte versucht durchzuplanen und alles
> nach dem ursprünglichen Plan entwickelt, d.h. zwischendurch
> dazugekommene Erkenntnisse und Technologien ignoriert, wird das Ergebnis
> veraltet sein sobald es auf den Markt kommt - daher der Grundsatz, oft
> kleine Versionssprünge zu veröffentlichen, um die Nutzer bei Laune zu
> halten.
> Auch bei Häusern ändern sich gelegentlich die Anforderungen
> zwischendurch, und Dinge werden mittendin umgeplant. Das manifestiert
> sich dann gelegentlich in kuriosen Konstruktionen.

Es sagt niemand, dass man beim klassischen Vorgehen, nicht den Plan 
ständig
anpassen kann. Wie gesagt, das Ziel sollte zuerst sein einen möglichst 
guten Plan zu haben, statt einen Plan von vorneherein abzulehnen.

>
> Motzkopp schrieb:
>> Ja, dann kannst nach agil und CO ständig redisgnen oder neu machen, und
>> das soll gut sein? Das ist nur teuer !
> Billiger als Projekte die nur für die Tonne entwickelt werden, weil man
> sich ändernde Marktsituationen/-Erkenntnisse ignoriert.

So ein Quark. Ich weiss nicht woher die Vorstellung kommt, das nach 
Wasserfall keine Änderungen am Plan mehr möglich sind und das das nur 
mit Scrum möglich ist.


>> Und du glaubst ja wohl nicht, das
>> eine funktionierende Frickelkei in der Praxis später noch redesigned
>> wird.
> Selbstverständlich werden Proof-of-Concept-Ansätze bereinigt und
> ausgebaut, wenn sie gut ankommen.

Bin 25 Jahre im Job ind 4 verschiedenen Unternehmen, das mit dem 
Redisgnen klappt in der Praxis nur mit KleinKlein Zeug, das keine 
anderen Entscheidungsgewalten abnicken müssen. Z.B. Meine jetzigen 
"Kunden", die Fachabteilungen ist das nicht vermittelbar, wofür sie 
wertvolle Resourcen opfern sollen. Was haben sie davon ?

Ing schrieb:
> Motzkopp schrieb:
>> Die Herren aus dem Anforderungs und Produktmanagment usw waren schon
>> immer bequem und denkfaul, durch Scrum und diesen Scheiss kriegen sie
>> jetzt auch noch ne offizielle Legimitation
>
> Aber wieso kommt man damit durch? Man stelle sich vor ein Haus zu
> beauftragen ohne Planung! "War halt noch nicht klar wo die Fenster und
> Türen rein sollen und wo der Schornstein stehen muss"? Bauteil fertigen
> ohne Zeichnungen/CAD? Das leuchtet jedem sofort ein, dass da etwas nicht
> stimmt. Bei Softwareprojekten ist das Bewusstsein offenbar auf dem Stand
> von 1980 verharrt?!


Die kommen damit durch, weil sie näher am Managment und am Kunden 
sitzen. Die Entwickler sind die Blaumänner in der Produktion, haben 
nichts zu kamellen, dürfen es nur ausbaden.
Notfalls reden die Herren sich raus, schwieriger Kunde, Markt hat sich 
geändert, Kunde hat es umentschieden usw. usw..
Meiner Meinung sind diese Ausreden zu 90% vermeidbar, wenn man seinen 
Denkapparat ordentlich angeschmissen hätte, aber lieber ersteinmal auf 
was rumklicken können und dann umentscheiden um dann damit massenweise 
Geld/Entwiclungszeit zu vernichten.

Michael Gugelhupf schrieb:
> Ing schrieb:
>
> Es ist übrigens ein Gerücht, dass bei Scrum keine Planung stattfindet
> und es keine Anforderungen gibt. Jeder Sprint wird voraus geplant und
> während eines Sprints wird sich an die Planung gehalten. Änderungen die
> während eines Sprints reinkommen werden frühstens im nächsten Sprint
> berücksichtigt. Damit das nicht zu lange dauert werden Sprints selber
> sehr kurz gehalten.
>
> Scrum bedeutet viel Disziplin.
>
> Das ist das eigentliche Problem. Wenn die Beteiligten undisziplinert
> sind, und die meisten sind es, dann kommt Mist raus. Der Product Owner
> schafft die Requirements nicht ran oder sie sind extrem wage. Der Scrum
> Master sichert nicht den Prozess. Die Sprints werden nicht sauber
> geplant. Mitten in den Sprints wird die Richtung geändert, jeder
> Programmierer macht was er will.
>
>> Bei Softwareprojekten ist das Bewusstsein offenbar auf dem Stand
>> von 1980 verharrt?!
>
> Nein, eher von 1950. Undisziplinierte Softwerker brauchen klare
> Anweisungen und Kontrolle. Wer glaubt Scrum ohne Disziplin zum Laufen zu
> bekommen, dem kann ich nur viel Spaß wünschen.


Jepp, hier haben wir einen, sie einer meiner letzten Postings !
Merke: Es liegt nie an Scrum, wenns nicht klappt, es liegt an den 
Leuten, oder man hat es falsch umgesetzt usw. !
Daher kommt mir das ganze auch so sektenartig vor, oder man will noch 
Scrum-Schulungen verdienen und die ganzen zertifizierten Scrummaster 
wollen es nicht umsonst gemacht haben.

motzkopp schrieb:
> Jepp, hier haben wir einen, sie einer meiner letzten Postings !

Ach du Pfeife, hör erst mal auf zu plenken.

Hättest du mich gefragt was an Scrum falsch ist hätte ich dir einen 
mehrstündigen Vortrag darüber halten können. Aus Erfahrung. Danach hätte 
ich noch eine Stunde dran hängen können, wie Scrum-Projekte durch 
Ausnutzung der Schwächen erfolgreich sabotiert werden.

Aber du hast ja nicht gefragt. Du hast einfach rumgegrölt. So wie ein 
Afd-Anhänger, unqualifizierte, unwissende aber im Besitz der alleinigen 
Wahrheit und noch stolz drauf.

Weißt du, es ist traurig wenn ein angeblicher Ingenieur wie du nicht 
einmal in Ruhe eine Diskussion zum Für und Wider einer Methode 
aushalten, geschweige denn führen kann.

Nun, da alles Weitere bei dir nur Perlen vor die plenkenden Säue ist 
schenke ich mir alles Weitere.

motzkopp schrieb:
> Merke: Es liegt nie an Scrum, wenns nicht klappt, es liegt an den
> Leuten, oder man hat es falsch umgesetzt usw. !
> Daher kommt mir das ganze auch so sektenartig vor, oder man will noch
> Scrum-Schulungen verdienen und die ganzen zertifizierten Scrummaster
> wollen es nicht umsonst gemacht haben.


Versteiff Dich doch nicht so auf SCRUM. Mit denen Leuten, mit denen es 
mit SCRUM klappt, kannst Du auch ohne SCRUM genauso viel reißen.

Du musst nur weg vom umfassenden Plan vorab. Wenn Deine Auftraggeber 
wissen, was sie wollen, z.B. deren Geschäftsprozesse auf neues 
Steuerrecht anpassen oder eine Produktionsstraße automatisieren, dann 
ist das doch gut. Dann gibt es zwar hier oder da eine Änderung, aber 
dann weiss anfangs, was hinten rauskommen soll.

Wenn Du etwas Neues entwickelst (ein Messgerät, eine Maschine, die 
erstmals elektronisch gesteuert wird, ...) dann kannst Du nicht wissen, 
was Du willst, einfach weil das bisher niemand in der Hand gehabt hat. 
Dann brauchst Du Entwickler (keinen Techniker), Ingenieure, keine 
Programmierer, Kreativität statt Sorgfalt. Oder besser gesagt, die 
Mischung daraus. Dann brauchst Du die Freiheit, heute die Arbeit der 
letzten 2 Wochen wegzuschmeißen und neu zu machen, heute die Annahme von 
gestern (es wird nie mehr als 255 geben) zu verwerfen.

Hätte Ford die Kunden befragt, hätten sie sich schnellere Pferde 
gewünscht.

Programmierer schrieb:
> Ing schrieb:
>> Aber wieso kommt man damit durch?
>
> Weil es funktioniert. Die Branchengrößen machen es vor.
>


Das höre ich auch immer wieder.
Die Branchengrössen können sich von der Ressourcengewalt ganz anders mit 
dem Zeug beschäftigen. Die können viel Ressourcen versemmeln, nur das 
Produkt muss 100% sein, das nutzen Millionen von Leuten.
Kann man nicht mit normalen Softwarebuden vergleichen, wo jede Stunde 
irgendein Kunde bezahlen muss und sich änderende Anforderungen und 
ständiges anders und neu Gemache finanziell ganz anders auswirken. Ist 
aber hipp, dass denen großen nachzumachen.

A. S. schrieb:
>
> Wenn Du etwas Neues entwickelst (ein Messgerät, eine Maschine, die
> erstmals elektronisch gesteuert wird, ...) dann kannst Du nicht wissen,
> was Du willst, einfach weil das bisher niemand in der Hand gehabt hat.
> Dann brauchst Du Entwickler (keinen Techniker), Ingenieure, keine
> Programmierer, Kreativität statt Sorgfalt. Oder besser gesagt, die
> Mischung daraus. Dann brauchst Du die Freiheit, heute die Arbeit der
> letzten 2 Wochen wegzuschmeißen und neu zu machen, heute die Annahme von
> gestern (es wird nie mehr als 255 geben) zu verwerfen.
>
> Hätte Ford die Kunden befragt, hätten sie sich schnellere Pferde
> gewünscht.

Diesen Anwendungsfall unterschreibe ich, siehe meinem letzten Postung, 
da zählt das innovative schnelle Produkt 100 mal mehr, als die 
Ressourcen und man startet auf der gründen Wiese.
Ich arbeite zur Zeit an einer seit 25 Jahren existierenden aus 50 Mio 
Zeilen bestehenden -grob gesagt- Buchhaltungssoftware. Schmeiss da mal 
kurz was um, jedes Flag einer Tabelle kann ungeahnte gravierende 
Auswirkung haben...

Mark B. schrieb:
> Das ist so durchaus üblich. Wenn ein Unternehmen sich hauptsächlich als
> Maschinenbauer sieht, woher soll es dann auch eine große Kompetenz in
> Sachen Softwareentwicklung besitzen?

Indem es entspr. Leute dafür einstellt und nicht die interne Truppe 
dafür missbraucht die ein bischen was zusammenschustern kann.

Dick Boutsos schrieb:
> Mark B. schrieb:
> Das ist so durchaus üblich. Wenn ein Unternehmen sich hauptsächlich als
> Maschinenbauer sieht, woher soll es dann auch eine große Kompetenz in
> Sachen Softwareentwicklung besitzen?
>
> Indem es entspr. Leute dafür einstellt und nicht die interne Truppe
> dafür missbraucht die ein bischen was zusammenschustern kann.

Softwareentwicklung ist aber keine Rocket Science. Es ist auch kein 
Missbrauch, wenn die Angestellten ihr Wissen und ihre Fähigkeiten etwas 
erweitern.

Mark B. schrieb:
> Das scheitert an einem ganz banalen Grund:
> Wenn man selbst keine Kompetenz in X besitzt, wie soll man dann erkennen
> welche Person genau die richtige wäre um X korrekt durchzuführen?

Was das fürn Nullargument?

Mark B. schrieb:
> Also zumindest Top-Level Requirements werden definitiv existieren. Wenn
> es nichtmal die gibt, wird doch niemand das Budget für eine Entwicklung
> bereitstellen.

Top-Level Requirement ist ganz hoch im Bullshit-Bingo.

Der Kunde hat Wünsche.
- Einfachere Bedienung
- Fernsteuerung
- Automatisierung bisher manueller Tätigkeiten
- Aussagekräftigere Anzeigen
- Eine Verriegelung, dass dies oder jenes nicht passiert

SW im Maschinenbau heisst weder Stückzahlen wie beim IPhone oder Auto, 
noch EDV, wo schon seit 70 Jahren Tausende von Programmierern an einer 
SW arbeiten.

Das was im Maschinenbau SW ist, wird bei IPhone oder Auto 
"Vorentwicklung" genannt, und dort gibt es aus guten Grund ähnliche 
Freiheiten und nicht die staren, auf Perfektion ausgerichteten 
Vorgehensmodelle. Dort darf man spielen, probieren, kreativ sein.

Und ja, auch beim Maschinenbau gibt es SIL, SAfety und Co, und dort sind 
Vorgehensmodelle Pflicht, weil die Aufgabe eine andere ist: Eine 
konkrete, zu Anfang bekannte Funktion mit bewährten Mitteln zu 
realisieren. Aber das ist nur ein (ungeliebter) Teil der SW im 
Maschinenbau

Ich will da mal aus meinem Bereich ein kürzlich aufgetretendes Problem 
schildern. Es gibt eine Tabelle mit Buchungen, wo wir 1,2 Mrd Datensätze 
haben. Dort mussten wir ein neues DB Feld einführen. Rückwirkend mussten 
alle Datensätze mit einem nicht einfach zu ermittelnden Wert gefüllt 
werden. Dies passierte durch eine aufwendige PLSQL Routine auf einer 
Oracle DB. Nun das Problem: Die Downzeit des Servers war nicht lange 
genug, um dieses Update durchzuführen. Erst nach wochenlangem Tüfteln, 
testen und optimieren haben wir das Problem gelöst. Da gab es schon viel 
schlimmere Probleme, aber das Bsp versteht jeder Softie.
Warum erzähle ich das ? Weil das ein Scheiss Feld war, was so harmlos in 
irgendeiner Maske in der GUI erscheint, fürn Anforderungsmanager 
vollkommen langweilig, für die Entwickler viel Arbeit.
Mit Scrum dann haha, brauchen wir doch nicht, oder anders, oder so, hmm? 
Da sprinten wir durch.
Wir müssen innovativer umd flexibler werden ! Erst mal was raushauen und 
dann entscheiden, wo es lang geht.

Motzkopp schrieb:
> Mit Scrum dann haha, brauchen wir doch nicht, oder anders, oder so, hmm?
> Da sprinten wir durch.

Scrum ist doch für Deine Aufgaben überhaupt nicht sinnvoll. Das ist so, 
als wenn jemand 13er Maulschlüssel verteufelt, weil die Prüfung einer 
12V-Batterie damit nur unzureichen möglich ist.

Mark B. schrieb:
> Ist kein Nullargument. Denk einfach mal bisschen nach, dafür ist dein
> Gehirn ja da. Wenn niemand in einer Firma echte Kompetenz in Sachen
> Software besitzt, und schon gar nicht die Personalabteilung, wie will
> man dann einen guten Entwickler einstellen? Es fehlt einem ja dann die
> Fähigkeit, beurteilen zu können wer wirklich gut ist.
Nach deiner Logik wäre dann jede Firma noch in der 
produktionstechnischen Steinzeit, weil sie angeblich nicht in der Lage 
ist fähige Leute zu erkennen. Dafür hat Gott die Studienabschlüsse und 
Arbeitszeugnisse geschaffen. Wenn sich einer bewirbt mit 5 Jahren 
Erfahrung in Softwareengineering und Informatikstudium wird der auch 
Ahnung haben, jedenfalls mehr als der Maschinenbauer mit nebenher 
erworbenen Programmierkenntnissen oder E-Techniker mit MC-Fokus.

Das Problem ist ein ganz anderes in diesen Firmen: Man hat noch gar 
nicht erkannt wie unprofessionell man dort arbeitet, das Gestümpere gilt 
dort als normal. Da wurschtelt halt der Maschinenbauer die Software 
irgenwie zusammen oder der E-Techniker die Steuerung aber wenns mal 
komplexer wird und über klassisches MC-Gefrickel hinausgeht glaubt er 
kann da wie bisher weiterfrickeln. Dazu kommt noch wie oben schon 
beschrieben, dass schnelle Ergebnisse gewünscht werden, der ahnungslose 
Vorgesetzte bestimmt also wie gearbeitet werden soll. Selbst wenn die 
Entwickler erkannt haben, dass sie mit dem Gefrickel nicht mehr 
weiterkommen und das ändern wollen würden, der Chef oder wer auch immer 
die Entscheidungsmacht hat, funkt mit seinen unrealistischen 
Zeitvorgaben immer dazwischen.

Wenn ich schon in solchen Knallfroschbuden vom "Chefentwickler" höre 
dass Testen überflüssig ist aber denen ständig die Projekte um die Ohren 
fliegen und keinen Termin reissen. Fragt man die wie sie ihre Projekte 
planen schauen die einen an wie ein Mondkalb. Scrum, Projektmanagement, 
Testszenarien, alles unnützer Kram für die, der nur Zeit kostet. Denen 
rennen auch regelmässig die Fähigen Leute weg, weil die keine neuen 
Strukturen etablieren dürfen. Da muss erst mal Erkenntnis+Wille da sein, 
das man so wie man jetzt 'arbeitet' es völlig unprofessionell ist und 
das geändert werden muss.

Mark B. schrieb:
> Weil man nicht versteht, wie es richtig
> gemacht werden muss (also die Entwicklung von Software).


Doch, von Zeit zu Zeit kommen dann solche Informatik-Experten und wollen 
eine 5-Mann-Entwicklung professionalisieren, so wie es bei EDV-SW (mehr 
oder weniger) gut funktioniert. Dann passieren folgende Dinge, die hier 
im Forum ja auch schon geschildert wurden:

- Unsinnige, unhinterfragte Regeln, die im gegenwertigen Kontext keinen 
Sinn machen. (Stefan U: jeder Member-Zugriff nur über Getter/Setter)

- Völlige Ausblendung des µC-Kontexts (Andreas S: Nein, die x kB-RAM im 
Datenblatt sind MB: ein µC mit so wenig RAM gäbe keinen Sinn)

- Design in UML: Nicht nur schlecht geeignet für Automaten, meist auch 
nur gemalt, nicht modelliert (nicht nur, dass kein Code erzeugt wird, 
... das Modell selber ist mangels Umgebung in sich selber nicht 
konsistent oder verifizierbar)

- Frühe Entscheidungen (Dann haben die Leute, die keine Ahnung von SW 
haben, halt ihre wünsche nicht ausreichend durchdacht)

A. S. schrieb:
> µC-Kontexts

A. S. schrieb:
> Mark B. schrieb:
>> Weil man nicht versteht, wie es richtig
>> gemacht werden muss (also die Entwicklung von Software).
>
> Doch, von Zeit zu Zeit kommen dann solche Informatik-Experten und wollen
> eine 5-Mann-Entwicklung professionalisieren, so wie es bei EDV-SW (mehr
> oder weniger) gut funktioniert. Dann passieren folgende Dinge, die hier
> im Forum ja auch schon geschildert wurden:
>
> - Unsinnige, unhinterfragte Regeln, die im gegenwertigen Kontext keinen
> Sinn machen. (Stefan U: jeder Member-Zugriff nur über Getter/Setter)
>
> - Völlige Ausblendung des µC-Kontexts (Andreas S: Nein, die x kB-RAM im
> Datenblatt sind MB: ein µC mit so wenig RAM gäbe keinen Sinn)
>
> - Design in UML: Nicht nur schlecht geeignet für Automaten, meist auch
> nur gemalt, nicht modelliert (nicht nur, dass kein Code erzeugt wird,
> ... das Modell selber ist mangels Umgebung in sich selber nicht
> konsistent oder verifizierbar)
>
> - Frühe Entscheidungen (Dann haben die Leute, die keine Ahnung von SW
> haben, halt ihre wünsche nicht ausreichend durchdacht)


Wer in Business Applikationen z.B. jedes Bit eines ints nutzt, um sich 
platzsparend Zustände zu merken, der kriegt in der Welt gewaltig hinter 
die Ohren, im µC-Kontext mag das ja sinnvoll sein.
Das mit den Gettern und Settern hätte ich auch gesagt. Hauptgrund neben 
anderen Vorteilen: Ich kann da einen Breakpoint reinsetzen.

Mark B. schrieb:
> Echte Informatik-Experten lesen zum Beispiel solche Artikel:
> 
https://www.javaworld.com/article/2073723/why-getter-and-setter-methods-are-evil.html
>
> Und verstehen sie auch :-)
>
> Das Problem bleibt nach wie vor, zu erkennen wer denn nun ein echter
> Experte ist und wer ein Möchtegern-Experte... und sowas steht halt auf
> keinem Diplomzeugnis der Welt drauf.


"It follows then that in OO systems you should avoid getter and setter 
functions since they mostly provide access to implementation details."

Was den für Implementierungsdetails ? Wo ist der Unterscheid zu public 
members, die ich ja dann stattdessen benutzen muss ?
Ich bin auch kein Fan davon alle member Variablen mit gettern und 
settern auszustatten, sondern nur die, auf die ich von aussen zugreifen 
muss.


"To see why, consider that there might be 1,000 calls to a getX() method 
in your program, and each call assumes that the
return value is of a particular type. You might store getX()'s return 
value in a local variable, for example, and that variable type
must match the return-value type. If you need to change the way the 
object is implemented in such a way that the type of X changes, you're 
in deep trouble. If X was an int, but now must be a long, you'll get 
1,000 compile errors."

Die kriege ich auch, wenn ich den Typ einer 1000 mal benutzen public 
member Variabe von int auf long ändere.


Liebe Informatik Experten, ich habe es nicht verstanden, erklärt mir 
warum getter und setter schlechter sein sollen, als public members.

Wow, ist ja echt interessant. Der Krieg der Vorgehensmodelle :D
Vielleicht wären Schulungen im Bereich der Komplexitätsforschung gar 
nicht so verkehrt. Man kann lernen komplexe Systeme zu erkennen und 
besser zu beurteilen. Und ich denke Software Entwicklung im 
wirtschaftlichen Umfeld stellt ein komplexes System dar.
Es würde genügen die grundlegenden Wesenszüge solcher Systeme zu 
verstehen und was einzelne Veränderungen bewirken können.

Und obwohl ich keine berufliche Erfahrung habe würde ich intuitiv 
wetten, dass es nicht das perfekte Modell gibt, genau wie es auch nicht 
die perfekte Programmiersprache gibt. Abhängig von diversen Faktoren 
kann ein Modell in einem Unternehmen besonders gut oder besonders 
schlecht funktionieren.

Aufwand, Zeitbedarf, Effizienz, Flexibilität... diese Werte können nicht 
alle perfektioniert werden. Besonders große Flexibilität wird andere 
Werte zwangsläufig hochtreiben, etwa den Zeitbedarf. Wenn ein Modell so 
gestaltet ist dass es hohe Flexibilität bei möglichst geringem 
Zeitbedarf bietet, treibt möglicherweise den Aufwands Wert hoch weil es 
hohe Disziplin durch Einhaltung vieler Regeln bedarf um effizient und 
flexibel zu funktionieren. Da aber nicht alle im Unternehmen 
diszipliniert sind funktioniert es nicht wie es theoretisch sollte.

Bei Programmiersprachen ist es ja auch so. Besonders einfache 
Programmiersprachen etwa Scriptsprachen sind langsamer.
Und eine Programmiersprache wie Rust die Vorteile einer GC Sprache ohne 
einen GC haben will bezahlt den Preis mit einer höheren Lernkurve der 
Sprache, was dann auch für viele eine problematische Hürde darstellt.

Vieles deutet also darauf hin dass es gar kein perfektes Vorgehensmodell 
in Projekten geben kann.
Maximal flexibel, maximal schnell, maximal günstig, maximal effizient, 
maximal leicht realisierbar... geht also nicht.

Was neue Modelle oft auszeichnet ist eine Verschiebung eines Wertes nach 
oben ohne den Verweis auf die zwangsläufige Senkung eines anderen 
Wertes.
Also es kommt z.B. ein neues Modell dass viel mehr Flexibilität und 
Zeitersparnis verspricht. Erst die Praxis zeigt dann dass es dies 
beispielsweise mit einer höheren Komplexität für die Beteiligten 
bezahlt, was dann bei manchen nicht funktioniert, weil die Beteiligten 
überfordert sind. Während die durchschnittliche Kompetenz in einem 
anderen Unternehmen höher ist und dort funktioniert es etwas besser.

Und dann streiten sich die Leute darüber welches System besser sei :D

Dirk K. schrieb:
> motzkopp schrieb:
>> Liebe Informatik Experten, ich habe es nicht verstanden, erklärt mir
>> warum getter und setter schlechter sein sollen, als public members.
>
> Getter und Setter sind genauso schlecht wie public Members!


Na, dann mich ich erstmal beruhigt, wobei ich persönlich die Getter und 
Setter wesentlich besser finde, wegen Breakpoint setzen und mögliche 
Modifizierung an zentraler Stelle.


>
> public class Connection
> {
>   // GOOD: private setter/getter
>   private State ConnectionState { get; set; }
>   public bool IsOpen() { return ConnectionState == State.Open; }
>   public bool IsClosed() { return ConnectionState == State.Closed; }
> }
>
> Ändert man den enum, sind bei den ersten beiden Klassen
> alle Aufrufe im Client-Code zu ändern, die auf den enum
> zugreifen. Bei der 3. Klasse betreffen die Änderungen
> nur die Klasse selbst.
>
> merciless

Du hast geschummelt. Hier gibt es noch ein Mapping zwischen einem Enum 
und einem Boolean Wert, was die Abstraktion des Enums ermöglicht. Klar 
muss dann der Rest des Code das Enum nicht kennen. Was ist, wenn ich 
wirklich ein int haben will ?

Nachtrag: Schummeln im Sinne eines Informationsverlust, der nur aufging, 
weil der Status nur zwei Zustände haben kann. Du kannst ja mal mit einem 
byte das Spiel betreiben:

private byte a;
..
public bool IsMinus128(a == -128)
..
public bool Is0(a == 0)
public bool Is1(a == 1)
public bool Is2(a == 2)
public bool Is3(a == 3)
..

dann kannst du auch den internen Datentyp von byte auf int ändern, ohne 
das der Rest des Codes betroffen ist ;).

> Und dieser Quatsch sagt mir, dass du nicht wirklich Ahnung
> von Software-Entwicklung hast. Auf diese Art kann man jedes
> Beispiel ins Lächerliche ziehen.
>
> merciless

Aber, aber, lieber Kollege ! Es ware hier die Rede von den so schlechten 
getter und settern. Da will ich als Begründung nicht irgendeinen 
konstruierten Fall haben. Der einzige vollfertige Ersatz sind public 
members und die halte ich für wesentlich schlechter !

Mark B. schrieb:
> motzkopp schrieb:
>> Liebe Informatik Experten, ich habe es nicht verstanden, erklärt mir
>> warum getter und setter schlechter sein sollen, als public members.
>
> Auf die Daten innerhalb eines Objekts soll man möglichst gerade nicht
> von außerhalb der Klasse beliebig zugreifen können. Wenn man das macht,
> hat man ja gerade keine Datenkapselung. Außerdem kann man dann die
> Implementierung einer Klasse nicht ändern, wenn anderer Code da immer
> beliebig auf deren Membern herumwühlt.


Jajaja, das ist alles klar. Wenn ich aber nun mal nen paar Werte der 
Klasse setzen oder lesen will, hmmm ? Ganz darauf verzichten ?

Jo man; Ihr habt's voll drauf.
Meine Forderung: Mindestlohn 150 k€/a für Progger!

Dirk K. schrieb:
> Dann, lieber Kollege, nenne doch mal ein Beispiel,
> wo du von außen unbedingt einen Wert in das Objekt
> setzen musst. Wenn sich das nicht umgehen lässt, dann
> würde ich einen Setter verwenden, weil man sonst keine
> Möglichkeit hat, auf die Änderung eines Wertes zu reagieren
> (vielleicht muss die Gültigkeit geprüft werden, oder
> eine Neuberechnung angestoßen werden, etc.).
>
> merciless

Ich persönlich nutze Setter selten, ich versuche alles über den 
Konstruktor zu übergeben. Aber manchmal lässt es sich nicht vermeiden, 
die Bsp hast du ja selber schon genannt.
Also halten wir fest: Standardlehrbuch-Empfehlung getter und setter zu 
benutzen (als Ersatz für public members) -  Richtig und Gut !
Gegenempfehlungen beziehen sich nur auf absolute Feinheiten, ist aber 
eine Gelegenheit sich als Creme de la Creme Informatik Experte zu 
positionieren !

Motzkopp schrieb:
> Richtig und Gut !
> Gegenempfehlungen beziehen sich nur auf absolute Feinheiten, ist aber
> eine Gelegenheit sich als Creme de la Creme Informatik Experte zu
> positionieren !

Eine Frage an die Experten (wobei Du, Motzkopp, ja nach eigenem Bekunden 
auch eher EDV machst):

Wer von Euch auf dieser Welle macht denn wirklich embedded Maschinen-SW? 
Nicht GUI, nicht Visu, nicht Eingabe von Ablaufplänen, sondern wirkliche 
Steuerungstechnik, (weniger Regelungstechnik, da das ja eher Matlab-Code 
ist)?

Also Wenn Sensor so, dann Aktor so, wenn Zeit abgelaufen, dann, wenn 
dies dann das?

Die meisten Mantras von Kapselung und keinen globalen Objekten greifen 
da nämlich meist nicht oder nur schlecht. Es gibt nämlich einen globalen 
Kontext, mit realen (nicht virtuellen) Teilen, die in einer konkreten, 
physischen Abhängigkeit zueinander stehen.

Ich unterscheide es in virtuelle Objekte (ein Quadrat auf der 
Zeichenfläche, ein Menber in der Adressliste, ein Fehlerbit im Logfile) 
und reale Objekte (das Rad vorne Links im Auto).

Virtuelle Objekte sind gut OOP-kapselbar, können fast beliebig 
instanziiert werden (50 neue Quadrate, neue Mitglieder? Nur zu).

Konkrete Objekte werden dann meist alibi-mäßig genauso gehandhabt ("ich 
leite alle 4 Räder von der Klasse Rad ab! und instanziiere sie dann." 
Super, hier ein Lutscher). Das ist quatsch. Es gibt genau 4 Räder am 
Auto, und alle 4 haben spezifische Eigenschaften und es macht überhaupt 
keinen Sinn, ein 5tes zu instanziieren oder nur 3. Kein DSP kommt damit 
klar, wenn man ein Rad weglässt oder 2 tauscht. Globale Objekte spiegeln 
hier nur die Aufgabe wieder und sind nicht böse. Wie weit das ignoriert 
wird, zeigt sich, wenn Autosar (wo Milliarden hinterstehen) als Gebastel 
angesehen wird, weil es den EDV-Mantras nicht folgt.

Ähnliches gilt für die Zeit, die in Steuerungstechnik eine viel breitere 
Rolle einnimmt als in der EDV, wo einfach nur alles akzeptabel schnell 
und gbgf. transaktionssicher sein muss.

Das, genau das ist der Unterschied, warum die EDV-Erfahrung der 
Informatiker im Maschinenbau (und genau darum ging es dem TO) regelmäßig 
scheitert.

Lothar M. schrieb:
> Fast jeder der Infrommatiker, die von der Hochschule kommend meine
> Hardware zur Maschinensteuerung zu programmieren hatten

Jetzt lästern schon die Mods verallgemeinernd über Informatiker... Waren 
das denn auch Informatiker mit Embedded Spezialisierung? Können frisch 
aus der Hochschule kommende Ings das besser?

Als Embedded-Spezialisierter Informatiker wird man von "normalen" 
Informatikern belächelt weil man kein Experte in PHP, nodejs, Mobile App 
Development, ... ist und nur so komisches Elektronik Zeug macht. Von 
Ings muss man sich anhören dass Ings das alles besser können... Toll!

Ein kleines bisschen wie bei Immigranten 2. Generation, welche hier als 
Ausländer und in der Heimat der Eltern als Deutsche gelten. Die habens 
auch nicht leicht...

Programmierer schrieb:
> Als Embedded-Spezialisierter Informatiker wird man von "normalen"
> Informatikern belächelt weil man kein Experte in PHP, nodejs, Mobile App
> Development, ... ist und nur so komisches Elektronik Zeug macht. Von
> Ings muss man sich anhören dass Ings das alles besser können... Toll!

Da ist ein wenig was dran. grins
Ich finde aber nicht schlimm, dass es so ist.

Ich würde mich einem Vorposter anschließen, das man frisch von der 
Hochschule erstmal in nix Erfahrung hat. Gilt für Infos genauso wie für 
Ings.
Ansonsten gilt für Leute, die eher EDV machen: Da kommt es sehr wohl auf 
Performance an, nur nicht auf 100µs. Es geht meist um Massendaten und 
der erste Blick bei Performaceproblemen richtet sich immer gegen 
IO/Datenbankabfragen. Weniger und sehr sehr schnelle Abfragen ist da das 
Ziel. Da kann man was rausholen !
Danach kommen irgenwelche Schleifen über Massendaten und was die da so 
machen. Danach kommt lange nichts.

Für Optimierungen des Codes Richtung compilerfreundlichkeit muss man 
schon sehr verzweifelt sein. Ich habe schon oft Code gesehen, der 
furchtbar kompliziert und umfangreich war, aber eigentlich nur einfache 
Dinge machte. Da hat jemand ziemlich unverständlichen Code hinterlassen, 
vermutlich ewig Zeit verbraten, nur um die letzten µs rauszuholen, 
vollkommen unnötig. Das ist bei Business-Apps nicht angesagt. 
Optimierungen, die den Code komplizierter machen, nur wenn es unbedingt 
sein muss und an letzter Stelle, wenn man bereits erstere erwähnte 
Möglichkeiten ausgeschöpft hat !
Daher haben logischweise Leute aus anderern Bereichen mehr Übung darin.

Chris D. schrieb:
> Nein, das tut Lothar nicht. Es geht offenbar nur um diejenigen, die
> "Hardware zur Maschinensteuerung zu programmieren hatten".

Und auch Maschinensteuerung ist etwas was Informatiker durchaus 
beherrschen können.

Chris D. schrieb:
> Wie sieht das heutzutage aus?

Genau so. Es gibt z.B. die Spezialisierung "Embedded Systems". Da lernt 
man Regelungstechnik, Sichere Systeme (FuSi und so), 
Mikrocontroller-Programmierung in C und C++, E-Technik-Grundlagen, DSP, 
Adaptive Filter usw. Sollte doch für den Maschinenbau gar nicht so 
falsch sein.

Chris D. schrieb:
> Eher, dass es das heutige Abstraktionsniveau der Software immer noch
> spielend schafft, selbst schnellste Controller an ihr Limit zu treiben,

Das hat aber nichts mit Informatikern an sich zu tun.

PS: In der Informatik-Spezialisierung "Embedded Systems" gibt es auch 
Robotik-Fächer wo man Dinge wie Inverse Kinematik, ROS, 
Roboter-Simulation usw lernt. Es gibt sogar einen Informatik 
Master-Studiengang extra komplett für Robotik, u.a. mit Teilnahme am 
Robocup. Man macht teilweise auch Schaltungsentwicklung und 
Platinenlayouts. Die Teilnahme an der Formula Student (sehr viel 
hardwarenahe Programmierung und Fahrzeugtechnik) wird gefördert. Ist 
auch nicht so weit weg von Industrie und Maschinenbau, oder?

Chris D. schrieb:
> Aber man darf natürlich auch nicht vergessen, dass man nicht viel kann,
> wenn man frisch aus dem Studium kommt und nichts nebenbei gemacht hat

Ja, aber das gilt für alle Studiengänge. Tatsächlich sind Informatiker 
hier eher im Vorteil, weil man im Studium und auch privat durchaus 
programmieren üben kann. Maschinen bauen oder Labor-Experimente sind da 
schon etwas schwieriger.

Chris D. schrieb:
> Aber ehrlich: irgendwo ist das doch Wahnsinn, wenn für eine simple
> Taschenlampen-App (also im Prinzip etwas, das auf Knopfdruck eine LED
> ein- und ausschalten muss) mittlerweile tatsächlich 5 MByte
> heruntergeladen werden müssen.

Das ist aber ein ganz anderes Problem. Google hat hier entschieden, dass 
das das kleinere Übel ist: Die Apps bringen ihre eigenen Libraries und 
Frameworks mit, alles zusammen in der .apk Datei. Das führt dazu dass 
beliebte Frameworks - auch die, die von Google selbst stammen - 
dutzendfach auf dem selben Gerät installiert sind. Dies ließe sich durch 
einen Paketmanager wie APT lösen, welcher die Bibliotheken bei Bedarf 
einmalig zentral installiert, die dann von den Apps benutzt werden 
können. Ein solches System wäre, wie eben APT, aber derart komplex, 
schwer beherrschbar und damit auch fehleranfällig, dass man das dem 
Normalo-Android-User nicht zutrauen wollte. Unter Windows kennt man das 
als "Dll-Hell". Die pragmatische Lösung ist es, nur ein Minimum an 
gemeinsamer Funktionalität mit Android selbst auszuliefern (das 
Android-Framework), und den Rest bringen die Apps selbst mit. Die 
funktionieren dafür praktisch "immer" und man kann sie auch leichter 
wieder deinstallieren, ohne Abhängigkeits-Chaos.

Dass APT in der Praxis so gut funktioniert ist den Maintainern zu 
danken, welche unermüdlich mit riesigem Aufwand die Paketdatenbanken 
pflegen. Das ist im schnelllebigen Mobile-Bereich, wo ständig neue Apps 
und App-Versionen herauskommen, kaum zu stemmen. Wer mal eine Distro 
genutzt hat, welche bei allen Paketen immer brandaktuelle Versionen 
ausliefert kann ein Lied singen von unlösbaren Abhängigkeitsproblemen 
(die gerne auch Updates komplett blockieren), die man nur durch 
komplizierte Fummelei auflösen kann.

Dazu kommt, dass Apps Medien (Grafik, Video, Ton) für verschiedene 
Sprachen und verschiedene Display-Auflösungen mitliefern. Das kann auch 
eine Menge Platz belegen. Google versucht das mit App Bundles in den 
Griff zu bekommen, was aber seine eigenen Probleme hat.

Chris D. schrieb:
> Und dann schaut man sich eine alte Sinumerik 810T-CNC-Steuerung an,

Kann man da auch beliebige Apps von Drittherstellern installieren ohne 
dass diese sich in die Quere kommen oder unauthorisierten Zugriff auf 
Daten erhalten, eigene Apps ultrakomfortabel mit einer IDE entwickeln, 
komplexe GUIs mit Medieninhalten bauen, Daten über verschiedene 
Netzwerke austauschen, und sodass das ganze auch noch ziemlich sicher 
ist?

Das Problem, beliebige Anwendungen und Komponenten kombinieren und 
flexibel, effizient, robust und benutzerfreundlich ausliefern zu können 
ist praktisch ungelöst. Wenn jemand eine Lösung hat, immer raus damit.

Ing schrieb:
> nahmhaften Unternehmen dieser Branche komplexe (Hochsprachen-)Software

Also im Maschinenbau wären das in dieser Reihenfolge VB .net und VB 6 / 
RealBasic / Xojo und neuerdings PyQt

Lothar schrieb:
> Ing schrieb:
>> nahmhaften Unternehmen dieser Branche komplexe (Hochsprachen-)Software
>
> Also im Maschinenbau wären das in dieser Reihenfolge VB .net und VB 6 /
> RealBasic / Xojo und neuerdings PyQt


Im Maschbau wird echt VB häufig eingesetzt, oder ist das ein Scherz ? 
Für was, die Leitrechner ?

motzkopp schrieb:
> Im Maschbau wird echt VB häufig eingesetzt, oder ist das ein Scherz ?
> Für was, die Leitrechner ?

Heute wohl nicht mehr, aber es war recht verbreitet, die 
Visualisierungen in VB zu machen. Oder halt alles, wo irgend ein 
Benutzer mit dem PC interagiert.

MFC und Windows API waren damals nicht wirklich intuitiv, Delphi gut 
aber exotisch (Pascal), QT und DotNet gabs noch nicht. Java auf Windows 
auch irgendwie Stiefmütterlich. Mit DotNet haben dann viele von denen, 
die in C eh µC gemacht haben, auf C# umgestellt, weil es ja C so ähnlich 
ist ;-)

Bernd K. schrieb:
> C# soll wohl ähnlicher zu ObjectPascal/Delphi (somit also exotisch) sein
> als jegliches C/C++-Derivat.

C# hat praktisch nichts mit C, C++, Pascal zu tun. Wenn schon ist C# 
sehr ähnlich zu Java, da beides auf Bytecode und einer VM basiert. Wie 
jetzt die Klammern aussehen und wo die Typen stehen ist ein rein 
kosmetischer Aspekt und sonst ziemlich egal.

Lothar M. schrieb:
> Es
> ergab sich eben "mit der Zeit", dass die Logdaten gespeichert werden
> müssen.

Ach, eine sich plötzlich ändernde Anforderung, die die Informatiker 
ausbaden müssen...

Bernd K. schrieb:
> Das ist für die Sprache irrelevant, das ist nur ein
> Implementierungsdetail des zufällig gerade verwendeten Compilers.

Zum einen das und auf der Zielmaschine kann man dann immer noch ngen 
drüber laufen lassen.

Bernd K. schrieb:
> Das ist für die Sprache irrelevant, das ist nur ein
> Implementierungsdetail des zufällig gerade verwendeten Compilers.

Gut zu wissen, dann schreibe ich meine AVR Programme demnächst in C#, 
weil ich dessen Syntax schöner finde als die von C.

Dann will ich hier auch mal den Klugscheisser geben:
C# ist sehr sehr ähnlich zu Java, da hat Microsoft abgeschaut, was beide 
auszeichnet ist die Garbage Collection, man braucht sich um den Speicher 
nicht zu kümmern.
Anders als bei Delphi, C++, C. Die haben gemeinsam, dass es Pointer 
gibt, das kennt ein Java oder c# Entwickler nicht.
Und C ist die einzige nicht OOP Sprache von allen.

Ing schrieb:
> hatte ich bisher einfach nur Pech mit den Firmen oder ist das
> "branchenüblich"?

Nein, so ein Chaos ist branchenüblich und stammt aus vielen Dingen wie 
Unwissenheit,  Knappheit an Ressourcen,  Budget,  wie auch fehlendes QM, 
kein seriöses Requirement Engineering oder Tools u.v.m.

Auch in anderen traditionellen aber auch modernen Branchen üblich: man 
ist sich immer noch gewöhnt, in Projekten mit Office, x Wordversionen, 
xy Excelversionen und hunderte Mails zu arbeiten, vor allem verstaubte 
Projektleiter.

Grüsse
 klausi

klausi schrieb:
> stammt aus vielen Dingen wie
> Unwissenheit,  Knappheit an Ressourcen,  Budget,  wie auch fehlendes QM,
> kein seriöses Requirement Engineering oder Tools u.v.m.

Gibt es sich alles. Ist in Summe aber nicht stichhaltig. Gerade Budget 
ist im Maschinenbau da, QM wurde quasi dort erfunden, und das deutscher 
Maschinenbau keine Anforderungen kennt bzw. Kundenwünsche erfüllt, ist 
auch nicht wirklich offensichtlich.

Vielleicht ist es doch so, dass sich offensichtlich falsche Methoden 
dann doch als das herausgestellt haben, was sie sind: falsch.


Ja, wenn die Schreiner Doors verwenden würden, ihre Zollstöcke 
regelmäßig kalibrieren und jeden Woche einen Tage am internen 
Qualitätszirkel teilnehmen würden, dann würden sich die vielen Fehler 
(vermessene Türen, falsche Maserung) sicher reduzieren.


Oder welche Fortschritte würde die Physik machen, wenn sie sich endlich 
wie die Mathematik rein auf Berechnungen stützt, anstatt an all diesen 
fehlerbehafteten Messungen festzuhalten,.