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.
Hier gibt es ein interessantes Video zum Thema Software-Engineering, bei dem auch auf die angesprochenen Punkte eingegangen wird: http://www.ulm.ccc.de/ChaosSeminar/2007/07_Software_Engineering
@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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.