SW Entwickler programmieren nicht.

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.

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.