Re: Informatik .....
Martin Schoenbeck wrote:
>
>
> Thomas George wrote:
>>
> Das Problem ist, daß hier Äpfel mit Birnen verglichen werden. Was der
> Maurer tut, ist lediglich (nicht abwertend gemeint) den fertigen,
> komplett ausgearbeiteten Entwurf des Architekten umzusetzen. Dies
> entspricht aber eher demjenigen, der nachher die CD mit dem fertigen
> Programm dupliziert oder die fertige Software auf Rechnern installiert,
> als dem Programmierer. Ein Informatiker, der nicht programmieren kann,
> taugt allenfalls für theoretische Informatik, aber nicht für den Einsatz
> in irgendwelchen Projekten. Und ein reiner Programmierer, der keine
> Ahnung von Software Engineering hat, sollte besser auch nie mehr
> codieren, als er auf einem Bildschirm überblicken kann.
Dem muß ich ganz und gar widersprechen - ich glaube du unterschätzt die
Arbeit von Maurern gewaltig. Im übrigen hat hier ja niemand gesagt ein
Informatiker solle/dürfe/müsse nicht programmieren können sondern daß man
zur Implementation einer fertigen Lösung keinen Informatiker braucht.
Irgendwie behagt mir diese Sichtweise es gäbe nur "richtige Informatiker"
und "Hilfsarbeiter" nicht so sehr.
> IMHO ist der Vergleich mit einem Operationsteam viel zielführender. Und
> eine entsprechende Team-Organisation natürlich auch. Ein zentraler Kopf,
> der die entscheidende Arbeit aber eben auch selbst erledigt. Und eine
> Reihe von Spezialisten, die ihm zuarbeiten.
Nicht alles was hinkt ist ein Vergleich ;-)
Der Maurer - Architekten Vergleich wird von den meisten Leuten einfach zu
extrem gezogen. Die meisten Leute die ich tagtäglich in der Praxis sehe
*sind* Maurer - ich sehe ja kaum Architekten. Es gibt einige große
Architekten wie Knuth, Sedgewick & Co. deren Entwürfe als Fertighäuse immer
wieder aufgestellt werden. Nicht jeder der den Titel Informatiker trägt
verdient es hier als Architekt gezählt zu werden!
>> > ich sehe mich als "Künstler" - nicht weil ich glaube die Sachen die ich
>> > mache wären so gut das es schon Kunst ist, sondern weil IMHO die
>> > kreative Arbeit des Programmierens sich nicht von der Arbeit z. B.
>> > eines Komponisten unterscheidet. Daraus ergibt sich natürlich eine
>> > natürliche Abneigung gegen
>>
>> Manchmal sehe ich das auch so, aber manchmal dann wieder nicht.
>
> Das aber gerade ist das Dilemma, gute Leute, ob Informatiker oder
> Programmierer, zu finden. Die müssen auf der einen Seite kreativ sein,
> auf der anderen Seite aber auch sehr diszipliniert. Und das findet man
> zusammen leider selten, sehr selten.
Ist schade aber ist so...
>>
>> > alle Regulierungsversuche aus der "Software-Engineering" Lobby die den
>> > kreativen Schaffensprozess lenken, beschränken behindern und
>> > beherrschen wollen. "Software-Engineering" ist der Versuch des
>> > Managements die unbeherrschten Künstler in kalkulierbare Bahnen zu
>> > lenken.
>>
>> Ich verabscheue IDEs, die einem alles vorkauen. Genau dann naemlich wird
>> man zum Nichtskoenner. Und viel Arbeit nehmen die einem auch nicht ab,
>> wnn man was ernsthaftes macht. Da lobe ich mir meinen emacs, den
>> Compiler und ein, zwei gute Buecher zum Thema.
>
> Die IDEs haben ja nun mit Software-Engineering gar nichts zu tun. Die
> Ablehnung des Software-Engineering ist aber gerade das Problem der
> Nur-Künstler. Die dann unwartbare und untestbare Software schaffen.
Nein - was ist denn schon "Software Engineering". Es ist der
Managementgeprägte Begriff für eine Tätigkeit die identisch ist mit
Programmieren selbst. Indem man "Engineering" ins Spiel bringt versucht man
die kreativität der Tätigkeit zu verleugnen um sie wirtschaftlich
berechenbar zu machen. "Engineerte" Arbeit ist billiger als "Kreative"
Arbeit! Ein guter Programmierer braucht kein "Software Engineering" weil
seine Fähigkeiten als guter Programmierer alleine zu wartbaren und guter
Software führen. Schlechte Programmierer glauben heutzutage ihre Probleme
wären mit SE alleine lösbar. Immer mehr schlechte Programmierer scheinen zu
glauben daß das wichtigste beim Programmieren ein standardkonformes
UML-Diagramm ist, vollständig vergessend daß solche Diagramme nur zur
Verbesserung der Kommunikationsbandbreite des Entwicklungsteams dienen.
Wir dürfen uns bezüglich der Definition des Programmierers als Künstler
nicht von unserem geistigen Auge einen Streich spielen lassen - es geht
hier nicht um eine exzentrische, launische aber irgendwie geniale Person
wie das Metaphorische Bild eines Künstlers für die meisten aussieht. Durch
Begriffe wie "verkünstelt" und die heutzutage allgemein schlechte Meinung
gegenüber Künstlern (Faulenzer, Verrückte...) wird die Sicht dessen was
einen Künstler eigentlich auszeichnet nur behindert.
>> Bei Software-Projekten ist es allerdings die Pure Notwendigkeit
>> regulierend einzugreifen. Insofern habe ich grosses Verstaendnis dafuer,
>> wenn einem ein _sinnvolles_ SE-Tool zur Pflicht gemacht wird,
>
> Kein Tool kann Software-Engineering. Das ist ein mentaler Prozess,
> Software kann da nur helfen. Aber eben nur dem, der es begriffen hat.
> Und der braucht sie dann eigentlich nicht unbedingt. Es ist ein (teurer)
> Irrglaube, in diesem Bereich mit Software irgendwas automatisch bewirken
> zu können.
Das ist schon richtig - ich würde mich jedoch über jeden Programmierer
wundern der sich nicht in seinen SE Vorlesungen gedacht hat was das alles
soll. Jeden den ich kenne der vorher schon länger Programmiert hat kam
bezügl. SE zum selben Schluß:
1) SE ist der Versuch allgemeine Regeln für etwas zu finden wofür es keine
allgemeinen Regeln gibt.
2) Die aktuellen SE-Richtlinien sind wohl im Alltag schon ganz richtig,
versagen jedoch bei den eigenlich schwierigen Problemen.
Dies führe bei fasst allen zu der Einstellung daß es für einen
Programmierer zwar wichtig ist sich diese Konzepte einmal anzuhören und
manche davon womöglich irgendwann einmal zu nutzen - daß sie jedoch kein
Ersatz für Kreativität sind.
Denn hier liegt das Problem - die SE-Kommerz-Branche versucht den Leuten
weiszumachen sie hätten Richtlinien und Regeln die - wenn man sie kennt und
befolgt - jedes Softwareproblem für einen lösen.
Gruß,
Jochen
Reply to: