Hallo, ich möchte folgenden Beitrag aus einem anderen thread hier nochmal aufgreifen: Ausheultaschentuchübergeber schrieb: > NULL schrieb: >> Ich sehe das als sehr kritisch, denn das heißt ich werde nach Jahren in >> diesem Unternehmen zum VB6 "Expert" > > Und kannst dann den weiteren Weg bestimmen. Tools wechseln, anderen die > Fleissarbeit abtreten und nur um die harten Nüsse kümmern. Sind doch > gute Aussichten. > ... > > Urmel aus dem Eis schrieb: >> Die Stärken eines guten Software >> Entwicklers sollten ohnehin im Software-Entwurf/Architektur und der >> Modellierung liegen > > So sieht es aus! Völlig egal in was später codiert wird. Codieren ist > nur noch Fleissarbeit und kann heute von Studenten und morgen > automatisch erfolgen. Ich würde wirklich gerne mal Jemanden kennenlernen, der sich SW-Entwickler nennt, aber nicht aktiv programmiert. In meinen 30 Jahren Berufserfahrung in der IT Welt habe ich immer wieder irgendwelche fachfremde Besserwisser erlebt, die fest davon überzeugt waren, dass Codieren (egal in welcher Programmiersprache) minderwertige oder automatisierbare Arbeit ist, die der Entwickler irgendwohin deligieren könnte. Auf der Anderen Seite habe ich aber bislang keinen einzigen Entwickler kennengelernt (erst recht keinen Seniorentwickler oder Architekten), der nicht selber codiert/programmiert. Was machen diejenigen dann und welche Werkzeuge benutzen sie, wenn nicht Entwicklungswerkzeuge? Wenn Entwickler sich tatsächlich von der praktischen Umsetzung von (abstrakten) Modellen lösen können, warum findet man dann keine Stellenanzeige für SW-Entwickler ohne Kenntnisse in einer oder mehreren Programmiersprachen als Voraussetzung? Danke, gnugnu
Schon mal was vom Job des Softwarearchitekten gehört. Auch bei den SW-Entwicklern gibt es Leute, die die Software GRUNDSÄTZLICH konzipieren. Vor allem dann, wenn es eine komplexe Software werden soll, die auf mehrere Plattformen laufen soll und im Laufe des Betriebs auch gewartet, erweitert und ab und an modifiziert werden soll. Ein Programmierer allein hat darauf eine streng begrenzte Sicht und soll nur ein Modul programmieren, wo ihm dann nur das Verhalten und die Schnittstellen mitgeteilt werden. Sicher sollte der Softwarearchitekt sich mit dem Material vertraut gemacht haben, wo die Software realisiert wird. Also die Randbedingungen der Hardware, die Leistungsfähigkeit der Programmiersprache und auch das Können der Programmierer. Also gibt es tatsächlich Informatiker, die nicht selbst programmieren, sondern die Informations- und Datenverarbeitung konzipieren und synthetisieren auf einem abstrakten Level. Wie sie dann konkret mit welchen Variablen, Strukturen, Klassen und Objekten programmiert wird, darauf hat er keinen Einfluss. Daher wird auch bei einem universitären Informatikstudium auch nicht darauf Wert gelegt, dass eine Programmiersprache in und auswendig beherrscht werden soll. Ich als Elektrotechniker kann nur Embedded Systeme programmieren. Bei einer großen Anwendungssoftware würde mir schon die Erfahrung fehlen, wo und wie ich anfangen soll.
gnugnu schrieb: > Was machen diejenigen dann und welche > Werkzeuge benutzen sie, wenn nicht Entwicklungswerkzeuge? Wenn > Entwickler sich tatsächlich von der praktischen Umsetzung von > (abstrakten) Modellen lösen können, warum findet man dann keine > Stellenanzeige für SW-Entwickler ohne Kenntnisse in einer oder mehreren > Programmiersprachen als Voraussetzung? Das Werkzeug ist eine geeignete grafische Darstellung wie UML, das mit MS Visio oder auch besseren Open-Source-Tools umgesetzt wird. Oder er schreibt ein Dokument in Word, indem die Software geplant werden soll. So etwas Ähnliches, wie es der Ingenieur mit dem Lastenheft macht. Das ist auch keine Programmierung mit einer Programmierumgebung, gehört aber zur SW-Entwicklung. Auch gibt es Stellenangebote, die explizit einen SW-Architekten suchen. Natürlich geht man davon aus, dass der auch programmieren kann. Also hat ein SW-Architekt in seiner Untermenge auch den Programmierer drin, aber umgekehrt der Programmierer nicht unbedingt auch SW-Architektur kann.
HBich schrieb: > Schon mal was vom Job des Softwarearchitekten gehört. Auch bei den > SW-Entwicklern gibt es Leute, die die Software GRUNDSÄTZLICH > konzipieren. Vor allem dann, wenn es eine komplexe Software werden soll, > die auf mehrere Plattformen laufen soll und im Laufe des Betriebs auch > gewartet, erweitert und ab und an modifiziert werden soll. > Danke für die Antwort. Daraus geht sehr klar hervor, dass Du nur eine sehr grobe Vorstellung von der Praxis der Entwicklung hast. Ich bin "Architekt." Auch als solcher gehört für mich der Umgang mit den Werkzeugen - gerade und insbesonders Cross-Plattform - zum alltäglichen Handwerkszeug. So Fragen wie "wir würden gerne dieses und jenes Feature plattformübergreifend verwenden, können es aber nicht, weil die Realisierung des features auf Version xyz von Compilerversion abc einen bug hat" kann nicht "nur" ein "einfacher Programmierer" lösen. > Ein Programmierer allein hat darauf eine streng begrenzte Sicht und soll > nur ein Modul programmieren, wo ihm dann nur das Verhalten und die > Schnittstellen mitgeteilt werden. Ich habe mal bei einer Firma gearbeitet, wo das Team aus einem Tech Lead ("Zusammenknüpfer") und Entwicklern ("Modulrealiserer") bestand. Da gab es das "Wasserfallmodell," bei dem der Projektkoordinator die Modularisierung vorgegeben und an den Tech Lead weitergereicht hat, der die Einzelmodule an die Entwickler (!) weitergegeben und dann die Ergebnisse integrationsgetestet hat. Nach deinem Modell wäre der Tech Lead hier der "SW-Entwickler" gewesen, und die Entwickler die "Programmierer." Der Projektkoordinator darüber war in der Regel mehr Manager und aus der Technik so weit heraus, dass er zu konkreten Fragen der Entwicklung sowieso nichts (mehr) sagen konnte oder wollte. Allerdings war die Aufgabe des Tech Leads nichts "höherwertiges" oder "wichtigeres" als das der Anderen. In der Tat hat die Position des Tech Leads von Projekt zu Projekt variiert, und in den Allermeisten Fällen hat der Tech Lead selber auch an einem Model mitentwickelt. Da war überhaupt nichts mit "die hochqualifizierten Entwickler" gegenüber "die Programmierer, die die Fleiss- oder Drecksarbeit machen." Ein Tech Lead in einem Projekt war typischerweise im nächsten Projekt wieder "normaler Entwickler." > > Sicher sollte der Softwarearchitekt sich mit dem Material vertraut > gemacht haben, wo die Software realisiert wird. Also die Randbedingungen > der Hardware, die Leistungsfähigkeit der Programmiersprache und auch das > Können der Programmierer. > Hast Du mal was von Architekten wie Gordon Letwin oder Dave Cutler gehört? Die haben hauptsächlich programmiert. Das "Können der Programmierer" beurteilen und die demzufolge einsetzen zu können hat überhaupt nichts mit technischer Aufgabenstellung zu tun. Es wäre schön, wenn die Personalverantwortung des Gruppenleiters Entwicklung durch einen technischen Hintergrund abgedeckt wird, aber das ist eine reine Mangagementaufgabe, und Jeder, der die übernimmt, wird durch die politische Firmenarbeit innerhalb kürzester Zeit zum reinen Kapazitätsverwalter. Viele Gruppenleiter sind Quereinsteiger. > Also gibt es tatsächlich Informatiker, die nicht selbst programmieren, > sondern die Informations- und Datenverarbeitung konzipieren und > synthetisieren auf einem abstrakten Level. > Ich habe nicht nach "Informatikern" gefragt, die nicht codieren, sondern "SW Entwicklern," die nicht codieren. Selbstverständlich hat die Arbeitsrealität und Aufgabenteilung in der IT so viele Facetten, dass es auch für Leute mit Abschluss (Informatiker) nicht oder weniger technische Aufgabengebiete gibt. > Wie sie dann konkret mit welchen Variablen, Strukturen, Klassen und > Objekten programmiert wird, darauf hat er keinen Einfluss. > Daher wird auch bei einem universitären Informatikstudium auch nicht > darauf Wert gelegt, dass eine Programmiersprache in und auswendig > beherrscht werden soll. > > > Ich als Elektrotechniker kann nur Embedded Systeme programmieren. > Bei einer großen Anwendungssoftware würde mir schon die Erfahrung > fehlen, wo und wie ich anfangen soll. Damit implizierst Du, dass eine Anwendersoftware mehr wert oder komplexer ist als ein Embedded System. Wie kommst Du darauf? Ist nicht ein Characteristikum eines Embedded Systemes, dass seine Kommunikation mit der Aussenwelt ein zentraler Flaschenhals des Gesamtsystems ist und damit eine in sich abgeschlossene Betrachtungsweise eine Sackgasse? In Allen hinreichen komplexen Embedded Systemen, die ich kennengelernt und mit denen ich zu tun hatte, wäre die Sichtweise "ich tue hier nur meinen Teil, und den Rest machen Andere" für den Entwickler völlig unmöglich gewesen. Das fängt schon mit so Fragen an, dass die Kommunikationstask entweder niedrig priorisiert sein muss (um das was das ES lokal tut nicht auszubremsen) oder High Pri (damit die Hostkommunikation nicht ausgehungert wird). Das kann natürlich Jemand von oben enifach festlegen, ändert aber nichts daran, dass Du die als ES Entwickler trotzdem realisieren und testen und debuggen musst, und das geht nun mal nicht in der Sandkiste.
Ich wär gern Architekt, bin aber nur Programmierer, weil mich niemand befördert.
Wieder mal ein nutzloser thread, wo Elektroniker darüber sinnieren, was Softwareentwicklung ist und bei dem keine je mehr gemacht hat, als ein aar Controller programmiert. Mit IT oder Informatik hat das alles nichts zu tun.
Wird wohl ähnlich wie bei Hardwareentwicklern sein. Die müssen (zumindest in größeren Firmen) auch weder löten noch eine Leiterkarte fertigen. Und so etwas wird auch im Studium nicht gelehrt. Es ist dennoch besser, wenn der HW-Entwickler es kann bzw. mal gesehen hat.
Martin K. schrieb: > Wieder mal ein nutzloser thread, wo Elektroniker darüber sinnieren, was > Softwareentwicklung ist und bei dem keine je mehr gemacht hat, als ein > aar Controller programmiert. Mit IT oder Informatik hat das alles nichts > zu tun. Liegste sowas von komplett daneben... bin Informatiker und habe auf Allen möglichen Ebenen und Plattformen entwickelt. Windows, Linux/Unix, RTOS, C, C++, C#, Basic, Lisp, you name it. Aber scheinbar bist Du ja noch wesentlich erleuchteter, dann führe uns doch mal ans Licht.
Ist es nicht just das, was bei Outsourcing geschieht? Die Vorgaben werden von deutschen Informatikern erstellt, “runtergecodet” wird es in Osteuropa. Freilich fallen damit auch manche auf die Fresse.
Martin K. schrieb: > Wieder mal ein nutzloser thread, wo Elektroniker darüber sinnieren, was > Softwareentwicklung ist und bei dem keine je mehr gemacht hat, als ein > aar Controller programmiert. Mit IT oder Informatik hat das alles nichts > zu tun. Deinem Beitrag nach kannst du nicht mal das, oder warum trägst du dann nichts sinnvolles bei?
> Was machen diejenigen dann und welche > Werkzeuge benutzen sie, wenn nicht Entwicklungswerkzeuge? Früher die Malschablone von IBM für die Flussdiagramme, heute UML (Rational ROSE, anyone?) > warum findet man keine > Stellenanzeige für SW-Entwickler ohne Kenntnisse in einer oder mehreren > Programmiersprachen als Voraussetzung? Da solche Tätigkeiten am Familiensilber des Grossen Produktes der Firma stattfinden, lässt man da ungerne "Neulinge" ohne Vorwissen ran (also kein frisch Angestellter, egal wieviel BE er mitbringt) sondern daran setzt man vorwiegend Alte Hasen mit vielen Dienstjahren an ebendiesem Produkt. Das ist zumindest was ich in meinem Vierteljahrhundert BE erlebt habe; es wundert mich dass Du mit 30J nie solches miterlebt hast. Bist Du Wanderarbeiter? Ich habe in 25J "nur" 4 AG mitgemacht, 2 davon lange Zeit und nie in Jubelelektronik sondern immer nur in ES f. Infrastrukturprodukte (SCADA, Telekom & ATC-VCS, Messtechnik f. Wasser-&Energieversorger) Die Aufgabenzuteilung "Architekt" habe ich immer dynamisch erlebt: so war auch ich zeitweise "Papiertiger" und malte nur UML & schrieb Spezifikationen. Dies meist in Bereiche wo ich vorher "nur Coder" war und genau dadurch besonders passende Kenntnisse zur Sache erwarb. Implementiert habe das manchmal ich, manchmal aber auch meine Kollegen. Sogar als "nur Tester" (angeblich noch ne Stufe unter Coders...) wurde ich systematisch zu Architektur&Design-Gestaltungsrunden miteinbezogen: weil ich wohl mehr Systemsicht und "Überhorizontdenke" an den Tag legte als andere Kollegen. Es ist nun mal so dass nicht jeder -egal wie gut er in gewissen Bereichen ist- alle anderen Aspekte genau so gut kann. Letztlich liegt es am "Chef" ob er ein gutes Händchen hat seine "wilde" Truppe zu dirigieren, die jeweiligen Teilaufgaben so dem "richtigen" zuzuschanzen dass die Truppe darob nicht noch wilder wird...
Seoul schrieb: > Ist es nicht just das, was bei Outsourcing geschieht? > > Die Vorgaben werden von deutschen Informatikern erstellt, > “runtergecodet” wird es in Osteuropa. Freilich fallen damit auch manche > auf die Fresse. In Unternehmen, in denen sich die Finanzler und "Strategen" etwas zu wichtig nehmen, und Techniker keiner ernst nimmt, da läuft das so. Von den Buden bleibt am Ende noch der Markenname, wenn man dann alles (natürlich im Rahmen einer ganz tollen Strategie) ausverkauft hat. Solche Firmen können auch einfach Döner verkaufen, Hauptsache man scheffelt irgendwie Kohle.
gnugnu schrieb: >> So sieht es aus! Völlig egal in was später codiert wird. Codieren ist >> nur noch Fleissarbeit und kann heute von Studenten und morgen >> automatisch erfolgen. Wenn sich Computer selbst automatisch programmieren, ist das der Moment der technischen Singularität? Ala "Alexa, programmiere mir Skynet"? Lohnt es sich überhaupt, darauf hin zu spekulieren und ggf. seine Karriere daran auszurichten, denn schließlich ist alles ab da unvorhersehbar, und mehr das Gebiet von Sci-Fi? Ähnlich sinnvoll wäre es zu sagen "ich mache nichts mit Mensch-Maschine-Interaktion weil im Falle einer Alien-Invasion wäre diese Qualifikation hinfällig".
PS: Was ist das für eine Software, die von Studenten programmiert werden kann? Die meisten (Informatik-)Studenten die ich kenne bringen selbsttätig nur die simpelsten Programme zuwege, die muss man ganz genau anleiten - und da könnt man's schneller selbst machen.
Dr. Sommer schrieb: > gnugnu schrieb: >>> So sieht es aus! Völlig egal in was später codiert wird. Codieren ist >>> nur noch Fleissarbeit und kann heute von Studenten und morgen >>> automatisch erfolgen. Falsch zugeordnetes Zitat! Das habe nicht ich geschrieben, sondern Jemand mit Nick "ausheulentaschentuchübergeber." Ich habe das im Gegenteil zitiert, weil ich nicht im Geringsten mit diesem Mythos übereinstimme! > Wenn sich Computer selbst automatisch programmieren, ist das der Moment > der technischen Singularität? Ala "Alexa, programmiere mir Skynet"? > Lohnt es sich überhaupt, darauf hin zu spekulieren und ggf. seine > Karriere daran auszurichten, denn schließlich ist alles ab da > unvorhersehbar, und mehr das Gebiet von Sci-Fi? Ähnlich sinnvoll wäre es > zu sagen "ich mache nichts mit Mensch-Maschine-Interaktion weil im Falle > einer Alien-Invasion wäre diese Qualifikation hinfällig". Nach meinem Wisensstand ist die Programmierung im Sinne von "eine Problemstellung als programmierBARE Prozedur formulieren, in Code umsetzen, auf Richtigkeit testen, ggf. fehlerfrei umschreiben sowie im Falle von nicht praktisch umsetzbaren Vorgaben Alternativen zu formulieren und von Vorne anzufangen" nur zu einem sehr kleinen überschaubaren Teil automatisierbar.
Dr. Sommer schrieb: > PS: Was ist das für eine Software, die von Studenten programmiert werden > kann? Die meisten (Informatik-)Studenten die ich kenne bringen > selbsttätig nur die simpelsten Programme zuwege, die muss man ganz genau > anleiten - und da könnt man's schneller selbst machen. Full ACK, und stützt vollständig meinen Punkt, dass Programmierung oft fälschlicherweise als "stumpfsinniges minderwertiges Handwerk, das eines studierten Informatikers unwürdig ist" herabgewertet wird.
gnugnu schrieb: > Falsch zugeordnetes Zitat! Das habe nicht ich geschrieben, sondern > Jemand mit Nick "ausheulentaschentuchübergeber." Schon klar, wollte einfach nur meinen Senf zu dieser Aussage abgeben, ist ja schließlich das Thema dieses Threads :-) gnugnu schrieb: > Full ACK, und stützt vollständig meinen Punkt, dass Programmierung oft > fälschlicherweise als "stumpfsinniges minderwertiges Handwerk, das eines > studierten Informatikers unwürdig ist" herabgewertet wird. Sehe ich auch so. Es gibt genug Programmier-Aufgaben an denen auch Informatik-Master scheitern - wer soll die dann können? Super-Informatiker?
noch so'n gnu schrieb: >> Was machen diejenigen dann und welche >> Werkzeuge benutzen sie, wenn nicht Entwicklungswerkzeuge? > Früher die Malschablone von IBM für die Flussdiagramme, heute UML > (Rational ROSE, anyone?) > >> warum findet man keine >> Stellenanzeige für SW-Entwickler ohne Kenntnisse in einer oder mehreren >> Programmiersprachen als Voraussetzung? > Da solche Tätigkeiten am Familiensilber des Grossen Produktes der > Firma stattfinden, lässt man da ungerne "Neulinge" ohne Vorwissen ran > (also kein frisch Angestellter, egal wieviel BE er mitbringt) sondern > daran setzt man vorwiegend Alte Hasen mit vielen Dienstjahren an > ebendiesem Produkt. Das sind sehr gute Punkte, die ich auch so weit unterschreiben kann. Allerdings stosse ich mich an diesem "die Programmierer da unten gegenüber den Entwicklern da oben" Mythos, der speziell an Hochschulen immer noch kultiviert wird. Der "alte Hase," der das Familiensilber bewahrt (gute Metapher!) ist meiner Erfahrung nach Niemals Jemand, der sich für die Programmierung "zu fein" war, sondern in aller Regel am Code des Softwarehauses selber seine Handschrift hinterlassen hat und jederzeit wieder Hand an den Code anlegt und das in der Regel auch immer wieder tut. > > Die Aufgabenzuteilung "Architekt" habe ich immer dynamisch erlebt: so > war auch ich zeitweise "Papiertiger" und malte nur UML & schrieb > Spezifikationen. Dies meist in Bereiche wo ich vorher "nur Coder" war > und genau dadurch besonders passende Kenntnisse zur Sache erwarb. > Implementiert habe das manchmal ich, manchmal aber auch meine Kollegen. > Sogar als "nur Tester" (angeblich noch ne Stufe unter Coders...) wurde > ich systematisch zu Architektur&Design-Gestaltungsrunden miteinbezogen: > weil ich wohl mehr Systemsicht und "Überhorizontdenke" an den Tag legte > als andere Kollegen. Ja, stützt auch meinen Punkt, dass es die rigide Trennung zwischen Entwicklern und Programmieren nicht geben kann (s.u.) > Es ist nun mal so dass nicht jeder -egal wie gut er in gewissen > Bereichen ist- alle anderen Aspekte genau so gut kann. > Wieder full ACK. Allerdings habe ich es noch nie erlebt, dass Jemand "nur besser modellieren kann als Andere," ohne auch zu wissen, wie diese Modelle praktisch umgesetzt werden können. Jedenfalls ist von Leuten, die sich so gesehen haben, in meinem Berufsumfeld niemals ein feldtaugliches Produkt in den Markt gegangen. > Letztlich liegt es am "Chef" ob er ein gutes Händchen hat seine "wilde" > Truppe zu dirigieren, die jeweiligen Teilaufgaben so dem "richtigen" > zuzuschanzen dass die Truppe darob nicht noch wilder wird... Ja, wie ich schon schrieb, ist ein guter Entwicklungsleiter Gold wert.
Jeder SW-Entwickler programmiert in irgendeiner Form. Es gibt SW-Architekten etc. die das größere System im Auge haben, aber jeder Architekt sollte auch programmieren können und meistens werden diejenigen zu Architekten, die das besonders gut können. So sollte es zumindest sein. Ich kenne zwar keinen hab aber davon gehört das es tatsächlich Architekten geben soll, die nicht programmieren können. Ich könnte so jemand nicht ernst nehmen und ich glaube die meisten anderen auch nicht. In der IT sind die Dinge zu schnell in Bewegung um SW Architektur zu machen, ohne die entsprechenden Frameworks zu kennen.
Im großen und ganzen stimme ich dir auch zu. Das Programmieren selbst wir meiner Meinung nach oft unterschätzt. Um so erfreulicher war es für mich die "software craftsmanship" Initiative zu entdecken. Die versuchen das Programmieren als echtes und wichtiges Handwerk wieder in den Fokus zu stellen. Ich finde besonders in der Softwareentwicklung ist der Skill-level-unterschied extrem. Zwischen einem totalen Anfänger und einem Überflieger ist locker ein Factor 10 dazwischen. Ein team von 3 Überflieger die das 3 fache Gehalt bekommen, ist wesentlich produktiver, effektiver und letztendlich wesentlich wirtschaftlicher als 10 "durchschnitts-"Entwickler. Aber erstmal muss man die Überflieger finden und der rest muss ja auch irgendwo unterkommen.
Ben W. schrieb: > Aber erstmal muss man die Überflieger finden und der rest muss ja auch > irgendwo unterkommen. Vor allem muss das Team am Ende irgendwie fachlich und auch menschlich (mindestens genauso wichtig!) zueinander passen, damit es effektiv arbeitet. Das kennt man ja aus dem Fußball, wenn wahllos Stars zusammengekauft werden, die dann nicht zusammenarbeiten.
Qwertz schrieb: > Das kennt man ja aus dem Fußball, wenn wahllos Stars zusammengekauft > werden, die dann nicht zusammenarbeiten. Eigentlich ein schönes Beispiel auch wenn ich Fussball nicht mag. Nach dem Modell der Theoretiker gewinnt Bayern also deshalb alles weil sie billige Idioten die den Ball kicken können einsetzen und einen Fussballarchitekten. Oder hab ich jetzt was falsch verstanden ;-)
Früher (vor den Hochsprachen) gab es Programmierer, die Quasi die Arbeit des Compilers erledigt haben. Heute gibt es immer noch Programmierer, die starre Dinge Umsetzen. Z.B. Leute, die um ein halbes Cent zu sparen, C Code der Vorserienentwicklung in noch kleineren Assembler-Code quetschen, bei Stückzahlen > 1E6. Die Frage ist nun, ob man z.B. Leute, die Geschäftsprozesse in UML modellieren, auch als SW-Entwickler bezeichnet. Ich würde sagen, nur dann, wenn diese UML-Diagramme über reine Bilder hinaus gehen und die Information durch z.B. einen imaginären Compiler interpretiert werden kann. In dem Fall sind es Softwareentwickler, die in der Sprache UML programmieren. Oder anders herum: Wenn modellieren nicht programmieren ist, dann "modellieren" die meisten C-Programmierer halt in C. Wenn die UML-Diagramme nur bunte Bilder sind, deren Sinn sich nur durch implizite Konventionen ergibt, dann sind es Visionen, Beschreibungen, Vorgaben, was auch immer, von Experten, Managern, Designern, was auch immer, aber keine Softwareentwickler, auch keine Software-Architekten. Als Analogon: Auch wenn ich vorgebe, dass das neue Geräte nur 100mW aufnehmen darf und einen 5V-Eingang hat, bin ich kein Hardware-Entwickler.
Achim S. schrieb: > (..) > Wenn die UML-Diagramme nur bunte Bilder sind, deren Sinn sich nur durch > implizite Konventionen ergibt, dann sind es Visionen, Beschreibungen, > Vorgaben, was auch immer, von Experten, Managern, Designern, was auch > immer, aber keine Softwareentwickler, auch keine Software-Architekten. > > Als Analogon: Auch wenn ich vorgebe, dass das neue Geräte nur 100mW > aufnehmen darf und einen 5V-Eingang hat, bin ich kein > Hardware-Entwickler. Stimmt. Das Problem ist folgendes: Wenn ein solcher UML "Experte" Software modelliert, die dann von Programmierern in Code umgesetzt wird, kommt meistens Müll dabei raus, sobald es komplex wird. Es war ja ursprünglich mal so gedacht analog zum Wasserfallmodell bzw. der Hardwareentwicklung. Planen vs. Bauen, Es funktioniert aber nicht für moderne Softwareentwicklung. Es gibt sowas vllt. noch bei sehr hardwarenaher Programmierung, wo man Treiber nach Spezifikationen umsetzen muss oder irgendwelche Registerdefinitionen schreibt, aber das hat imho nicht viel mit Softwareentwicklung zu tun. Aber ja ich habe das mal gesehen und da wurden tatsächlich "Programmierer" eingesetzt und daher kommt wohl auch die alte Unterscheidung zwischen Programmierer und Entwickler. Ich denke in Zukunft wird das noch weniger, weil man es automatisieren kann.
> Re: SW Entwickler programmieren nicht.
Was soll der Endwiggler denn sonst machen ?
Flotte Sprüche klopfen und Schau machen ?
Blender haben wir doch wirklich genug.
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.