Hallo Forum,
langsam bekomme ich den Eindruck, dass 95% der Ingenieure von
Softwareentwicklung keine Ahnung haben.
Eine Unsitte die mich besonders nervt ist das Verteilen von losen,
unversionierten Dateien per USB-Stick. Da lässt man einen Diplomanden
z.B. mit irgendwelchen vorverarbeiteten Messdaten arbeiten. Wochen
später merkt man dass etwas mit den Daten nicht stimmt, und dann wird
gerätselt mit welcher Softwareversion und welchen Parametern die Daten
wohl erstellt wurden und was dabei schief gegangen sein könnte (die
Originale gammeln auf irgendwelchen USB-Platten vor sich hin und werden
gelöscht wenn gerade kein Platz mehr da ist). Oder es werden
Skriptsammlungen herumgereicht, jeder bastelt seine Erweiterungen dazu,
und am Ende (falls die Zweige denn überhaupt wieder zusammenfinden) ist
vieles doppelt und passt nichts mehr zusammen. Vom eigentlichen
Programmierstil will ich gar nicht reden.
Die IT-Abteilung betreibt einen SVN-Server, aber ich kenne hier
(forschungslastige Abteilung) keinen der ihn benutzt, und kaum einen der
weiß was SVN überhaupt ist. Ich denke mir jedes Mal, wie wunderbar
einfach viele Dinge würden, wenn man einfach sagen könnte "schau in
blafoo/branches/user123, da hab ich ein paar Bugs gefixed" oder
"aktualisier dir die Daten aus mess/xyz, die Verarbeitung wurde
geändert"...
Wie sind eure Erfahrungen? Geht es bei euch auch manchmal so planlos zu?
Nein.
Aus Deinem Post, war der Satz
> Vom eigentlichen> Programmierstil will ich gar nicht reden.
das einzige was mit Softwareentwicklung zu tun hat. Alles andere ist
Organisation, Versionierung etc. hat aber mir der eigentlichen
Entwicklung nichts am Hut.
Hier (große Firma aus dem Bereich Schienenverkehrstechnik, lauter
Elektroingenieure) wird eine zehn Jahre alte Version von Microsoft
Visual Source Safe benutzt. Ach nein, sie wird gar nicht wirklich
konsequent genutzt, vielmehr werden die Dateien meistens auf dem
Netzlaufwerk abgelegt in einem Ordner mit der Versionsnummer.
Warum man nicht was Vernünftiges macht wie Subversion mit z.B.
TortoiseSVN als Client, versteh ich auch nicht. Aber es ist wohl so wie
Du sagst, die Ingenieure die keine Vorlesungen über Softwaretechnik etc.
hatten gehen da wohl eher planlos vor, es sei denn sie haben zuvor schon
mal in einer Firma gearbeitet, in der es richtig anstatt falsch gemacht
wird ;-)
Wenn so gearbeitet wird, ist aber nicht nur der Ing schuld,
sondern auch die Ebene drüber, die das offenbar toleriert.
Selbst eine halbwegs ordentliche Bude achtet auf Versionierung,
Backup etc. und treibt ihre Leute notfalls dahin.
Auch wenn der einzelne Entwickler schon eine Nase dafür haben
sollte und es notfalls auf eigene Faust sinnvoll handhabt,
gehören diese elementaren Dinge firmenweit einheitlich
eingeführt. Ein SVN-Server, der mehrheitlich ignoriert wird,
deutet doch m.E. auf eine planlose Führung hin.
Ich studiere E-Technik in Gießen höre gerade eine Vorlesung namens
"Softwaretools und -management". Der Dozent ist als Gast an der FH und
arbeitet bei Conti. Die haben diese Probleme nicht, wegen DOORS und
anderen Programmen. Versionsverwaltungen sind wohl recht schwierig
einzuführen, der Dozent wird nach eigenen Angaben aber bei keiner Firma
mehr anfangen, die keine verwendet.
Hier sind die Folien:
http://freenet-homepage.de/SWT_2009/
Achso ... gerade DOORS wurde bei Conti vom Quali-Management eingeführt
und nur durch Druck dann auch eingesetzt. Ist wohl das selbe Problem wie
mit Doku, schätze ich. Niemand machts gern aber wenn es fertig ist
extrem hilfreich.
Klaus Wachtler schrieb:
> Wenn so gearbeitet wird, ist aber nicht nur der Ing schuld,> sondern auch die Ebene drüber, die das offenbar toleriert.
Richtig.
> Selbst eine halbwegs ordentliche Bude achtet auf Versionierung,> Backup etc. und treibt ihre Leute notfalls dahin.
Kann durchaus unterschiedlich sein, in der einen Abteilung so und in der
anderen so. Je höher die Informatikerdichte, desto größer ist die
Wahrscheinlichkeit, dass die Versionsverwaltung vernünftig gehandhabt
wird.
> Auch wenn der einzelne Entwickler schon eine Nase dafür haben> sollte und es notfalls auf eigene Faust sinnvoll handhabt,> gehören diese elementaren Dinge firmenweit einheitlich> eingeführt. Ein SVN-Server, der mehrheitlich ignoriert wird,> deutet doch m.E. auf eine planlose Führung hin.
Wenn die Gruppenleiter und der Abteilungsleiter halt allesamt keine
"richtigen" Software-Menschen sind... und die IT an sich outgesourcet
wurde... dann hängt es teilweise von der Initiative eines fähigen
Mitarbeiters ab, der seinen Chef überzeugen kann, hab ich so den
Eindruck.
Hier wurde vor kurzem entschieden, kein DOORS zu verwenden.
Kostet ja Geld...
Firma: weltweit tätiger Blechbieger mit Elektronikanteil. ;-)
Produkte stehen in jedem Haushalt.
>langsam bekomme ich den Eindruck, dass 95% der Ingenieure von>Softwareentwicklung keine Ahnung haben.
langsam bekomme ich den Eindruck, dass das Schubladendenken enorm
zunimmt und immer mehr solche unqualifizierten Threads kommen.
Mal gehts um BWLer, mal um FH vs. Uni, dann wieder um Informatiker.
Solche Pauschalaussagen sind völlig unnötig und werden Dich in Deiner
Laufbahn nur behindern, da Du schon gar nicht mehr unvoreingenommen auf
jemanden zugehen kannst.
Zum Threadersteller:
Ingenieure können programmieren und Informatiker wollen programmieren.
(scnr)
Informatiker wollen aber auch eine schöne bunte IDE mit Hilfe und
Autovervollständiung um eine Mickey Mouse Oberfläche zu basteln.
Es kommt halt immer drauf an was man -die Firma- braucht.
>Aus Deinem Post, war der Satz>>> Vom eigentlichen>> Programmierstil will ich gar nicht reden.>>das einzige was mit Softwareentwicklung zu tun hat. Alles andere ist>Organisation, Versionierung etc. hat aber mir der eigentlichen>Entwicklung nichts am Hut.
Das ist der weit verbreitete Irrtum, durch den dieses Problem überhaupt
erst entsteht. Das Schreiben von Code ist nur ein kleiner Teil der
Softwareentwicklung. Genauso wie das Zusammenschrauben von Trägern nur
ein kleiner Teil der Brückenkonstruktion ist.
> Solche Pauschalaussagen sind völlig unnötig
Ich habe keine Pauschalaussagen gebraucht, sondern eine Prozentzahl die
den gefühlten Anteil des o.g. Problems deutlich machen soll. Ich bin
selbst Ingenieur, und würde mich als recht fähig im Bereich der
Softwareentwicklung bezeichnen.
Gast schrieb:
> Das ist der weit verbreitete Irrtum, durch den dieses Problem überhaupt> erst entsteht. Das Schreiben von Code ist nur ein kleiner Teil der> Softwareentwicklung.
Das ist der weit verbreitete Irrtum, wegen dem meist trotz toller
Prozesse am Ende doch nur instabiler Mist rauskommt.
Ingenör schrieb:
> Zum Threadersteller:> Ingenieure können programmieren und Informatiker wollen programmieren.> (scnr)
Da stimmt nur der erste Teil bedingt. Als Informatiker hielt man sich
schon damals Programmierer, oder - wenn es die nicht gab - E-Techniker.
Ein guter Info ist für's Coden viel zu schade.
Informatik hat mit Programmierung fast nichts zu tun.
Chris D.
Peter: warum scheitern so viele Softwareprojekte? Weil die Programmierer
den Unterschied zwischen Bubblesort und Quicksort nicht kennen? Oder
nicht doch eher, weil
- die Anforderungen unklar sind
- das Gesamtkonzept nichts taugt
- die Abstimmung nicht funktioniert
- zu wenig Zeit zum Testen eingeplant wird
- usw.?
Ein Projekt kann schon vermurkst sein, bevor auch nur eine einzige Zeile
Code geschrieben ist. Und dann kann auch der beste Programmierer nichts
mehr herausholen.
@gast
Das gilt nicht nur für die Softwareentwicklung.
Ich habe graue Haare bekommen, als ich versucht habe herauszufinden, was
in einem Prototypenprojekt zurzeit verbaut ist
(Hardware+Softwarestand)und dazu minimale technische Angaben,
Typenschild hätte meist gereicht.
Selbst die Teileverantwortlichen konnten mir meist keine vernüftigen
Angaben machen.
Ein einfaches, es ist A von B Typ C eingebaut zurzeit ändert sich die
Software in der Erprobungfast täglich, Hardwareunterlagen liegen auf
Laufwerk X: hätte erstmal gereicht.
Das ist für eine technische Abnahme sehr hilfreich.
In DOORS habe ich mal reingeschaut, soll genutzt werden, keiner kennt
sich damit aus oder weiss wie es genutzt werden soll.
In den vielen Firmen geht es so chaotisch zu, weil es an 2 einfachen
Dingen fehlt, der richtigen Kommunikation und Dokumentation.
Eingendlich basiert alles auf einem ganz einfachen Schema :
Firmen, Vorgesetzte , Kollegen müssen begreifen, dass das heutige
Programmieren nicht mehr mit dem aus den 70er/80er Jahren zu vergleichen
ist. Es ist halt auch eine Wissenschaft, bei dem die Ergebnisse nicht
vom Zufall abhängen sondern hart erarbeitet werden müssen. Weiterhin
stellt Software "Firmenkapital" dar, welches durch
Versionkontrollsystemen gesichert werden muss.
Doch solange der Software (bzw. den Programmierern) nicht die nötige
Entwicklungszeit Testzeit Dokumentationszeit zugestanden wird.
Werden immer irgendwelche "Schnellschüsse" herausgegeben. Oft liegt das
Problem weniger am Softwerker als vielmehr an den Randbedingungen.
Wer kennt das nicht, eine "unfertige" Hardware wird einbehalten, bei
einer fertigen Hardware mit unfertiger Software gibt´s ne Freigabe. Es
kann ja "nachgeflashed" werden.
Hmm, man muss halt gute Ideen durchsetzen im schlimmsten Fall erzwingen
können. Kann mir die Arbeit ohne SVN nicht mehr vorstellen, vor allem,
wenn mehrere Leute an einem Projekt arbeiten. Wer es nicht tut, verliert
Zeit und Zeit ist Geld.
Gast schrieb:
> Peter: warum scheitern so viele Softwareprojekte? Weil die Programmierer> den Unterschied zwischen Bubblesort und Quicksort nicht kennen? Oder> nicht doch eher, weil> - die Anforderungen unklar sind> - das Gesamtkonzept nichts taugt> - die Abstimmung nicht funktioniert> - zu wenig Zeit zum Testen eingeplant wird> - usw.?
Na, wenn wir uns davon aufhalten liessen, wuerden wir ja gar kein
Projekt fertig kriegen.
Ich kann dem voll zustimmen. Bin Elektrotechnik Ingenieur. Arbeite seit
ca. 1Jahr als Softwareentwickler bei einem mittelständigen Unternehmen.
Hier geht genauso so ab wie einige beschrieben haben. Arbeite mit
Informatikern zusammen. Die können zwar richtig gut programmieren, aber
aber keinerlei Ahnung von Softwareentwicklung. Nach 1 Jahr konnte ich
durchsetzten, das SVN mit allem drum und dran eingeführt wird.
Was ich mir immer bei diesem Kampf anhören musste --> Wir sind kein
Softwarehaus sondern ein Maschinenbau Unternehmen. Jemand hat es schon
geschrieben, die Programmierung aus den 80er hat mit der heutigen nichts
mehr viel gemeinsam, nur sieht das die entsprechende Ebene nicht.
Mein bestes bis jetzt:
Chef: Wir brauchen in der Tabelle eine neue Spalte, das haben sie doch
in 2 min drinne.
Ich: Das ist doch kein Excel!
Jeder der schon mal in Java Tabellen programmiert hat, weiß von was ich
spreche.
Das Problem ist einfach, das die entsprechenden Vorgesetzten einfach
nicht so die Ahnung davon haben und sagen Dinge zu die in Ihrer Zeit
nicht realisierbar sind...
Aber scheint bei vielen so zu sein
Nein.
Aus Deinem Post, war der Satz
> Vom eigentlichen> Programmierstil will ich gar nicht reden.> das einzige was mit Softwareentwicklung zu tun hat. Alles andere ist> Organisation, Versionierung etc. hat aber mir der eigentlichen> Entwicklung nichts am Hut.> Das ist der weit verbreitete Irrtum, durch den dieses Problem überhaupt> erst entsteht. Das Schreiben von Code ist nur ein kleiner Teil der> Softwareentwicklung.> Das ist der weit verbreitete Irrtum, wegen dem meist trotz toller> Prozesse am Ende doch nur instabiler Mist rauskommt.
Mein Gott. Das ist doch ganz einfach:
Es gibt Programmierer. Das sind die, die einen Code zusammenkloppen
können der dann auch meist läuft.
Und es gibt Softwareentwickler. Das sind die, die einen Code
zusammenkloppen können der dann auch meist läuft und für andere lesbar
ist. Die sich mit Versionierung, Dokumentation, Organisation auskennen
und im Team an größeren Softwareprojekten einsetzbar sind.
Programmieren hab ich im Elektrotechnikstudium gelernt.
Softwareentwicklung erst danach in einem großen internationalen
börsennotierten Softwarekonzern.
>Doch solange der Software (bzw. den Programmierern) nicht die nötige>Entwicklungszeit Testzeit Dokumentationszeit zugestanden wird.>Werden immer irgendwelche "Schnellschüsse" herausgegeben. Oft liegt das>Problem weniger am Softwerker als vielmehr an den Randbedingungen.
Jaja, und wenn man dann mehr Zeit hat, wird die für Dokumetation genutzt
?
Wovon träumst Du eigentlich nachts ? Die Vorstellung, dass zusätzliche
Zeit plötzlich für Dokumentation genutzt würde, ist doch abenteuerlich.
Hatte übrigends mal ein interressantes Jobangebot, nachdem ein Kunde
mich gesehen hat, wie ich während der Kompilierung (dauerte etwa eine
Stunde) eines Projektes an der Doku gearbeitet habe. Alle anderen waren
Kaffee trinken. Der wollte mich sofort abwerben.
Gruss
Axel
...wer ernsthaft SW entwickeln will kommt ohne DOORS und SVN (o.ä.)
einfach nicht aus. Und der Rest entwickelt nicht ernsthaft :) So beka**t
das teilweise auch ist, ohne gehts halt nicht - merkt man aber selbst
nach dem ersten Monat.
Klaus.
hmm,
ist das nicht Normal das Doku schreibt man ad hoc, nur dann wenn Zeit
ist?
Kompilierung, Source einchecken, automatische Test usw. Das ist Zeit für
Doku schreiben. Sonst keine, oder so kurz das kann man vergessen.
Beim Thema DOORS habe ich immer dein Eindruck, dass da ein paar
Wirtschaftsinformatik Praktikanten aus dem 1. Semester 3 Wochen bestraft
wurden. Hauptziel: Excel mit Versionierung und möglichst schlechtem
Linkkonzept zu vergewaltigen.
Das Tool ist einfach grauenhaft.
Hmm, ich kenn das Problem eher andersrum. Die Leute kennen sich mit
allerhand Tools (darunter auch svn, UML-Tools,.......) sehr gut aus.
Das Codieren an sich ist dann eher das große Problem. Abstrakte
Konstrukte,
Basisklassen, deren Verwendung und Design-Patterns werden heute von den
meisten Softwareentwicklern nicht mehr beherrscht.
Dafür gibts ja die Automatische Code-Synthese -> einfach auf den Knopf
drücken und die Software kommt hinten raus ;-)
Das erste ,was ich in einer Exfirma vermittelt bekam war,
auf solche Tools zu verzichten. Denn dieser Codec ist
zu lang , oftmals fehlerbehaftet bzw fehlerinduzierend
also nicht ernsthaft zu gebrauchen, weil er das Compilat
versaut.
Die konsequente Beherzigung dessen führte zu excellenten
Programmen so gut , daß die GL sukzessive die Macher
feuerte ...
Insofern kann im Umkehrschluß gesagt werden - Ihr wollt
eine gewisse Unkündbarkeit , dann verwendet ........
>Das erste ,was ich in einer Exfirma vermittelt bekam war,>auf solche Tools zu verzichten.
Erinnert mich an meine Erfahrungen mit Lex und Yacc an der FH. Seitdem
mache ich um synthetischen Code einen großen Bogen. Selbst wenn die
Tools heute besser geworden sind... Aber auch Menschen können schlechten
Code erzeugen.
Schoen fuer dich, es gibt auch Leute, denen ist Windows noch nie
abgestuerzt...
Wenn 150 Entwickler an einem Repository haengen mit zig Branches und
taeglichem Gemerge sieht's ein bisschen anders aus als bei Miniprojekten
mit einer Hand voll Leuten.
>Wenn 150 Entwickler an einem Repository haengen mit zig Branches und>taeglichem Gemerge sieht's ein bisschen anders aus als bei Miniprojekten>mit einer Hand voll Leuten.
Und was schlägst du als Alternative vor? Alle machen ihren Mist lokal
und am Ende dürfen alle 6 Monate lang alles zusammenmergen?
Was soll dabei schiefgehen? Das Repository ist transaktionsbasiert und
sehr einfach aufgebaut. Ein Changeset, eine neue Datei. Da kann nichts
kaputt gehen. Natürlich kann sich der Benutzer in Merge-Konflikten
verheddern, aber das ist ein Problem der richtigen Anwendung.
Arne:
Du würdest aber nicht ernsthaft einen Analyzer und Parser in C
schreiben, oder?
Bei Codegeneratoren muss man zwei Fälle unterscheiden:
- Code, der nach der Erzeugung nicht mehr von Hand bearbeitet wird.
Solche Tools sind z.B. für den Compilerbau unverzichtbar (Lex, Yacc).
- Code, der nur einmal erzeugt und dann von Menschen weiterbearbeitet
wird. Wenn der erzeugte Code nur aus ein paar einfachen leeren Gerüsten
besteht, dann kann das durchaus sinnvoll sein. Ein Problem wird es, wenn
der Generator umfangreichen Programmcode erzeugt, entweder aus einer
Standardvorlage oder aus eingegebenen Ablaufdiagrammen o.ä., und man mit
diesem Code weiterarbeiten soll. Das verstößt gegen das Prinzip der
Modularisierung, weil man "fremden" mit selbstgeschriebenem Code
vermischt, statt durch eine Schnittstelle zu trennen.
