die Mehrzahl aller Informatik Absolventen kann nicht programmieren

Post by Frank Buss
http://tickletux.wordpress.com/2007/01/24/using-fizzbuzz-to-find-developers-who-grok-coding/
Vielleicht stimmt es ja, daß in den USA im Studium mehr Wert darauf gelegt
wird, Visual Basic zu bedienen, statt Schleifen zu programmieren? Sieht es
in Deutschland genauso schlecht aus?

Ich hätte zumindest problemlos durch das Informatik-Studium hier an der
Uni kommen können ohne programmieren auch nur ansatzweise zu erlernen.

Im Idealfall kann man als Absolvent einer Uni sich in die meisten
Programmiersprachen einarbeiten, aber leider ist das nur der Idealfall.
Viele schaffen es nicht die theorethischen Grundlagen, die vielfach zwar
gelehrt werden dann auf die Praxis zu übertragen. Dieser Bezug, dass
ganze Theorie-Modell, was gelehrt wird, dann auch so beizubringen, dass
die Leute es praktisch anwenden können, wird nicht gemacht.

Ich hab jetzt gerade kein griffiges Beispiel zur Hand, aber dann muss es
halt das tun:
Man lernt an der Uni hier in den ersten Semestern durchaus was über
reguläre Ausdrücke, EBNF-Grammatiken, Kontextfreie Grammatiken etc.
Aber das ist alles schöne Theorie, jedoch darüber, dass und wie man das
praktisch einsetzen kann lernt man wenig.

Und in den Programmierpraktika, die ich hier an der Uni kenne ging es
darum in Teams ein Programm zu programmieren. Dabei kommt es in vielen
Fällen nicht auf das wie an, sondern nur darauf, dass hinten was
rauskommt, was funktioniert. Das fördert nun nicht umbedingt, dass man
sauber programmiert oder gar verstehen muss, was der Partner da
programmiert.

Andererseits kann man natürlich auch in Frage stellen, inwieweit die Uni
sowas leisten muss. Schließlich sollten die Leute auch etwas
Selbstverantwortung haben und man kann denen nicht alles nachtragen.

Gruß
Martin

--
Lustige Erlebnisse mit der Deutschen Bahn:
http://www.bahn-spass.de/

Per Newgro

2007-03-03 22:07:11 UTC

Hallo Martin Köhler,

Post by Martin KÃ¶hler
Andererseits kann man natürlich auch in Frage stellen, inwieweit die Uni
sowas leisten muss. Schließlich sollten die Leute auch etwas
Selbstverantwortung haben und man kann denen nicht alles nachtragen.

Deswegen ist es eine Universität und keine Schule :-). Studieren heißt ja
auch sich bemühen und nicht alles vorgekaut bekommen. Normalerweise
bekommst Du die Grundlagen serviert und solltest dann in der Lage sein,
Dich dann zu entwickeln. Wenn Du programmieren lernen willst, muß Du
Fachinformatiker lernen.

Cheers
Per

Frank Buss

2007-03-04 16:52:00 UTC

Post by Per Newgro
Normalerweise
bekommst Du die Grundlagen serviert und solltest dann in der Lage sein,
Dich dann zu entwickeln. Wenn Du programmieren lernen willst, muß Du
Fachinformatiker lernen.

Es stimmt zwar, daß man je nach Studienschwerpunkt nicht viel mit dem
Programmieren zu tun hat, aber ich würde es als große Einschränkung sehen,
wenn ein Informatiker nicht zumindest minimale Programmierkenntnisse hat,
denn sonst entwirft man z.B. interessante Systemarchitekturen, die aber nur
mathematisch interessant sind, da praktisch nicht umsetzbar.

--
Frank Buss, ***@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Daniel Urban

2007-03-07 19:24:28 UTC

"Frank Buss"

Post by Frank Buss

In solchen Fällen entwickelt der gute Forschen eben vorher seine eigene
Programmiersprache mit dem die Realisierung möglich ist. ;-)

Gruß,

Daniel

Daniel Urban

2007-03-07 19:22:37 UTC

"Martin Köhler"

Post by Martin KÃ¶hler
Ich hab jetzt gerade kein griffiges Beispiel zur Hand, aber dann muss es
Man lernt an der Uni hier in den ersten Semestern durchaus was über
reguläre Ausdrücke, EBNF-Grammatiken, Kontextfreie Grammatiken etc.
Aber das ist alles schöne Theorie, jedoch darüber, dass und wie man das
praktisch einsetzen kann lernt man wenig.

Kann ich nachvollziehen. gilt aber meinens Erachtens nur für das
Grundstudium.
im Hauptstudium hatte ich das ein oder andere Mal ein Aha-Erlebnis.

Post by Martin KÃ¶hler
Und in den Programmierpraktika, die ich hier an der Uni kenne ging es
darum in Teams ein Programm zu programmieren. Dabei kommt es in vielen
Fällen nicht auf das wie an, sondern nur darauf, dass hinten was
rauskommt, was funktioniert. Das fördert nun nicht umbedingt, dass man
sauber programmiert oder gar verstehen muss, was der Partner da
programmiert.

Das liegt aber eher daran, daß es erstens sehr aufwendig wäre und
zweitens keine Definition von "sauberen programmieren" gibt.

Gruß,

Daniel

Ralf Ullrich

2007-03-03 23:28:02 UTC

Post by Frank Buss
Sieht es
in Deutschland genauso schlecht aus?

Ich würde sagen, das hat weniger etwas mit dem Informatik-Studium, ob nun
abgeschlossen oder nicht, zu tun, sondern mehr mit Qualitäten, bei denen
ich nicht mal sicher bin, ob man sie erlernen kann. Sicher kann aber jeder
diese Qualitäten üben, und zwangsläufig wird man ein immer besserer
Programmierer, je mehr Code man geschrieben hat. Ob man aber jemals
wirklich guten Code quasi aus dem Ärmel schütteln kann, scheint mehr vom
angeborenen Talent als vom erworbenen Können abhängig zu sein.

Wenn ich mal meine persönliche Erfahrung aus dem Berufsleben zugrunde
lege, dann kann ich aus einer Stichprobe von etwa 30 Kollegen schöpfen,
deren Programmiererqualitäten ich aus erster Hand und gut genug kenne um
sie genau einzuschätzen. Allesamt Leute, die hauptberuflich Software
geschrieben haben. Etwa 2/3 Drittel davon mit Informatik-Diplom. Aus
diesen 30 bleiben 3, von denen ich sagen würde, sie haben Talent zum
Programmieren, nur einer davon hat ein Diplom. Ob man nun mit einem
Informatik-Studium besser programmieren kann oder nicht, kann man aus
dieser kleinen Stichprobe sicher nicht ableiten, aber man kann doch eines
sehen: Nur 10% aller hauptberuflichen "Codeschreiber" erreichen überhaupt
ein (in meiner Beurteilung) zufriedenstellendes Niveau.

Das scheint aber auch nicht auf Softwareentwicklung alleine beschränkt zu
sein, sondern scheint mindestens im IT Umfeld, vielleicht aber sogar in
allen technischen Berufen ähnlich zu sein. In den (nicht nur
Programmier-)Teams, in denen ich gearbeitet habe, waren die 90%
derjenigen, die keinen guten Code produzieren konnten oder z.B. in der
Systemadministration nicht jede neue Technik sofort bis ins Detail
verstanden haben, aber dennoch wichtige Mitglieder. Wir (=die "Supercoder"
od. "Superadmins") haben diese Kollegen zwar scherzahft "Wasserträger"
genannt, weil sie ständig Überwachung, Kontrolle und Hilfestellung
brauchten um ihr tägliches Arbeits-Pensum abzuliefern und ledliglich
einfachere Aufgaben selbstständig abarbeiten konnten, aber dennoch waren
wir immer voller Respekt diesen "Wasserträgern" gegenüber, denn sie
konnten eines sehr gut, dass uns "Supercodern" äußerst schwer fiel: sie
konnten Routinearbeiten zuverlässig erledigen ohne sich dabei zu
langweilen. (Also z.B. Boilerplate-Code beim Programmieren, oder reines
Operating in der System-Administration.)

Insofern würde ich den Artikel in seiner Beobachtung bestätigen, in dem
ich sage, dass viele Kollegen die sich für einen Job in der
Softwareentwicklung interessieren, nicht gut genug Programmieren können,
um völlig selbstständig zu arbeiten. Ich würde dem Artikel aber auch
insofern widersprechen, dass man solche Kollegen am besten gleich wieder
nach Hause schickt.

In unseren Teams jedenfalls, konnten die 10% Supermänner wesentlich mehr
erreichen, weil sie von Routineaufgaben entlastet waren, und sie waren mit
ihrer Arbeit wesentlich zufriedener, als wenn sie diese Routineaufgaben
hätten erledigen müssen. Ebenso die "Wasserträger". Denen hat es gereicht
ordentliche Durchschnittsarbeit abzuliefern und um Fünf nach Hause gehen
zu können, die brauchten keine so aufwändige Ego-Pflege wie die
Supermänner, die zumindest ab und zu mal glänzen können mussten um
interessiert zu bleiben.

Menschen werden eben nicht in der Fabrik gebacken und passgenau
hergestellt, sondern sie haben ihre individuellen Schwächen und Stärken.
Eine Personalpolitik, die sich nur eine Handvoll harter Skills ausrichtet,
und Anwärter, die Schwächen in diesen harten Skills zeigen, von vornherein
ausschließt, ist meiner Meinung nach zum Scheitern verurteilt. Wichtiger
ist es eine gesunde Mischung in ein Team zu bringen. Und da kann der
"senior programmer" der zwar Schwierigkeiten mit einer an sich simplen
Schleife hat, genau der Richtige sein, weil er seine Stärken woanders hat,
und sich genau dort, noch Lücken in der Teamzusammenstellung befinden.

cu

P.S.: Eins noch im Nachtrag: Alle 30 der erwähnten Programmierer hätten
das FizzBuzz Problem des Artikels ohne weiteres im _normalen_ Berufsalltag
lösen können. Aber wieviele es unter dem Druck eines Bewerbungsgesprächs
hätten schreiben können, kann ich nicht abschätzen, ganz sicher aber nicht
alle! Herrje, ich bin mir nicht mal sicher ob ich es könnte.

Helmut Wollmersdorfer

2007-03-04 21:00:57 UTC

Post by Ralf Ullrich
Menschen werden eben nicht in der Fabrik gebacken und passgenau
hergestellt, sondern sie haben ihre individuellen Schwächen und Stärken.
Eine Personalpolitik, die sich nur eine Handvoll harter Skills
ausrichtet, und Anwärter, die Schwächen in diesen harten Skills zeigen,
von vornherein ausschließt, ist meiner Meinung nach zum Scheitern
verurteilt. Wichtiger ist es eine gesunde Mischung in ein Team zu
bringen.

Dieser Absatz gehört in Stein gemeisselt.

Helmut Wollmersdorfer

Paul Ebermann

2007-03-07 23:18:52 UTC

Post by Ralf Ullrich
In unseren Teams jedenfalls, konnten die 10% Supermänner wesentlich mehr
erreichen, weil sie von Routineaufgaben entlastet waren, und sie waren mit
ihrer Arbeit wesentlich zufriedener, als wenn sie diese Routineaufgaben
hätten erledigen müssen. Ebenso die "Wasserträger". Denen hat es gereicht
ordentliche Durchschnittsarbeit abzuliefern und um Fünf nach Hause gehen
zu können, die brauchten keine so aufwändige Ego-Pflege wie die
Supermänner, die zumindest ab und zu mal glänzen können mussten um
interessiert zu bleiben.

Hmm, es heißt doch so schön: 20% des Teams bringen 80% der Leistung.

Leider bringt es nicht, die anderen 80% des Teams zu
feuern - dann stellt sich das selbe Gleichgewicht nämlich
beim kleineren Team ein, mit dem Ergebnis, dass nur 20%
der Arbeit gemacht wird :-)

(Leicht vereinfacht formuliert ...)

Paul

--
Nun ludigxas: Persone: La Levigxo de la Lun' (Povus Esti Simple)

Wolfgang Rostek

2007-03-08 11:06:53 UTC

Post by Paul Ebermann

Hmm, es heißt doch so schön: 20% des Teams bringen 80% der Leistung.
Leider bringt es nicht, die anderen 80% des Teams zu
feuern - dann stellt sich das selbe Gleichgewicht nämlich
beim kleineren Team ein, mit dem Ergebnis, dass nur 20%
der Arbeit gemacht wird :-)
(Leicht vereinfacht formuliert ...)
Paul
--
Nun ludigxas: Persone: La Levigxo de la Lun' (Povus Esti Simple)

Ich kann beiden nicht zustimmen.

In einer komplexen Anwendungen programmieren oft ein Teil
des Teams an der Grenze oder auch darüber, wo sie die
Komplexität beherrschen. Der Nutzen dieser Beiträge ist
aus meiner Erfahrung eher negativ. Codeverdopplung, kein
Refactoring zur rechten Zeit, etc.

Warum sollte sich die Effizienz der guten Programmierer
auch auf 20% runter skalieren (s.o.). Sie leisten absolut gesehen
einen größeren Beitrag. Im kleinen Team wird der eher noch
größer, da sie die Auswüchse der anderen nicht korrigieren
müssen.

Eine Aussage von Gamma auf der OOP ist mir noch gut in
Erinnerung. Das Eclipse Team hat sehr gute Programmierer,
die kein 'micro management' benötigen. Deshalb ist das
Team (zum damaligen Zeitpunkt) auch relative klein. Ok,
ein solches Projekt darf man wohl nicht als Maßstab für
die breite Masse an Anwendungsentwicklungen nehmen.

Gruß
Wolfgang R.

Sven Köhler

2007-03-03 23:57:59 UTC

Post by Frank Buss
Vielleicht stimmt es ja, daß in den USA im Studium mehr Wert darauf gelegt
wird, Visual Basic zu bedienen, statt Schleifen zu programmieren? Sieht es
in Deutschland genauso schlecht aus? Ich habe zumindest vereinzelt
Programmierer getroffen, bei denen ich vermuten würde, daß sie längere Zeit
für die Lösung brauchen würden, ähnlich wie der im Artikel erwähnte "senior
programmer".

An meiner UNI wird viel Wert auf pratische Ausbildung gelegt. Jeder
Informatik-Student 2 Projekte machen:
- Projekt über 1 Semester
- Proejtk über 2 Semester

Das ganze jeweils in einer Gruppe von ca. 10 Leuten.

Danach sieht es dann meist besser aus, mit dem Programmieren.
Üblicherweise ist mind. einer dabei, der es auch richtig kann (weil er
zu Hause den ganzen tag nix anderes macht ... wie ich ;-) )

Grüße
Sven

Gerhard Landeck

2007-03-06 12:31:34 UTC

Post by Sven KÃ¶hler
An meiner UNI wird viel Wert auf pratische Ausbildung gelegt. Jeder
- Projekt über 1 Semester
- Proejtk über 2 Semester
Das ganze jeweils in einer Gruppe von ca. 10 Leuten.
Danach sieht es dann meist besser aus, mit dem Programmieren.
Üblicherweise ist mind. einer dabei, der es auch richtig kann (weil er
zu Hause den ganzen tag nix anderes macht ... wie ich ;-) )

Und der eine oder die zwei programmieren dann alles und die anderen
acht oder neun schauen zu und lernen nix.

Grüße, Gerhard

Stefan Waldmann

2007-03-06 14:28:13 UTC

Post by Gerhard Landeck

Und der eine oder die zwei programmieren dann alles und die anderen
acht oder neun schauen zu und lernen nix.

weil sie die Lösungen der Programmieraufgaben von dem einen oder den
zweien kopieren, die bereits Programmieren können ;-)

--
Programmierer [m], seltener auch ~in [w]:
Irdische, i.a. humanoide Lebensform, die in einem komplizierten
biochemischen Prozess Kaffee, Cola und Pizza in maschinenlesbaren
Programmcode umwandelt.

Sven Köhler

2007-03-07 03:38:49 UTC

Post by Gerhard Landeck

Und der eine oder die zwei programmieren dann alles und die anderen
acht oder neun schauen zu und lernen nix.

Nein. So war das nicht gemeint.

Die Aufgaben müss als Gruppe gelöst werden. Jeder muss seinen part
übernehmen. Wer nicht mitarbeiten will, will nicht und kriegt ne
schlechte Note oder fliegt raus.

Natürlich gibt es auch solch starke Eigenbrödler, dass sie alles
übernehmen. Aber das soll nicht die Regel sein - und auch die kriegen
eine schlechte Note oder fliegen raus.

Florian Weimer

2007-03-04 09:24:26 UTC

Post by Frank Buss
http://tickletux.wordpress.com/2007/01/24/using-fizzbuzz-to-find-developers-who-grok-coding/
Vielleicht stimmt es ja, daß in den USA im Studium mehr Wert darauf
gelegt wird, Visual Basic zu bedienen, statt Schleifen zu
programmieren? Sieht es in Deutschland genauso schlecht aus?

Wir hatten zufällig kurz vor dem Wochenende die gleiche Diskussion
(sehr motivierend *seufz*). In Deutschland dürfte es an die meisten
Universitäten auch nicht wesentlich anders aussehen: man kann auch
ohne Programmierpraxis (wahrscheinlich auch ohne
Pragrammierkenntnisse) zum Abschluß gelangen.

Auf der anderen Seite gibt es viele fähige Programmierer, die etwas
ganz anderes machen (z.B. physikalische Grundlagenforschung). Bei
Musikern kann man dieses Phänomen wenigstens darauf schieben, daß ein
künstlerisches Einkommen unabhängig von der Begabung ziemlich unstet
ist und es daher sinnvoll ist, sich etwas anderes zu suchen. Beim
Programmieren (Softwareentwickeln, Verzeihung) sollte, gerade für
fähige Leute, die Arbeitsplatzsicherheit mit anderen Berufen
vergleichbar (heute eher: schlecht) sein.

Programmieren ist offenbar eine stigmatisierte, abnorme Veranlagung.

Ich weiß noch nicht so ganz, was für eine Lehre ich daraus ziehen
soll. Natürlich kann man häufig die Entwicklung in Länder geben, wo
der Programmieranteil an der Bevölkerung vielleicht nicht höher ist,
aber dafür die Bevölkerung viel, viel größer -- und die Tätigkeit ist
eher positiv besetzt. Für bestimmte Projekte ist das aber ganz und gar
unmöglich. Ich hege immer noch die Hoffnung, daß wir in einem Jahr
(oder gar früher) eine schlagkräftige Truppe zusammenhaben, aber das
alles gestaltet sich weitaus schwieriger als erwartet.

Jochen Theodorou

2007-03-04 13:00:29 UTC

Florian Weimer schrieb:
[...]

Post by Florian Weimer
In Deutschland dürfte es an die meisten
Universitäten auch nicht wesentlich anders aussehen: man kann auch
ohne Programmierpraxis (wahrscheinlich auch ohne
Pragrammierkenntnisse) zum Abschluß gelangen.

Was bitte ist denn Programmierpraxis? Da setzt sich eine Gruppe von 2-5
Studenten zusammen und löst ein Problem Programmierproblem. Ist das
Praxis? Meiner Meinung nach reicht das nicht. Wenn ich zum Beispiel
sehe, dass viele Vorlesungen sich darauf beschränken die Syntax und
Semantik zu erklären, die Zahl der Übungsprogramme dann aber auf GGT und
sowas reduzieren, dann wundert mich da nur wenig. Man lernt die
unterschiedlichen Konzepte der Programmiersprachen eben nicht indem man
lernt ein Programm zu schreiben, das kompiliert.

Was man auf diese Weise nicht lernt ist wie ein Probelm zu lösen ist.
Man lernt nur wie man eine Lösung umsetzt... wenn überhaupt. Man lernt
aber nicht zu lösen. Daher würde ich zum Beispiel auch erwarten, dass
die Mehrzahl der Studenten das Problem lösen kann, wenn es sich um eine
Prüfungsfrage handelt. Im Semester darauf ist das wieder vergessen. Nach
dem Abschluss eh.

Aber wer diese Aufgabe lösen kann, muss noch lange kein guter
Programmierer sein.

Post by Florian Weimer
Auf der anderen Seite gibt es viele fähige Programmierer, die etwas
ganz anderes machen (z.B. physikalische Grundlagenforschung). Bei
Musikern kann man dieses Phänomen wenigstens darauf schieben, daß ein
künstlerisches Einkommen unabhängig von der Begabung ziemlich unstet
ist und es daher sinnvoll ist, sich etwas anderes zu suchen. Beim
Programmieren (Softwareentwickeln, Verzeihung) sollte, gerade für
fähige Leute, die Arbeitsplatzsicherheit mit anderen Berufen
vergleichbar (heute eher: schlecht) sein.
Programmieren ist offenbar eine stigmatisierte, abnorme Veranlagung.

Ich denke der Respekt der Bevölkerung vor der Informatik ist allgemein
gestiegen, aber der Beruf des Programmierers hat immer noch einen
schlechten Ruf. Da heisst es, das man für wenig Geld viel Arbeiten muss.
Das man zum Ende eiens Projektes hin oft endlose Überstunden schieben
muss und dann diese nichtmal durch Freizeit ausgeglichen bekommt. Warum
wollen denn viele firmen Leute unter 30 mit 10 Jahren Erfahrung? Weil
die noch belastbar sind und gleichzeitig Erfahrung haben. Danach feuert
man sie und holt sich Ersatz. Selbst wärend der New Economy Blase hatte
der Beruf des Programmierers kein gutes Image.

Ich denke nicht das sowas mit einem Job aus der Grundlagenforschung
vergleichbar ist. Ausserdem ist der Arbeitsmarkt zu Physikern
freundlicher, weil es davon nciht so viele gibt.

Post by Florian Weimer
Ich weiß noch nicht so ganz, was für eine Lehre ich daraus ziehen
soll. Natürlich kann man häufig die Entwicklung in Länder geben, wo
der Programmieranteil an der Bevölkerung vielleicht nicht höher ist,
aber dafür die Bevölkerung viel, viel größer -- und die Tätigkeit ist
eher positiv besetzt. Für bestimmte Projekte ist das aber ganz und gar
unmöglich. Ich hege immer noch die Hoffnung, daß wir in einem Jahr
(oder gar früher) eine schlagkräftige Truppe zusammenhaben, aber das
alles gestaltet sich weitaus schwieriger als erwartet.

Da kenn ich so eingie, die diese Erfahrung gemacht haben. Aber die
Firmen sind teilweise selsbt schuld, fordern sie doch für jeden Job
einen akademischen Abschluss... zum Beispiel für Systemadministratoren.
Früher einmal galt die Regel, dass man einen Uniabsolventen ca. 1 Jahr
einlernen muss bevor er sein ganzes Potential entfalten kann. Und viele
wollten deshalb lieber Leute von der FH, weil die durch die praktischere
Ausbildung schneller eingesetzt werden können.

Gruss theo

--
Jochen "blackdrag" Theodorou
Groovy Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/

Florian Weimer

2007-03-04 14:05:55 UTC

Was bitte ist denn Programmierpraxis? Da setzt sich eine Gruppe von
2-5 Studenten zusammen und löst ein Problem Programmierproblem. Ist
das Praxis? Meiner Meinung nach reicht das nicht.

Natürlich nicht. Alles, was man im Studium nur ein-, zweimal macht,
wird vergessen (und die Lösung von entsprechenden Aufgaben mit den
fragwürdigen Methoden optimiert).

Post by Jochen Theodorou
Im Semester darauf ist das wieder vergessen. Nach dem Abschluss eh.

Genau.

Post by Jochen Theodorou
Aber wer diese Aufgabe lösen kann, muss noch lange kein guter
Programmierer sein.

Das ist auch ein Problem. Ich bilde mir ja ein, daß man gewisse Dinge
nachflicken kann, die man kaum vorneweg beurteilen kann (das
automatisierte Testen oder die richtige Nutzung des Build-Systems zum
Beispiel). Aber ob ein Kandidat selbstständig brauchbare
Schnittstellen entwerfen kann, ist nur schwer zu beurteilen. Ich traue
mir höchstens zu herauszubekommen, ob sie weiß, was eine
Software-Schnittstelle ist (unabhängig vom Modell, daß durch eine
Sprache bzw. Entwicklungsmethode vorgegeben wird).

Post by Jochen Theodorou
Ich denke der Respekt der Bevölkerung vor der Informatik ist allgemein
gestiegen, aber der Beruf des Programmierers hat immer noch einen
schlechten Ruf. Da heisst es, das man für wenig Geld viel Arbeiten
muss. Das man zum Ende eiens Projektes hin oft endlose Überstunden
schieben muss und dann diese nichtmal durch Freizeit ausgeglichen
bekommt.

Daran allein kann's nicht liegen, Klinikärzte sind auch nicht besser
dran, haben aber, denke ich, einen besseren Ruf. Möglicherweise rettet
die Perspektive für die Zukunft aber etwas (es gibt mehr
niedergelassene Ärzte als Studienabbrecher à la Bill Gates).

Und jenseits von Boilerplate-Code (für den es aber auch Terence Parrs
Lösung gibt -- fünf Jahre an der Automatisierung arbeiten, statt fünf
Tage Code runterschreiben) halte ich Programmieren durchaus für eine
intellektuell befriedigende Tätigkeit.

Post by Jochen Theodorou
Warum wollen denn viele firmen Leute unter 30 mit 10 Jahren
Erfahrung? Weil die noch belastbar sind und gleichzeitig Erfahrung
haben.

Die Planung der Entwicklung ist tatsächlich ein ausgesprochen
unangenehmes Thema. Wenn man sich verschätzt, gibt's großes Leid zum
Ende hin. Auf der anderen Seite spiegelt das nur wieder, daß
Softwareentwicklung eben doch in weiten Teilen noch nicht
Industrieproduktion ist, was das ganze für alle Beteiligten
interessant (und manchmal auch übertrieben abenteuerlich) macht.

Post by Jochen Theodorou
Danach feuert man sie und holt sich Ersatz. Selbst wärend der New
Economy Blase hatte der Beruf des Programmierers kein gutes Image.

Viele der beteiligten Unternehmen nahmen selbst ja die technischen
Details nicht ernst. Keine Versionskontrolle, keine Tests und keine
Testinfrastruktur, völlige Fehleinschätzung des Aufwands.

Post by Jochen Theodorou
Da kenn ich so eingie, die diese Erfahrung gemacht haben. Aber die
Firmen sind teilweise selsbt schuld, fordern sie doch für jeden Job
einen akademischen Abschluss... zum Beispiel für
Systemadministratoren.

Naja, zum Glück muß ich diese Entscheidungen nicht fällen. Ich würde
eher ChangeLog-Einträge und Diffs sehen wollen (erst recht bei
Programmierern). 8-/

Post by Jochen Theodorou
Früher einmal galt die Regel, dass man einen
Uniabsolventen ca. 1 Jahr einlernen muss bevor er sein ganzes
Potential entfalten kann. Und viele wollten deshalb lieber Leute von
der FH, weil die durch die praktischere Ausbildung schneller
eingesetzt werden können.

Aber sieht es an den FHs wirklich besser aus mit der
Programmiererdichte?

Stefan Ram

2007-03-04 14:21:48 UTC

Post by Florian Weimer
Daran allein kann's nicht liegen, Klinikärzte sind auch nicht
besser dran, haben aber, denke ich, einen besseren Ruf.

»"For the delivery of colonoscopy services in Ontario,
we need to further study the practice of colonoscopy in
offices and private clinics," senior investigator Dr.
Linda Rabeneck told Reuters Health. "There is something
different about the practice of colonoscopy in these
settings that gives rise to higher cancer miss rates,
a worrisome finding." (...)

Specifically, compared with hospital-based colonoscopy,
having the procedure in an office tripled the risk of new
or missed colorectal cancers in men and doubled the risk
in women.«

http://www.sciam.com/print_version.cfm?articleID=B16257C96B9844ACE63D499838C2B71A

Heiko W. Rupp

2007-03-04 16:25:17 UTC

Post by Florian Weimer
Ende hin. Auf der anderen Seite spiegelt das nur wieder, daß
Softwareentwicklung eben doch in weiten Teilen noch nicht
Industrieproduktion ist, was das ganze für alle Beteiligten

Ich kann es nicht mehr hören. IT ist Industrieproduktion. Das
Duplizieren der Ergebnisse am Fließband via CD-Brenner ist nichts
anderes als das finale Zusammenschrauben eines Autos. Bis so ein
Auto aber geschraubt wird, verbringen viele Ingenieure sehr viele
Stunden im Kämmerlein und es werden sehr viele Tests gemacht
(Crash-Test, Fahrtests in strenger Kälte und großer Hitze).
Und trotzdem gibt es immer wieder Rückrufe, weil eben bei der
Konstruktion ein Fehler gemacht wurde. Und das ist in anderen Bereichen
mit nicht-trivialen Endprodukten nicht anders.

--
Heiko W. Rupp <***@pilhuhn.de> http://bsd.de/e3fu/

Florian Weimer

2007-03-04 22:04:12 UTC

Post by Heiko W. Rupp

Ich kann es nicht mehr hören. IT ist Industrieproduktion.

Dafür scheitern aber immer noch ziemlich viele IT-Projekte. 8-/

Spaß beiseiten, ich denke, daß der Weg klar in diese Richtung geht
(und daß sich die Industrieproduktion selbst ebenfalls verändert),
weil man die Abhängigkeit von Gurus loswerden und die erwähnten
Wasserträger durch (Kodier)roboter ersetzen will. Ich bin mir aber
nicht sicher, ob das wirklich so funktioniert. Ich kenne allerdings
auch keine Software-Systeme genauer, die auf diese Weise entwickelt
werden.

Ralf Ullrich

2007-03-04 23:43:59 UTC

Post by Heiko W. Rupp

Ich kann es nicht mehr hören. IT ist Industrieproduktion.

Dafür scheitern aber immer noch ziemlich viele IT-Projekte. 8-/
Spaß beiseiten, ich denke, daß der Weg klar in diese Richtung geht
(und daß sich die Industrieproduktion selbst ebenfalls verändert),
weil man die Abhängigkeit von Gurus loswerden und die erwähnten
Wasserträger durch (Kodier)roboter ersetzen will. Ich bin mir aber
nicht sicher, ob das wirklich so funktioniert. Ich kenne allerdings
auch keine Software-Systeme genauer, die auf diese Weise entwickelt
werden.

Die Wasserträger und Gurus/Supermänner gibt es auch in der Forschung und
Entwicklung in der Industrie und das Verhältnis ist wahrscheinlich
dasselbe wie bei der Softwareentwicklung. Und genausowenig wie es die
"Kodierroboter" je geben wird, gibt es vergleichbare "Ingenieursroboter".

Der Unterschied zwischen der professionellen und ingenieursmäßigen
Arbeitsweise in der fertigenden Industrie und einer professionellen
Softwareentwicklung liegt woanders.

Ich habe mal ein Beispiel persönlich erlebt: Bei einem Automobilhersteller
waren einige Beschwerden eingegangen, dass bei einem Modell die
Scheibenwischer bei hohen Geschwindigkeiten nicht richtig funktionierten
bzw. klapperten. Aus diesem Anlass haben sich dann einen Nachmittag lang
in einem Meeting sieben Leute zusammengesetzt. Da war dann dabei ein
Designer, der aufpassen sollte, dass etwaige Änderungen am Scheibenwischer
auch weiterhin ins Designkonzept der Modellreihe passen. Ein Konstrukteur,
der für das gesamte Scheibenwischeraggregat verantwortlich ist, und
aufpassen sollte, dass etwaige Änderungen am Scheibenwischer keiner
weiteren Änderungen am übrigen Aggregat nötig machen. Dann war doch noch
ein Spezialist vom Zulieferer dabei, der aufpassen sollte, dass die Form
für den Spritzguß nicht durch etwaige Änderungen so kompliziert wird, dass
das Preisbudget durchbrochen wird. Und so ging es weiter, da war also noch
ein Spezialist für Aerodynamik, ein Geräuschdesigner, der verantwortliche
F&E-Manager und nicht zuletzt ein Fertigungsingenieur, der beurteilen
sollte, wie evtl. Änderungen in die laufende Produktion eingebracht werden
können. Das Meeting, das ich mitbekommen habe, war nur das erste Meeting,
in dem die Beschwerden ausgewertet wurden, diesem sind sicher etliche
weitere in derselben Runde gefolgt, bis das Modell einen neuen
verbesserten Scheibenwischer bekam.

In anderen Worten, für ein Teil, das nachher im Laden vielleicht 30 Euro
kosten wird, und nicht mal ein Promille des Produktes ausmachte, wurden
für eine Detailverbesserung, die die allermeisten Kunden gar nie bemerken
werden, am Ende sicherlich mehr als ein Mannmonat an F&E Resourcen
eingesetzt.

Ich kenne kein einziges Softwareprojekt, bei dem Bug-Reports mit einem
ähnlichen Resourceneinsatz begegnet wird.

Man kann also sagen, dass die professionelle Arbeitsweise in der
fertigenden Industrie dadurch gekennzeichnet ist, dass selbst am kleinsten
Teil des Endproduktes viele hochgradig spezialisierte Ingenieure beteiligt
sind.

In der Softwareentwicklung hingegen wird in der Regel vom Entwickler
verlangt ganze Bibliotheken im Alleingang herzustellen und es wird
eigentlich schon als großer Fortschritt gefeiert, dass man sich vorher
wenigstens über die Schnittstellen einigt. Man ist noch weit davon
entfernt, dass am selben Stückchen Code
- ein OO-Design-Spezialist,
- ein Performance-Spezialist,
- ein IT-Sicherheits-Spezialist,
- ein Datenschutz-Spezialist,
- ein Architektur-Spezialist, und
- ein Integrations-Spezialist
zusammenarbeiten. Heute wird doch vom Entwickler verlangt, alle diese
Spezialisierungen in sich zu vereinigen, und sich dazu auch noch am besten
gleich selbst zu managen.

Nun, wenn man zuviel von den Softwareentwicklern verlangt, braucht man
sich nicht wundern, wenn man am Ende von Gurus abhängig ist.

Gurus wird's immer und überall geben. Die Kunst ist, sich von ihnen nicht
abhängig zu machen, und dies wird in der Industrie dadurch erreicht, dass
man mehrere bestenfalls durchschnittliche Ingenieure zu exzellenten
Spezialisten heranwachsen lässt, und sie dann am Produkt zusammenwirken
lässt. Wenn unter diesen Ingenieuren dann ein Guru ist, dann wird er
bestenfalls schneller als andere zum Spezialisten, aber in seinem
Spezialgebiet ist er dennoch leicht zu ersetzen, weil er eben nur seine
vertikale Expertennische besetzt.

Dagegen in der Softwareentwicklung, wo man nach wie vor den Alleskönner
sucht, also denjenigen der über die gesamte horizontale Wissenbreite
glänzt, macht man sich leicht von einem Guru abhängig.

Eine weitere Frage ist allerdings, ob eine solche Vorgehensweise für
Software überhaupt machbar ist. Ein Automodell besteht glaube ich aus etwa
15.000 Einzelteilen und kostet sagen wir mal 20.000 Euro und wird mehrere
hunderttausendmal hergestellt.

Eine Software, wie IntelliJ IDEA oder Eclipse, OpenOffice oder MS Office,
A2LL oder Toll Collect besteht leicht aus zehnmal soviel Klassen (also
quasi Einzelteilen). Das Endprocukt darf aber z.B. im Falle von IntelliJ
IDEA nur wenige hundert Euro kosten und wird bestenfalls genauso oft
verkauft wie das Auto, oder sie muss ihre Kosten gar anders als durch
Verkäufe reinbringen (Eclipse, OpenOffice). Fein raus ist man bestenfalls,
wenn man nur ein Exemplar liefern muss, das dann aber gleich Milliarden
kosten darf (A2LL, Toll Collect) oder wenn man als Quasi-Monopolist
Mondpreise für Alltagsprodukte (MS Office) verlangen kann. Aber wie die
Fehlschläge bei den Großprojekten bzw. die Produktqualität beim
Monopolisten zeigen, wird wohl nicht mal dort die Software
"ingenieursmäßig" entwickelt. Es muss wohl daran liegen, dass es sich
nicht mal dann rechnet, wenn man einen Geldscheißer hat.

cu

Ingo R. Homann

2007-03-05 08:41:09 UTC

Hi,

Post by Ralf Ullrich
Eine weitere Frage ist allerdings, ob eine solche Vorgehensweise für
Software überhaupt machbar ist. Ein Automodell besteht glaube ich aus
etwa 15.000 Einzelteilen und kostet sagen wir mal 20.000 Euro und wird
mehrere hunderttausendmal hergestellt.
Eine Software, ... besteht leicht aus zehnmal soviel Klassen
(also quasi Einzelteilen). Das Endprocukt darf aber ...
nur wenige hundert Euro kosten und wird bestenfalls
genauso oft verkauft wie das Auto...

Schon. Allerdings vergisst Du, dass - nachdem das Auto auf dem
Reissbrett erstmal fertig ist - die eigentliche Produktion des Autos
deutlich teurer ist, als die Vervielfältigung der Software (wenn sie
erstmal fertig ist), sprich das Brennen auf CD. Vom Vertriebsweg ganz zu
schweigen.

Zu Vergleichen ist das Ganze also sowieso nur sehr schwer...

Ciao,
Ingo

Ralf Ullrich

2007-03-05 09:41:11 UTC

Hi,

Post by Ralf Ullrich
Eine weitere Frage ist allerdings, ob eine solche Vorgehensweise für
Software überhaupt machbar ist. Ein Automodell besteht glaube ich aus
etwa 15.000 Einzelteilen und kostet sagen wir mal 20.000 Euro und wird
mehrere hunderttausendmal hergestellt.
Eine Software, ... besteht leicht aus zehnmal soviel Klassen (also quasi
Einzelteilen). Das Endprocukt darf aber ...
nur wenige hundert Euro kosten und wird bestenfalls
genauso oft verkauft wie das Auto...

Schon. Allerdings vergisst Du, dass - nachdem das Auto auf dem Reissbrett
erstmal fertig ist - die eigentliche Produktion des Autos deutlich teurer
ist, als die Vervielfältigung der Software (wenn sie erstmal fertig ist),
sprich das Brennen auf CD. Vom Vertriebsweg ganz zu schweigen.
Zu Vergleichen ist das Ganze also sowieso nur sehr schwer...

Das ist doch genau was ich sagen wollte.

Alle schimpfen immer das Softwareentwicklung im Vergleich zur
industriellen Fertigung so chaotisch abläuft, vergessen dabei aber zu
prüfen, ob eine ingenieursmäßge Vorgehensweise überhaupt wirtschaftlich
realisierbar ist.

Beim Auto machen die eigentlichen Fertigungskosten am Ende den Löwenanteil
an den Stückkosten aus. Die _einzige_ Möglichkeit die Fertigungskosten zu
senken, und das Produkt damit wirtschaftlich attraktiver zu machen, ist es
eben, sich _vorher_ mehr Gedanken darüber zu machen. Auf diese Weise kann
sich eben der hohe Aufwand an F&E letzten Endes direkt positiv auf den
Gewinn auswirken, obwohl man eigentlich mehr Mittel einsetzt. Und das eben
ohne auf kaum steuerbare indirekte Faktoren, wie z.B. durch verbesserte
Qualität erhöhte Kundenakzeptanz und damit erhöhten Absatz zu hoffen.

Bei der Software bestehen die Fertigungskosten praktisch aus den paar Cent
für eine CD Pressung evtl. ein Handbuch. Nicht nur machen diese Kosten nur
ein winzigen Teil der Stückosten einer Software aus, sie sind auch
praktisch nicht mehr sinnvoll weiter zu senken. Und das heißt eben jeder
Euro Mehraufwand in der Entwicklung wirkt sich direkt auf den Endpreis des
Softwareprodukts aus. Im Gegensatz zur industriellen Fertigung kann man
das Endprodukt also durch erhöhten F&E-Einsatz nicht mehr verbilligen,
sondern ausschließlich verteuern.

Dazu kommt noch: Beim physischen Produkten ist eine Nachbesserung mit
äußerst hohen Kosten verbunden. (Man denke nur mal an Sony's Akku-Rückruf
in der letzten Zeit.) Dagegen kostet mich bei der Software eine
Nachbesserung fast nichts. Pro Stück bestenfalls ein paar Cent an
Internetkosten um dem Endkunden einen Patch zum Download anbieten zu können.

Ich kann es mir als Softwarehersteller also erlauben ein unfertiges
Produkt auf den Markt zu bringen, gerade weil ich kaum Kapital riskiere
wenn ich Nachbesserungen riskieren. Ganz im Gegenteil: Ich werde sogar
dafür belohnt ein unfertiges Produkt auf den Markt zu bringen, da ich mein
Produkt noch vor der evtl. sorgfältigeren Konkurrent an die Kunden bringe,
kann ich mir schon Marktanteile sichern, während die Konkurrenz noch
kompiliert.

Genau diese Faktoren wirken sich aber direkt darauf aus, wie einzelnen
Softwareentwickler bzw. Konstrukteure/Ingenieure arbeiten sollen.

Während also die Ingenieure in der Industrie möglichst sorgfältig und
vorausplanend arbeiten sollen, um zum Zeitpunkt des Produktionsbeginns,
spätestens aber mit Zeitpunkt der Auslieferung mit einem möglichst
perfekten Produkt aufwarten zu können, wird von den Softwareentwicklern
erwartet, mit möglichst wenig Aufwand, möglichst viel zu erreichen*).
Wobei es erst mal ausreichend ist, wenn etwas in den meisten Fällen
funktioniert, weil man für die wenigen Ausnahmen, in denen es versagt, ja
immer noch jederzeit nachbessern kann.

Chaos ist da vorprogrammiert. Und gleichzeitig wird auch verständlich,
warum ein Softwareentwickler möglichst breites Wissen haben soll, statt
sich auf einen Aspekt zu spezialisieren: Er kann damit flexibler
eingesetzt werden. (Damit kommen wir dann auch der übertriebenen
Diplom-Verliebtheit in den Stellenanzeigen näher, verspricht doch gerade
die universitäre Ausbildung mit ihrem Nimbus den Studenten alles ein
bisschen und vor allem das lebenslange selbständige Lernen beizubringen,
dass eine vielfältige Einsatzmöglichkeit gesichert ist.)

cu

*) Natürlich gibt es auch in der Industrie Bereiche, wo die Ingenieure
praktisch unter denselben Rahmenbedingunen arbeiten, wie
Softwareentwickler. Dies ist vor allem dort der Fall, wo in kleinen und
mittelgroßen Serien Zwischenprodukte hergestellt werden und die
Lieferanten unter hohem Konkurrenzdruck stehen, weil sie nahezu beliebig
ausgetauscht werden können. Also z.B. gedrehte Metallteile oder im
Spritzdruckguss hergestellte Kunststoffteile. Hier arbeiten dann, auf die
Fertigungsmethoden im eigenen Betrieb hochgradig spezialisierte Ingenieure
daran, die Vorgaben der Kunden in möglichst kurzer Zeit möglichst
kostengünstig auf der eigenen Fertigungsstraße zu realisieren, denn wenn
die Konkurrenz einen Tag früher oder ein paar Cent pro Stück billiger
liefern kann, erhält sie den Auftrag. Einen solchen Job hat mein Onkel
zwei Jahrzehnte lang gehabt, bis die Konkurrenz aus dem Osten so gut
aufgeholt hatte, dass seinem Arbeitgeber nicht mehr genug Aufträge zuteil
wurden.

Heiko W. Rupp

2007-03-05 10:29:17 UTC

Post by Ingo R. Homann
Zu Vergleichen ist das Ganze also sowieso nur sehr schwer...

Eben. Und es wird trotzdem immer wieder zum Nachteil der Informatik
gemacht. Schon alleine deswegen, weil kein Autohersteller
veröffentlicht, was im Lauf der x Jahre Entwicklungszeit alles schief
gelaufen ist.

--
Heiko W. Rupp <***@pilhuhn.de> http://bsd.de/e3fu/

Heiko W. Rupp

2007-03-05 10:27:53 UTC

Modell die Scheibenwischer bei hohen Geschwindigkeiten nicht richtig
funktionierten bzw. klapperten. Aus diesem Anlass haben sich dann einen

Also letztlich ist genau das passiert, was der IT immer vorgeworfen
wird. Das initiale Design war Murks und die QA hat nicht funktioniert.
Ich verstehe auf was Du raus willst und Du hast es auch gut begründet.
Aber letztlich hat man auch in der Autoentwicklung tolle Vorgaben und
Normen etc. und dann gibt es Rückrufe wegen eines Keilriemens oder eines
Dichtungsrings, die jeweils gerade mal 20 Cent wert sind.

--
Heiko W. Rupp <***@pilhuhn.de> http://bsd.de/e3fu/

Jochen Theodorou

2007-03-04 16:42:54 UTC

Florian Weimer schrieb:
[...]

Post by Jochen Theodorou
Aber wer diese Aufgabe lösen kann, muss noch lange kein guter
Programmierer sein.

Oder eine neue Programmiersprache, oder eine neue API... Ich denke zum
Beispiel das ein brauchbarer Javaprogrammierer auch unter C# mit .Net
zurecht kommen wird nachdem er sich eingearbeitet hat.

[...]

einen besseren Ruf bei wem? Bei der Bevölkerung, ja, bei den
Medizinstudenten sicher nicht.

als Studienabbrecher darfst du kein Arzt sein, höchstens Heilpraktiker
und dafür brauchst du nichtmal Abi. Ärzte haben den Ruf viel Geld zu
verdienen, das steigert ihr Ansehen in der Bevölkerung. Und Ärzte werden
meistens auch nicht so einfach gefeuert.

Allerdings ist die Jobsicherheit inzwischen ein extrem wichtiger Faktor
finde ich. sich als Arzt nieder zu lassen lohnt aber auch schon lange
nicht mehr so sehr wie früher. Es gibt in einigen Teilen Deutschlands
einen Mangel an niedergelassenen Ärzten. Da will niemand hin, weil sich
da zu wenig Geld verdienen lässt. Und wenn man weiss was die
Neidergelassenen Ärzte alles bezahlen müssen wundert das auch nicht. Die
Praxiseinrichtung bedeutet Verschuldung über viele Jahre hinweg. Da tut
jede zusätzliche Anschaffung, jeder zusätzlich Aufwand weh. Und dann
muss deine Praxis auch laufen, sprich genug Kunden haben.

Ein Arzt hat allerdings den Vorteil das er ein Projekt in der Regel
alleine abarbeiten kann bzw. das nur durch seine Kenntnisse
beeinträchtigt ist und man andere Ärzte hinzuziehen kann. die Kosten
werden nur für den Kunden erhöht und der wehrt sich nciht, weil es die
Krankenkasse bezahlt. In der It jedoch kannst du nciht jeden Auftrag
annehmen. Wenn du alleine bist sind deine Möglichkeiten Projekte
abzuarbeiten relativ gering. Da wird man schnell mal von einem Kunden
abhängig und dann gibt es eventuell noch Streit darüber ob es richtig
gemacht wurde.

Nö.. also ich würde sagen die Programmierer und Ärzte sind nicht
vergleichbar.

Post by Florian Weimer
Und jenseits von Boilerplate-Code (für den es aber auch Terence Parrs
Lösung gibt -- fünf Jahre an der Automatisierung arbeiten, statt fünf
Tage Code runterschreiben) halte ich Programmieren durchaus für eine
intellektuell befriedigende Tätigkeit.

Was glaubst du warum ich mich so für Groovy interessiere? Ich will
weniger Boilerplate-Code schreiben und mich mehr auf das Problem
konzentrieren können.

Post by Jochen Theodorou
Warum wollen denn viele Firmen Leute unter 30 mit 10 Jahren
Erfahrung? Weil die noch belastbar sind und gleichzeitig Erfahrung
haben.

klar, tortzdem finde ich das Firmen oft eine total übersteigerte
Erwartung an die Leute haben. Warum stellt man einen Akademiker ein,
wenn der dann Boilerplate-Code schreiben soll? Sowas ist meiner Meinung
nach Verschwendung von Potential. Und gleichzeitig heisst es, es gäbe zu
wenig qualitfizierte Leute... kein Wunder sage ich da immer wieder.

Post by Jochen Theodorou
Danach feuert man sie und holt sich Ersatz. Selbst wärend der New
Economy Blase hatte der Beruf des Programmierers kein gutes Image.

Viele der beteiligten Unternehmen nahmen selbst ja die technischen
Details nicht ernst. Keine Versionskontrolle, keine Tests und keine
Testinfrastruktur, völlige Fehleinschätzung des Aufwands.

Das mit den Tests wird auch heute noch teilweise nicht sehr ernst
genommen. Das sind dann so "wilde Ideen aus dem Bereich des XP". Was die
völlige Fehleinschätzung der Lage beweisst.

[...]

Aber sieht es an den FHs wirklich besser aus mit der
Programmiererdichte?

Ich weiss das die Ausbildung an der FH praktischer orientiert ist und
mehr am Bedarf der Industrie. Im Klartext heisst das Java und sie ahben
irgendwelcher minderschweren Aufgaben in Java erledigt. Der Uniabsolvent
könnte dabei theoretisch ein grösseres Wissen aus dem Bereich der
Datenstrukturen und Algorithmen mitbringen, ebenso mehr Wissen über
andere Programmiersprachen und vielleicht sogar ein besser Gespür für
die Lösungsfindung. Alles in allem spricht mehr für den Absolvent der
Uni finde ich. Allerdings kommt es auf die Firma an wen sie wirklich
braucht. Und auf den Absolventen, ob er sich so durch das Studium
gewurschtelt hat oder sich wirklich mit den Dingen beschäftigt hat.
Allerdings sind da weder ein gutes Diplom, noch ein erfolgreiches
Studium ein wirklicher Beweis für. Und es ist schon gar kein Beweis
dafür dass das Wissen noch vorhanden und auch praktisch umsetzbar ist.

Ich denke einige praktische Aufgaben würden da sicher aufschlussreicher
sein. Dann kann man den Stil beobachten zum Beispiel

Gruss theo

--
Jochen "blackdrag" Theodorou
Groovy Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/

Marcus Woletz

2007-03-04 17:33:14 UTC

Hallo Jochen,

Jochen Theodorou schrieb:
[...]

Post by Jochen Theodorou
klar, tortzdem finde ich das Firmen oft eine total übersteigerte
Erwartung an die Leute haben. Warum stellt man einen Akademiker ein,
wenn der dann Boilerplate-Code schreiben soll? Sowas ist meiner Meinung

diese bei den Leuten hier scheinbar normalerweise völlige Trennung
zwischen Entwicklung und Implementierung ist mir in meiner Laufbahn
bisher noch nicht begegnet. OK, ich agiere eher im mittelständischen
Umfeld. Ich sehe auch nicht so richtig den Grund, warum Akademiker nicht
kodieren können sollten/müssten. Innerhalb der Gruppe der Akademiker
gibt es massive Unterschiede in den Fähigkeiten, Software zu entwickeln.
Im Studium werden theoretische Aspekte der Informatik gelehrt. Das
ist sehr wichtig, aber reines _Handwerkszeug_. Der Prozess der
Entwicklung von Software ist ein in einigen Bereichen intellektuell und
kreativ anspruchsvoller Prozess, der deshalb im Team besser aufgehoben
ist. Das Studium befähigt allenfalls, beim Entwurf der Datenstrukturen
und Algorithmen die Todsünden zu vermeiden und lässt hoffen, dass die
Ergebnisse dann brauchbar effizient arbeiten.
Meiner Meinung nach ist die Sache so: ohne vernünftigen theoretischen
Hintergrund ist nicht zu erwarten, dass Leute brauchbare Softwaresysteme
entwerfen und implementieren. Das ist die notwendige Bedingung.
Zusätzlich ist noch eine gehörige Portion Motivation und Begabung
notwendig, dass eine Person gute Software entwickeln kann. Diese
Skills trennen dann die wirklich guten Leuten von den mittelmäßigen
"Handwerkern". Das sind jedenfalls meine Erfahrungen, die ich im Laufe
der Zeit gesammelt habe.

[...]

Post by Jochen Theodorou
Das mit den Tests wird auch heute noch teilweise nicht sehr ernst
genommen. Das sind dann so "wilde Ideen aus dem Bereich des XP". Was die
völlige Fehleinschätzung der Lage beweisst.

XP beinhaltet IMO einige ausgesprochen vielversprechende Ansätze.
Viele davon sind jedoch für Entscheidungsträger eher schwer verdaulich,
und wenn nicht diese, dann macht häufig die Finanzabteilung einen
Strich durch die Rechnung. XP zahlt sich eher längerfristig aus,
und sowas ist den entsprechenden Stellen grundsätzlich schlecht zu
vermitteln (jedenfalls heutzutage).

[...]

Post by Jochen Theodorou
Gruss theo

ciao

Marcus

Jochen Theodorou

2007-03-04 18:12:14 UTC

Post by Marcus Woletz
Hallo Jochen,
[...]

warum eine solche Trennung, eben weil ich es als Verschwendung empfinde.
Ok, ich hätte es weniger am akademischen Grad festmachen sollen, als
vielmerh an den tatsächlichen Fähigkeiten. Es kommt auch darauf an wie
viele Leute in dem Projekt beschäftigt sind usw. Aber lasse ich einen,
der sich gut mit Spring auskennt GUIs machen, während der, der sich auf
GUIs versteht Spring macht? Sin macht das, wenn die beiden
zusammenarbeiten und sich gegenseitig etwas beibringen. Das ist dann
Training, eine Investition. Aber wenn es darum geht ein Projekt fertig
zu bekommen, dann scheint mir eine solche Einteilung irgendwie seltsam.

Und genauso ist es wenn ich einen für OOD habe, der dann
Boilerplate-Code schreibt. Wenn das Team natürlich so zusammengesetzt
ist, das keiner spezialisiert ist, ist es natürlich wieder egal, die
Firma arbeitet dann eventuell allgemein ineffizienter.

Post by Marcus Woletz
Im Studium werden theoretische Aspekte der Informatik gelehrt. Das
ist sehr wichtig, aber reines _Handwerkszeug_. Der Prozess der
Entwicklung von Software ist ein in einigen Bereichen intellektuell und
kreativ anspruchsvoller Prozess, der deshalb im Team besser aufgehoben
ist.

Da stimme ich dir zu 100% zu. Kommt aber auch auf den BEreich an, in dem
du arbeitest.

Post by Marcus Woletz
Das Studium befähigt allenfalls, beim Entwurf der Datenstrukturen
und Algorithmen die Todsünden zu vermeiden und lässt hoffen, dass die
Ergebnisse dann brauchbar effizient arbeiten.

naja, für die Todsünden braucht man keinen akademischen Grad meine ich.

Post by Marcus Woletz
Meiner Meinung nach ist die Sache so: ohne vernünftigen theoretischen
Hintergrund ist nicht zu erwarten, dass Leute brauchbare Softwaresysteme
entwerfen und implementieren. Das ist die notwendige Bedingung.

Was ist brauchbar? Brauchbar ist es wenn es die Anforderungen des Kunden
erfüllt, oder? Ob die Software dabei weniger gut ist, als sie eigentlich
sein könnte spielt erstmal nur eine Nebenrolle.

Post by Marcus Woletz
Zusätzlich ist noch eine gehörige Portion Motivation und Begabung
notwendig, dass eine Person gute Software entwickeln kann. Diese
Skills trennen dann die wirklich guten Leuten von den mittelmäßigen
"Handwerkern". Das sind jedenfalls meine Erfahrungen, die ich im Laufe
der Zeit gesammelt habe.

Ja gut, da stimme ich dir wieder zu.

[...]

XP beinhaltet IMO einige ausgesprochen vielversprechende Ansätze.

klar, ich bin kein XPler, aber ich halte durchaus grosse Stücke darauf.

Post by Marcus Woletz
Viele davon sind jedoch für Entscheidungsträger eher schwer verdaulich,
und wenn nicht diese, dann macht häufig die Finanzabteilung einen
Strich durch die Rechnung. XP zahlt sich eher längerfristig aus,
und sowas ist den entsprechenden Stellen grundsätzlich schlecht zu
vermitteln (jedenfalls heutzutage).

stimmt leider.

Gruss theo

--
Jochen "blackdrag" Theodorou
Groovy Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/

Florian Weimer

2007-03-04 22:15:53 UTC

Post by Florian Weimer
Das ist auch ein Problem. Ich bilde mir ja ein, daß man gewisse
Dinge nachflicken kann, die man kaum vorneweg beurteilen kann (das
automatisierte Testen oder die richtige Nutzung des Build-Systems
zum Beispiel).

Oder eine neue Programmiersprache, oder eine neue API... Ich denke zum
Beispiel das ein brauchbarer Javaprogrammierer auch unter C# mit .Net
zurecht kommen wird nachdem er sich eingearbeitet hat.

Ja, wobei "API" schon aufwendig sein kann, aber angesichts der
Vielfältigkeit ist es vermessen, da Vorwissen zu erwarten.

Post by Florian Weimer
Daran allein kann's nicht liegen, Klinikärzte sind auch nicht besser
dran, haben aber, denke ich, einen besseren Ruf. Möglicherweise rettet
die Perspektive für die Zukunft aber etwas (es gibt mehr
niedergelassene Ärzte als Studienabbrecher à la Bill Gates).

einen besseren Ruf bei wem? Bei der Bevölkerung, ja, bei den
Medizinstudenten sicher nicht.

Hmm, guter Punkt. Ich gebe zu, das mit den Ärzten war etwas an den
Haaren herbeigezogen. In der Freizeitgesellschaft dürften alle Berufe,
die nicht strikt 9-to-5 sind, reichlich unpopulär sein.

Weil er im Idealfall ein Tool bauen kann, daß das ein für alle Mal
erschlägt (oder doch einen großen Teil). Und er kann heute
Boilerplates in Perl und morgen in Haskell schreiben.

Post by Jochen Theodorou
Sowas ist meiner Meinung nach Verschwendung von Potential.

Boilerplate-Code ist das immer, so wie der Sekretär, der die
regelmäßige Formatierung seiner Excel-Tabellen von Hand erzeugt. Egal
wie glücklich es ihn macht.

Ich habe im letzten Jahr einiges zu diesem Thema auf die harte Tour
gelernt. 8->

Post by Jochen Theodorou
Ich denke einige praktische Aufgaben würden da sicher
aufschlussreicher sein. Dann kann man den Stil beobachten zum Beispiel

Ja, wenn sie ihren Code nicht einmal ansatzweise richtig
einrücken. *grusel*

Jochen Theodorou

2007-03-05 15:17:22 UTC

Florian Weimer schrieb:
[...]

Weil er im Idealfall ein Tool bauen kann, daß das ein für alle Mal
erschlägt (oder doch einen großen Teil).

Der idealfall hängt aber meist nicht so sehr vom Programmierer ab, als
von den wechselnden Anforderungen der Kunden.

Post by Florian Weimer
Und er kann heute
Boilerplates in Perl und morgen in Haskell schreiben.

wenn er es nicht dem Chef zeigt wahrscheinlich ;)

Gruss theo

--
Jochen "blackdrag" Theodorou
Groovy Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/

Wanja Gayk

2007-03-06 18:40:12 UTC

Ich habe im letzten Jahr einiges zu diesem Thema auf die harte Tour
gelernt. 8->

-v

Ich steh' auf Anekdoten aus dem Leben - hatte heute einen beschissenen
Tag, da brauch ich das jetzt.
:-)

Gruß,
-Wanja-

--
Ada Byron, die Lochkarten für Babbages "Difference Engine" vorbereitete,
gilt als die erste Programmiererin der Weltgeschichte. Sie hat auch das
Verhaltensmuster für alle nachfolgenden Programmierer vorgegeben: Sie
trank und schluckte Drogen.

Ivan Dolvich

2007-03-05 10:17:30 UTC

Post by Florian Weimer
Aber sieht es an den FHs wirklich besser aus mit der
Programmiererdichte?

Ich weiss das die Ausbildung an der FH praktischer orientiert ist und
mehr am Bedarf der Industrie. Im Klartext heisst das Java und sie ahben
irgendwelcher minderschweren Aufgaben in Java erledigt.

Aus eigener Erfahrung kann ich berichten, dass die Programmierung und
Softwareentwicklung an unserer FH einer der Schwerpunkte war. Hier ist
ein Teil davon

1. Semester:
* Programmieren Grundlagen (Java ohne OO), dazu einfacheren
Übungsaufgaben
* Theorie - Automaten, Grammatiken, Sprachen
2. Semester:
* Java OO: Vorlesung mit Labor. Im Labor 5-6 Aufgaben a-la "Game of Life"
* C++ OO: Vorlesung, Übungsaufgaben
* Theorie - Berechenbarkeit, Komplexität
3. Semester: Praktikum in einer Firma
4. Semester:
* Softwaretechnik - UML, RUP
* Labor, Programmierung eines Parsers in C
* Datenbanken-Labor (JDBC)
5. Semester:
* Labor mit hardwarenaher C-Programmierung
* Studienarbeit: C++ Programmierung
6. Semester: Praktikum in einer Firma
7. Semester:
* Labor, Programmierung eines Web-Shops mit Struts und Hibernate
* Labor, Programmierung einer Java Anwendung, JDBC
8. Semester: Diplomarbeit in einer Firma

Post by Jochen Theodorou
Der Uniabsolvent
könnte dabei theoretisch ein grösseres Wissen aus dem Bereich der
Datenstrukturen und Algorithmen mitbringen

Ja, hier sind die Uni-Leute wirklich besser. Das ganze Programmierzeug
an der FH ist leider vergänglich - aktuelle Technologien, die nach
einigen Jahren in Vergessenheit geraten werden. Aber es hat einen
schönen "Learn by Doing" effekt.

Grüße, Ivan

Jochen Theodorou

2007-03-05 15:25:43 UTC

Post by Florian Weimer
Aber sieht es an den FHs wirklich besser aus mit der
Programmiererdichte?

Ich weiss das die Ausbildung an der FH praktischer orientiert ist und
mehr am Bedarf der Industrie. Im Klartext heisst das Java und sie
ahben irgendwelcher minderschweren Aufgaben in Java erledigt.

Aus eigener Erfahrung kann ich berichten, dass die Programmierung und
Softwareentwicklung an unserer FH einer der Schwerpunkte war. Hier ist
ein Teil davon
* Programmieren Grundlagen (Java ohne OO), dazu einfacheren
Übungsaufgaben
* Theorie - Automaten, Grammatiken, Sprachen
* Java OO: Vorlesung mit Labor. Im Labor 5-6 Aufgaben a-la "Game of Life"
* C++ OO: Vorlesung, Übungsaufgaben
* Theorie - Berechenbarkeit, Komplexität
3. Semester: Praktikum in einer Firma
* Softwaretechnik - UML, RUP
* Labor, Programmierung eines Parsers in C
* Datenbanken-Labor (JDBC)
* Labor mit hardwarenaher C-Programmierung
* Studienarbeit: C++ Programmierung
6. Semester: Praktikum in einer Firma
* Labor, Programmierung eines Web-Shops mit Struts und Hibernate
* Labor, Programmierung einer Java Anwendung, JDBC
8. Semester: Diplomarbeit in einer Firma

was da zum Beispiel fehlt ist Lisp. C, Java und C++ haben doch zum Teil
recht ähnliche Konzepte, der Funktionale Teil fehlt da irgendwie ganz.
Sowas wie Designpatterns habt ihr scheinbar auch nciht gemacht, naja,
das hat man an der Uni meist auch nicht. Ich würde mich zum Beispiel
garnicht so sehr wundern wenn ein Absolvent dieser FH zwar eine Webapp
zustande bringt, aber nicht die Eingangs erwähnte Aufgabe in unter 10min
löst.

Post by Jochen Theodorou
Der Uniabsolvent könnte dabei theoretisch ein grösseres Wissen aus dem
Bereich der Datenstrukturen und Algorithmen mitbringen

aktuelle Technologien sind an der Uni auch nicht so heiss. Wenn du dich
mit solchen Dingen beschäftigen willst bleiben dir meist nur die
Hauptseminare und Diplomarbeit. Soll heissen dass es sehr wahrscheinlich
extrem spezialisiertes Wissen aus einem kleinem Bereich sein wird.

Gruss theo

--
Jochen "blackdrag" Theodorou
Groovy Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/

Martin Mayer

2007-03-05 15:31:31 UTC

Post by Ivan Dolvich
Ja, hier sind die Uni-Leute wirklich besser. Das ganze Programmierzeug
an der FH ist leider vergänglich - aktuelle Technologien, die nach
einigen Jahren in Vergessenheit geraten werden. Aber es hat einen
schönen "Learn by Doing" effekt.

Aktuelle Technologien finde ich auch als Lehrstoff relativ sinnlos. In 2
Jahren ist dieses Wissen zumindest zum großen Teil veraltet und bei der
Menge an Technologien besonders im IT-Bereich handelt es sich immer um
Nischenwissen.
Die theoretischen Grundlagen dagegen ändern sich nicht oder bei weitem
nicht so schnell, auch das strukturierte Vorgehen welches man z.B. im
Bereich Software-Engineering (sofern man diesen wählt) mitbekommt wird
einem immer nützlich sein, selbst wenn die spätere Firma ein anderes
Vorgehensmodell verwenden sollte.

Sich mit aktuellen Programmiersprachen, Frameworks etc. zu beschäftigen
sollte wirklich die Aufgabe eines jeden Studenten sein, unabhängig davon ob
es in der Uni verlangt wird. Ich habe dazu z.B. nebenbei bei einer kleinen
Softwarefirma gearbeitet, was mir im Nachhinein betrachtet extrem viel
gebracht hat.

Martin

Ivan Dolvich

2007-03-05 17:09:37 UTC

Post by Jochen Theodorou
was da zum Beispiel fehlt ist Lisp. C, Java und C++ haben doch zum Teil
recht ähnliche Konzepte, der Funktionale Teil fehlt da irgendwie ganz.

Ja das stimmt, der Stoff orientiert sich an dem Mainstream in der
Industrie. Wäre vielleicht nicht schlecht um den Blickwinkel zu
erweitern. An der Uni hier hat man früher Haskell gelehrt. Viele
Studenten haben sich aber beklagt, dass es viel zu kompliziert ist und
nix für die Praxis taugt. Jetzt lehrt man "Java in 2 Wochen".

Post by Jochen Theodorou
Sowas wie Designpatterns habt ihr scheinbar auch nciht gemacht, naja,
das hat man an der Uni meist auch nicht.

Es gab eine Vorlesung nur über Design Patterns, es wurden ca. 15
Patterns behandelt, war aber ein Wahlfach.

Post by Jochen Theodorou
garnicht so sehr wundern wenn ein Absolvent dieser FH zwar eine Webapp
zustande bringt, aber nicht die Eingangs erwähnte Aufgabe in unter 10min
löst.

Hier irrst du dich, die meisten könnten das nach dem ersten Semester
schaffen. Ich hatte mal ein Kollege im 4. Semester aus der Uni - er
konnte Java so wie wir im 2. Semester und Eclipse garnicht. Dafür hat er
sehr gut alles verstanden was ich ihm bei der Einarbeitung in das
Projekt erzählt habe, auch die komplexeren Dinge. Ich vermute er ist
jetzt viel besser im Programmieren geworden.

Grüße, Ivan

Jochen Theodorou

2007-03-05 17:41:08 UTC

Post by Jochen Theodorou
was da zum Beispiel fehlt ist Lisp. C, Java und C++ haben doch zum
Teil recht ähnliche Konzepte, der Funktionale Teil fehlt da irgendwie
ganz.

also bei Haskell kann ich es verstehen, ich finde irgendwie keinen
Zugang zu der Sprache ;) Aber ein bischen Scheme wäre sicher hilfreich
gewesen.

[...]

Post by Jochen Theodorou
garnicht so sehr wundern wenn ein Absolvent dieser FH zwar eine Webapp
zustande bringt, aber nicht die Eingangs erwähnte Aufgabe in unter
10min löst.

Hier irrst du dich, die meisten könnten das nach dem ersten Semester
schaffen.

Ich meinte ich würde mich nicht wundern. Und anch dem ersten Semester
zählt nicht, nach dem letzten ist wichtig. Man vergisst in der
zwischenzeit sehr viel.

Post by Ivan Dolvich
Ich hatte mal ein Kollege im 4. Semester aus der Uni - er
konnte Java so wie wir im 2. Semester und Eclipse garnicht. Dafür hat er
sehr gut alles verstanden was ich ihm bei der Einarbeitung in das
Projekt erzählt habe, auch die komplexeren Dinge. Ich vermute er ist
jetzt viel besser im Programmieren geworden.

Ach, das käme auf einen Vergleich an ;)

Gruss theo

--
Jochen "blackdrag" Theodorou
Groovy Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/

Olaf Pohlmann

2007-03-05 10:25:50 UTC

Post by Florian Weimer
Aber ob ein Kandidat selbstständig brauchbare
Schnittstellen entwerfen kann, ist nur schwer zu beurteilen. Ich traue
mir höchstens zu herauszubekommen, ob sie weiß, was eine
Software-Schnittstelle ist (unabhängig vom Modell, daß durch eine
Sprache bzw. Entwicklungsmethode vorgegeben wird).

Das ist nach meinen Erfahrungen aber schon ein guter Filter. Ein guter
Test ist auch, eine Methodensignatur einmal mit einem
Interface-Parameter wie Set und einmal mit einer einfachen
Implementation wie HashSet anzubieten und zu fragen, welches die besser
Wahl ist, und *warum*.

Der Unterschied zwischen Runtime- und Checked-Exceptions gehoert zum
Grundwissen eines Java-Programmierers, aber viele koennen diese Frage
gar nicht oder nur vage beantworten.

Dann kann man jemandem Code zu lesen geben, der kompiliert und nach
Designfehlern und -schwaechen fragen. Viele Bewerber wissen z.B. nicht,
dass Object#equals und Object#hashCode immer "gemeinsam" ueberschrieben
werden muessen.

Bei einem schriftlichen Test muss man vor allem offene Fragen stellen,
kein Multiple-Choice-Kram. Was man da zu lesen bekommt ist teilweise
abenteuerlich.

op

Jochen Theodorou

2007-03-05 15:35:28 UTC

Olaf Pohlmann schrieb:
[...]

Post by Olaf Pohlmann
Der Unterschied zwischen Runtime- und Checked-Exceptions gehoert zum
Grundwissen eines Java-Programmierers, aber viele koennen diese Frage
gar nicht oder nur vage beantworten.

damit testest du auch Javawissen, also solltest du möglichst nach einem
Javaprogrammierer suchen, wenn du das fragst. Das sagt allerdings 0 über
die Fähigkeiten des Programmierers aus.

[...]

Post by Olaf Pohlmann
Bei einem schriftlichen Test muss man vor allem offene Fragen stellen,
kein Multiple-Choice-Kram. Was man da zu lesen bekommt ist teilweise
abenteuerlich.

ja, und dann werden wieder Begriffe abgefragt. Kann sein das der Begriff
nciht geläufig ist, das Konzept aber (vielleicht unter einem anderem
Namen) schon.

Sorry, aber bei genau sowas sehe ich nicht die Fähigkeiten eines
Programmierers eingeschätzt. Es wird nur geschaut ob die Sprache
beherrscht wird. Auch wenn man die Sprache beherrscht kann es trotzdem
ein schlechter Programmierer sein. Ist ein ganz interessantes Phänomen
in OSS-Projekten zum Beispiel. die Lösung ist dann zum Beispiel an sich
korrekt. Sie erfolgt aber ohne Verständnis des Gesamtsystems und in
einem schlechten Stil. Naja gut, kommt auch auf das Projekt an.

Gruss theo

--
Jochen "blackdrag" Theodorou
Groovy Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/

Olaf Pohlmann

2007-03-05 17:07:17 UTC

Post by Olaf Pohlmann
Der Unterschied zwischen Runtime- und Checked-Exceptions gehoert zum
Grundwissen eines Java-Programmierers, aber viele koennen diese Frage
gar nicht oder nur vage beantworten.

damit testest du auch Javawissen, also solltest du möglichst nach einem
Javaprogrammierer suchen, wenn du das fragst. Das sagt allerdings 0 über
die Fähigkeiten des Programmierers aus.

Wenn die Stelle nach guten Java-Kenntnissen verlangt und das auch
explizit so ausgeschrieben ist, halte ich das fuer notwendig. Java ist
eine eher ausdrucksschwache Sprache und nur durch gute Kenntnisse von
APIs effizient einzusetzen. Die Standard-API lernt man aber nicht mal so
nebenbei in einer Woche.

Wenn mir jemand Interfaces in Java gut erklaeren kann, sagt das durchaus
etwas ueber OOP-Kenntnisse.

Post by Olaf Pohlmann
Bei einem schriftlichen Test muss man vor allem offene Fragen stellen,
kein Multiple-Choice-Kram. Was man da zu lesen bekommt ist teilweise
abenteuerlich.

ja, und dann werden wieder Begriffe abgefragt. Kann sein das der Begriff
nciht geläufig ist, das Konzept aber (vielleicht unter einem anderem
Namen) schon.

Nein, bei offenen Fragen kann jeder einfach drauflos schreiben, was fuer
ihn in dem Kontext wichtig erscheint. Das Problem ist eher, dass niemand
weiss, wann die Antwort ausreicht. Deswegen gibt's dazu auch soviel Zeit
wie noetig.

Post by Jochen Theodorou
Sorry, aber bei genau sowas sehe ich nicht die Fähigkeiten eines
Programmierers eingeschätzt. Es wird nur geschaut ob die Sprache
beherrscht wird. Auch wenn man die Sprache beherrscht kann es trotzdem
ein schlechter Programmierer sein.

Naja, das glaube ich nicht. Es gibt nach meinen Erfahrungen eine klare
Korrelation zwischen der Kenntnis der "Hauptsprache" und den
Design-Faehigkeiten. Klar kann man immer noch falsch liegen, aber
jemand, der nur theoretische Konzepte kennt und keine ausreichenden
Sprachkenntnisse hat, ist auch nicht unbedingt ein Volltreffer. Zu
wissen, wie es im Prinzip geht und das dann in die Praxis umzusetzen,
sind zwei Paar Schuhe.

op

Jochen Theodorou

2007-03-05 17:57:56 UTC

Olaf Pohlmann schrieb:
[...]

Post by Olaf Pohlmann
Wenn die Stelle nach guten Java-Kenntnissen verlangt und das auch
explizit so ausgeschrieben ist, halte ich das fuer notwendig.

Dann aber bitte kein Diplom fordern. Denn offensichtlich wird dann
jemand gesucht der Java beherscht und ob er ein guter Programmierer ist
überlasst ihr dem Zufall.

Post by Olaf Pohlmann
Java ist
eine eher ausdrucksschwache Sprache und nur durch gute Kenntnisse von
APIs effizient einzusetzen. Die Standard-API lernt man aber nicht mal so
nebenbei in einer Woche.

sicherlich nicht, aber wie gesagt, dann wird eigentlich auch kein
Informatiker gesucht.

Post by Olaf Pohlmann
Wenn mir jemand Interfaces in Java gut erklaeren kann, sagt das durchaus
etwas ueber OOP-Kenntnisse.

das kommt ganz darauf an wie viel du da hören willst und wann du
interfaces als erklärt betrachtest.

[...}

Post by Olaf Pohlmann

Naja, das glaube ich nicht. Es gibt nach meinen Erfahrungen eine klare
Korrelation zwischen der Kenntnis der "Hauptsprache" und den
Design-Faehigkeiten.

Meiner Meinung nach bezieht sich das nicht auf ein saubere Design.

Post by Olaf Pohlmann
Klar kann man immer noch falsch liegen, aber
jemand, der nur theoretische Konzepte kennt und keine ausreichenden
Sprachkenntnisse hat, ist auch nicht unbedingt ein Volltreffer.

Wenn jemand 3-4 Programmiersprachen (aus verschiedenen Bereichen)
gelernt hat, dann kann er in einer Woche eine neue Sprache soweit
lernen, dass er Programme schreiben kann, die auch kompilieren. Die API
zu lernen dauert dann nochmal wesentlich länger, aber die
Designfähigkeiten betrift das in der Regel dann weniger.

Post by Olaf Pohlmann
Zu
wissen, wie es im Prinzip geht und das dann in die Praxis umzusetzen,
sind zwei Paar Schuhe.

klar, da stimme ich dir zu.

Gruss theo

--
Jochen "blackdrag" Theodorou
Groovy Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/

Wanja Gayk

2007-03-04 11:25:49 UTC

Post by Frank Buss
http://tickletux.wordpress.com/2007/01/24/using-fizzbuzz-to-find-developers-who-grok-coding/

Also nach meiner Zeit als Tutor für das Softwarepraktikum an meiner
ehem. Uni, wundert mich das garnicht: Der Betrugsversuch ist die Regel,
nicht die Ausnahme. Es ist nur relativ schwer es nachzuweisen.
Ich habe auch schon massenhaft Code von Diplomanden gesehen, der selbst
mir die Schamesröte ins Gesicht treiben sollte und ich halte mich
weißgott nicht für den Paganini unter den Programmierern.

Aber vielleicht sollten die guten Herren Personalchefs auch mal in ihren
Schwachkopf reinkriegen, dass Universitäten Akademiker ausbilden, keine
Programmierer. Das Programmieren ist im Studium (zumindest war es an
meiner Uni so) halt hin und wieder ein notwendiges Übel, aber auch nicht
mehr.

Gruß,
-Wanja-

Florian Weimer

2007-03-04 14:23:57 UTC

Post by Wanja Gayk
Aber vielleicht sollten die guten Herren Personalchefs auch mal in
ihren Schwachkopf reinkriegen, dass Universitäten Akademiker
ausbilden, keine Programmierer.

Dafür rennen die Universitäten den Moden der Industrie aber ganz schön
eifrig hinterher (man denke nur an die Diskussionen um Java als
Lehrsprache).

Und ehrlich gesagt: Ich glaube nicht, daß jeder, der Forschung in der
Informatik macht, auf einen Kreis von Mitarbeitern zugreifen kann, die
seine Ideen umsetzen, ohne daß er sich selbst die Finger schmutzig
machen muß. Ich glaube daher, daß die Universitäten sich selbst mit
einer "unsere Absolventen können nicht Programmieren und wir sind
Stolz darauf"-Haltung ins Knie schießen.

Auf der anderen Seite gibt's ja durchaus massiv-parallele Systeme, die
Personal produzieren, das (vielleicht nicht dem deutschen Diplom
vergleichbare) akademische Qualifikationen vorweisen kann *und* das
willens und fähig ist, Code zu produzieren. Bei den Herren
Personalchefs hat sich das tatsächlich herumgesprochen, und es wird
entsprechend gehandelt. Die Kostenfrage ist inzwischen nur ein
Teilaspekt.

Jochen Theodorou

2007-03-04 17:09:02 UTC

Post by Wanja Gayk
Aber vielleicht sollten die guten Herren Personalchefs auch mal in
ihren Schwachkopf reinkriegen, dass Universitäten Akademiker
ausbilden, keine Programmierer.

Dafür rennen die Universitäten den Moden der Industrie aber ganz schön
eifrig hinterher (man denke nur an die Diskussionen um Java als
Lehrsprache).

Man muss aber auch sehen, dass Universitäten oft mit der undustrie
zusammenarbeiten. Unis lehren ja nicht nur, sie forschen auch. Und
eigentlich ist ihre Lehre eine Ausbildung für spätere Forscher. Und da
Diplomarbeiten oft Teil der Forschung sind, orientiert man sich da halt
an der Industrie.

Wenn man in der Forschung tätig ist muss man aber in der Regel auch
nicht so viel Programmieren.

Post by Florian Weimer
Ich glaube daher, daß die Universitäten sich selbst mit
einer "unsere Absolventen können nicht Programmieren und wir sind
Stolz darauf"-Haltung ins Knie schießen.

Die Haltung ist eher: "wir legen den Grundstein, der Student muss sich
selbst weiterentwickeln". Allerdings entwickelt sich die Uni immer mehr
zur FH. Die Prüfungen werden mehr und weniger tief, die Eigenarbeit der
Studenten minimiert, das Studium gestrafft. Auf die art bekommt man
keine Fähigen Programmierer finde ich. alles finde ich es auch fraglich
ob die Uni sowas überhaupt produzieren muss.

Post by Florian Weimer
Auf der anderen Seite gibt's ja durchaus massiv-parallele Systeme, die
Personal produzieren, das (vielleicht nicht dem deutschen Diplom
vergleichbare) akademische Qualifikationen vorweisen kann *und* das
willens und fähig ist, Code zu produzieren. Bei den Herren
Personalchefs hat sich das tatsächlich herumgesprochen, und es wird
entsprechend gehandelt. Die Kostenfrage ist inzwischen nur ein
Teilaspekt.

Also in den Stellenanzeigen sehe ich davon nichts.

Gruss theo

--
Jochen "blackdrag" Theodorou
Groovy Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/

Martin Köhler

2007-03-04 20:26:21 UTC

Post by Jochen Theodorou
Die Haltung ist eher: "wir legen den Grundstein, der Student muss sich
selbst weiterentwickeln". Allerdings entwickelt sich die Uni immer mehr
zur FH. Die Prüfungen werden mehr und weniger tief, die Eigenarbeit der
Studenten minimiert, das Studium gestrafft. Auf die art bekommt man
keine Fähigen Programmierer finde ich. alles finde ich es auch fraglich
ob die Uni sowas überhaupt produzieren muss.

Das die Uni sich in der Form immer mehr der FH annähert stört mich auch.
Aber das Problem ist zum Teil auch, dass das einem Großteil der
Studenten entgegenkommt, da diese zum selbständigen Arbeiten kaum in der
Lage sind. Macht man nicht eine Mindespunktzahl aus den Übungszetteln
und regelmässige Anwesenheit in den Übungsgruppen als Voraussetzung zur
Zulassung zur Klausur, so erhält man exorbitante Durchfallquoten.

Gruß
Martin

--
Lustige Erlebnisse mit der Deutschen Bahn:
http://www.bahn-spass.de/

Jochen Theodorou

2007-03-05 15:51:55 UTC

Post by Martin KÃ¶hler

Ok, dann mal die Frage: Hat sich da in den letzten Jahren was verändert?
Wenn ja, dann sollte man fragen warum. Wenn nein, dann besteht doch
eigentlich kein wirklicher Bedarf dafür. Imho wird das nur gemacht weil
man die Studenten in kürzerer Zeit durch die Uni bringen will. Dann sind
sie früher in der Industrie und sorgen schneller für Arbeit. Scheinbar.
Denn wer die Uni druchläuft wie die Schule, der lernt oft nicht selber
zu denken - nicht wirklich jedenfalls. Selbständiges Arbeiten und
vorallem eigenverantwortliches Arbeiten geht so flöten. Wer das nicht
glaubt, der sollte sich mal ein paar chinesische Studenten anschauen und
wie schwer die sich tun mit dem Studium. Das liegt dann oft nicht nur an
der Sprache, sondern auch an der geringeren Steuerung durch andere.
Meiner Meinung nach sind Übungsgruppen und Übungsklausuren gut, aber
nciht wenn sie zwingend sind. Und die Übungsklausuren werden ja
langfristig eh weg fallen, weil dann direkt nach der Vorlesung geprüft
wird. Bei uns gab es früher viele Prüfungen die stoff von 4 Semestern
abgefragt haben, ist auf 2 Semester reduziert worden. Man hat teilweise
Multiplechoice eingeführt, aber um die Fragen zu beantworten muss man
genauso rechnen wie früher. Effektiv bekommt man also weniger Punkte,
weil man für den Rechenweg nichts bekommt.

Aber die Qualität lässt allgemein nach finde ich. Was andere in ihre
Blogs schreiben ist für manche ein Paper...

Gruss theo

--
Jochen "blackdrag" Theodorou
Groovy Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/

Wanja Gayk

2007-03-04 20:55:59 UTC

Post by Florian Weimer
Und ehrlich gesagt: Ich glaube nicht, daß jeder, der Forschung in der
Informatik macht, auf einen Kreis von Mitarbeitern zugreifen kann, die
seine Ideen umsetzen, ohne daß er sich selbst die Finger schmutzig
machen muß. Ich glaube daher, daß die Universitäten sich selbst mit
einer "unsere Absolventen können nicht Programmieren und wir sind
Stolz darauf"-Haltung ins Knie schießen.

Nochmal: Die Uni bildet Forscher aus.
Dein Einwand klingt in meinen Ohren so, als ob du dich darüber aufregst,
dass Lebensmittelchemiker keine guten Köche sind, wenn sie aus ihrer
Ausbildung kommen.

Die Stellenanzeigen sprechen eine andere Sprache.

Gruß,
-Wanja-

Florian Weimer

2007-03-04 21:47:11 UTC

Nochmal: Die Uni bildet Forscher aus.

Und? Es gibt genügend Disziplinen, wo Selbstprogrammieren das Forschen
erheblich erleichtert. Auch in der Informatik. Das hat weniger mit
Forschen zu tun, sondern eher damit, daß Programmieren eine
universelle Kulturtechnik ist. Trotzdem denke ich, daß man in der
Informatik verstärkt mit Problemen konfrontiert wird, bei dem das
Verhalten von real existierenden Rechnersystemen zumindest am Rand
eine Rolle spielt. In solchen Fällen sollte man seine Thesen sich auch
gefälligst auf echtem Eisen bewähren lassen -- und sei es nur, um
geschickt die Ergebnisse zu schönen.

Es geht mir, wohlgemerkt, nicht um "programming in the large", was
eine ganz andere Kategorie ist.

Post by Wanja Gayk
Dein Einwand klingt in meinen Ohren so, als ob du dich darüber
aufregst, dass Lebensmittelchemiker keine guten Köche sind, wenn sie
aus ihrer Ausbildung kommen.

Ich kenne mich mit Lebensmittelchemie nicht wirklich aus, vermute
aber, daß es in der Praxis meist nicht aufs Kochen ankommt,
insbesondere nicht auf die kulinarische Qualität.

Ich sehe dagegen einen haufen Forschungsarbeiten in der Informatik,
bei denen zumindest so getan wird, als ob die Autoren Programmcode zum
Laufen gebracht haben. Und der Weg dorthin ist bei kleinen Projekten
einfach schneller, wenn weniger Leute involviert sind.

Die Stellenanzeigen sprechen eine andere Sprache.

Liest Du chinesische Stellenanzeigen?

Jochen Theodorou

2007-03-05 16:01:59 UTC

Nochmal: Die Uni bildet Forscher aus.

Und? Es gibt genügend Disziplinen, wo Selbstprogrammieren das Forschen
erheblich erleichtert.

kommt darauf an. Wenn man eine Simulation macht oder ein Verfahren das
nur eine Näherungslösung berechnet ist selbst zu programmieren schon
notwendig, aber die Programme sind in der Regel eher klein und
optimierung bezieht sich auf theoretische Grössen, nicht auf das
Verwenden von StringBuilder statt StringBuffer.

Post by Florian Weimer
Auch in der Informatik.

Gerade in der Informatik gibt es ziemlich viele mathematisch orientierte
Teile. In diesen wird in der Regel nciht in echt programmiert, sondern
in Pseudocode, wenn überhaupt. Ausserdem passt das Zeug meist auf ein
paar Zeilen und wenn nicht, werden eben funktionen mit höherer Logik
vorrausgesetzt.

Post by Florian Weimer
Das hat weniger mit
Forschen zu tun, sondern eher damit, daß Programmieren eine
universelle Kulturtechnik ist.

Ich weiss zwar nicht was eine Kulturtechnik sein soll, aber wenn du eine
gewisse praktsiche Art meinst ein Problem zu lösen, dann stimme ich dir
zu. Nur das erwarte ich von einem Forscher nicht.

Post by Florian Weimer
Trotzdem denke ich, daß man in der
Informatik verstärkt mit Problemen konfrontiert wird, bei dem das
Verhalten von real existierenden Rechnersystemen zumindest am Rand
eine Rolle spielt.

verstärkt gegenüber was?

Post by Florian Weimer
In solchen Fällen sollte man seine Thesen sich auch
gefälligst auf echtem Eisen bewähren lassen -- und sei es nur, um
geschickt die Ergebnisse zu schönen.

wenn man den Vergleichsalgorithmus gleich schlecht implementiert, dann
sit das ja kein Problem. Dazu muss man kein guter Programmierer sein.

Post by Florian Weimer
Es geht mir, wohlgemerkt, nicht um "programming in the large", was
eine ganz andere Kategorie ist.

ja gut, aber um mehr als 100 Zeilen doch wohl schon, oder?

Post by Wanja Gayk
Dein Einwand klingt in meinen Ohren so, als ob du dich darüber
aufregst, dass Lebensmittelchemiker keine guten Köche sind, wenn sie
aus ihrer Ausbildung kommen.

Ich kenne mich mit Lebensmittelchemie nicht wirklich aus, vermute
aber, daß es in der Praxis meist nicht aufs Kochen ankommt,
insbesondere nicht auf die kulinarische Qualität.

Und so kommt es in der Forschung für den Informatiker auch oft weniger
aufs Programmieren an, vorallem hat das meist keinen Einfluss auf die
Qualität des Forschers. Hängt natürlich vom Bereich ab.

Post by Florian Weimer
Ich sehe dagegen einen haufen Forschungsarbeiten in der Informatik,
bei denen zumindest so getan wird, als ob die Autoren Programmcode zum
Laufen gebracht haben. Und der Weg dorthin ist bei kleinen Projekten
einfach schneller, wenn weniger Leute involviert sind.

dieser Programmcode ist meist Pseudocode.

Gruss theo

--
Jochen "blackdrag" Theodorou
Groovy Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/

Daniel Urban

2007-03-04 19:28:15 UTC

"Wanja Gayk"

Post by Wanja Gayk
Aber vielleicht sollten die guten Herren Personalchefs auch mal in ihren
Schwachkopf reinkriegen, dass Universitäten Akademiker ausbilden, keine
Programmierer. Das Programmieren ist im Studium (zumindest war es an
meiner Uni so) halt hin und wieder ein notwendiges Übel, aber auch nicht
mehr.

Das ist genau der Punkt. Die Universität soll für universitäre
Forschung und
Lehre ausbilden. Natürlich können nicht alle absolventen in der Uni
unterkommen. Aber diese Leute sollten dann in der Wirtschaft auch bei
konzeptionellen oder architekurellen Fragen eingesetzt werden und
später
auch im Projektmanagment und für Führungsaufgaben.

Fakt ist aber, daß in Firmen Systemanalayse, Spezifikation und
Implementierung von ein und der selben Personengruppe ausgeführt wird,
was in vielen Fällen einfach billiger ist.

Dies hat die Uni aber mittlerweile auch begriffen, aller Ortens wird
versucht,
daß Studium praxisorientierter zu machen.

Man kann aber eigentlich niemals erwarten, daß ein Absolvent die Uni
als Java-Spezialist verläßt. Ich bin der Meinung, daß man auf der Uni
weiterhin Konzepte lernen sollte und wie man sich selbst etwas
beibringt.
Dann sollte man in kurzer Zeit jede Programmiersprache ordentlich
beherrschen und nach ein oder zwei Jahren auch Spezialist sein.

Mal abgsehen von bestimmten Gruppen, wie theoretische Informatiker
oder Informatiker im Datenschutzbereich oder sonstigen juristischen
Bereichen, sollte ein Informatiker Spaß am Implementieren haben und
dementsprechend auch geeignet sein. Leider studieren immer mehr
Leute Informatik, die keine Mathematik oder Logik mögen und schon
gar nicht programmieren wollen.

Grúß,

Daniel

Carsten Wanke

2007-03-04 22:07:30 UTC

Hallo Daniel,

Post by Daniel Urban
Leider studieren immer mehr
Leute Informatik, die keine Mathematik oder Logik mögen und schon
gar nicht programmieren wollen.

Es soll ja auch immer mehr Vegetarier geben, die sich zum Fleischerhandwerk
berufen fühlen...

Gruß,
Carsten

Uwe Naumann

2007-03-04 21:58:53 UTC

Teilweise wohl schon. Wobei die Frage eigentlich eher ist, wo genau das
Übel liegt.

Wie schon andere schrieben: fürs Programmieren braucht man nicht
unbedingt ein Hochschulstudium, weil das oft schon zu sehr ins Akademische
geht. Dort oft viel theoretisches Wissen vermittelt, aber nicht wie man es
praktisch sinnvoll anwendet. Leider ist es aber oft so das genau dieses
Diplom für viele Jobs unsinnigerweise als Voraussetzung angesehen wird.
Man werfe einfach mal einen Blick in die Stellenanzeigen der
$BELIEBIGE_ZEITUNG.

Andererseits scheint es teilweise wirklich so zu sein, das man den Leuten
primär die Bedienung diverser Tools vermittelt anstelle Ihnen das
Programmieren beizubringen. Zumidest scheint dies bei unseren BA-Studis so
zu laufen. Visual Studio kennen die blind. Aber beim Analysieren und
Abstrahieren eines Problems oder beim Anwendungsdesign haperts. Wobei man
denen das nicht mal zum Vorwurf machen kann. Sie bekommen es ja so
beigebracht :-(

--
Gruss Uwe

--------- cut here with a very sharp knife ---------
Uwe Naumann eMail: uwe[at]vieledinge[dot]de
Web: http://www.vieledinge.de http://www.swllog.de

Florian Weimer

2007-03-04 22:07:25 UTC

Post by Uwe Naumann
Andererseits scheint es teilweise wirklich so zu sein, das man den Leuten
primär die Bedienung diverser Tools vermittelt anstelle Ihnen das
Programmieren beizubringen. Zumidest scheint dies bei unseren BA-Studis so
zu laufen. Visual Studio kennen die blind. Aber beim Analysieren und
Abstrahieren eines Problems oder beim Anwendungsdesign haperts.

Eben das ist ja auch ein Grund, warum man doch jemanden haben will,
der eine Ausbildung durchlaufen hat, bei der nach Kriterien wie der
Abstraktionsfähigkeit gesiebt wird. Auch wenn das in heutigen Zeiten
unpopulär ist und nicht besonders hart durchgezogen wird.

(Mit ein wenig Erfahrung, was in dieser Situation zumutbar ist, sollte
man das aber auch im Bewerbungsgespräch feststellen können. Das
skaliert aber schlechter als ein einfaches Ausschlußkriterium.)

Kurt Stege

2007-03-05 10:47:37 UTC

Was erwartest Du eigentlich?

Was hat Informatik mit Programmieren zu tun?

Informatik ist eine Wissenschaft, vergleichbar mit der Mathematik.
Man könnte vielleicht sogar sagen, die Informatik wäre ein Teilgebiet
der Mathematik, aber das lasse ich nun lieber, denn genauso könnte
man argumentieren, daß die Chemie ein Teilgebiet der Physik wäre.

Programmieren ist ein Handwerkszeug, vergleichbar mit Rechnen.

Als Mathemaktiker lernt man nicht wirklich, komplexe Integrale
zu knacken. (Dafür hat man ja die Phyisker und Elektrotechniker;
die können das besser.) Eine der ersten Übungsaufgaben in meinem
Mathe-Studium war nicht etwa "Berechnen Sie 2+2." Nein, sie lautete
"Zeigen Sie, daß 2+2 vier ergibt."

Wer Programmierer sucht, sollte nicht unbedingt Diplom-Informatiker
suchen, sondern Leute, die in ihrer Ausbildung programmieren gelernt
und geübt haben. Wer Leute sucht, die Rechnen können, zum Beispiel
um Differenzialgleichungen lösen, sollte von Diplom-Mathematikern
Abstand nehmen (wobei es natürlich auch dort welche gibt, die das
gut können; aber man lernt es nicht zwangsläufig im Studium). Wer
jemanden sucht, der neue Verfahren entwickeln soll, mit denen man
Differentialgleichungen auf andere Art als bisher lösen kann, ist
mit Mathematikern gut bedient. Denn dafür ist eine wissenschaftliche
Denkweise und Herangehensweise nützlich.

Wer jemanden sucht, um Fizzbuzz zu programmieren, sollte einen
ausgebildeten "Handwerker" einstellen. Wer einen braucht, um dabei
zu helfen, eine Software zu schreiben, die maschinell nachweist, ob
ein schon vorhandenes Fizzbuzz-Programm wirklich Fizzbuzz macht,
also einen Korrektheitsbeweis durchführt, sollte für das Vorhaben
auch Wissenschaftler, Informatiker, einsetzen, die die dafür passende
"Denke" haben.

Selbstverständlich gibt es viele Diplom-Informatiker, die auch
programmieren können. Aber das hat vermutlich eher mit den
persönlichen Hobbys des Kandidaten zu tun als mit der Ausbildung
zum Wissenschaftler. Genauso gibt es ja auch viele Physiker und
Mathematiker und Maurer, die gut programmieren können.

Und selbstverständlich ist es auch für viele Programmieraufgaben
nützlich, wenn der Programmierer einen wissenschaftlichen Hintergrund
hat und in seiner Ausbildung eine logisches Denken durch ein
beliebiges (natur-)wissenschaftliches Studium geübt hat. Und in
ganz seltenen Fällen hilft sogar das fachliche Wissen weiter,
daß der Kandidat in seinem Studium gelernt hat. Aber das ist,
meiner Erfahrung nach, eher die Ausnahme...

<Hier bitte Deinen Lieblings-Schlußpunkt nach eigener Wahl einfügen.>

Gruß,
Kurt.

Frank Buss

2007-03-05 22:59:04 UTC

Post by Kurt Stege
Wer Programmierer sucht, sollte nicht unbedingt Diplom-Informatiker
suchen, sondern Leute, die in ihrer Ausbildung programmieren gelernt
und geübt haben. Wer Leute sucht, die Rechnen können, zum Beispiel
um Differenzialgleichungen lösen, sollte von Diplom-Mathematikern
Abstand nehmen

Der Vergleich hinkt etwas. Mir ist schon klar, daß ein Informatiker nicht
unbedingt so gut wie jemand programmieren können muß, der programmieren als
Schwerpunkt gelernt hat oder seit duzenden von Jahren hauptberuflich macht.
Aber um bei dem Beispiel mit dem Mathematiker zu bleiben, würde ich
FizzBuzz eher damit vergleichen, daß einer weiß, was Punktrechnung vor
Strichrechunung ist und im Kopf z.B. 2*x+4=0 nach x auflösen kann. Das ist
zwar auch nur in gewissen Sinne rechnen, aber wenn ein Mathematiker solche
grundlegenden Dinge nicht beherrscht, dann wird er Schwierigkeiten haben,
z.B. Beweise selber zu erstellen, da er viel länger dafür braucht, wenn er
sowas immer in ein CAS eintippen muß.

Auf den Informatiker übertragen: Es ist nicht notwendig, daß jemand der
Informatik studiert hat, einen effizienten H.264 Video-Encoder schreiben
kann (wie ein Mathematiker nicht unbedint komplexe Intetrale lösen können
muß), aber wenn er sowas wie FizzBuzz nicht lösen kann, dann würde ich
bezweifeln, daß er überhaupt Aufgabenstellungen jeglicher Art im
Informatikbereich selbständig lösen kann.

Ich gehe dabei vielleicht von der falschen Annahme aus, daß die Fähigkeit
zu programmieren etwas Grundsätzliches ist, vergleichbar damit, Anleitungen
zu schreiben, Kochrezepte (analog zu imperativen Programmierstil) oder
Gesetzestexte (analog zu deklarativen Programmierstil). Also allgemein
gesprochen, die Fähigkeit, anhand einer gegebenen Aufgabenstellung,
Anweisungen so zu verfassen, daß die eine gegebene Zielperson, in die der
Autor sich hineinversetzt, lösen kann, ohne groß nachdenken zu müssen. Beim
Programmieren ist die "Zielperson" ein Computer. Auch wenn das nicht jeder
kann und es vielleicht nicht nötig ist, wenn man einen Korrektheitsbeweis
für ein Programm führt, hilft es meiner Meinung nach ungemein, wenn ein
Informatiker zumindest ansatzweise diese Fähigkeit besitzt, wenn er mit
"richtigen" Programmierern zusammenarbeitet.

Und für komplexere Probleme, bei denen ein Korrektheitsbeweis nicht mehr
mathematisch exakt mit vertretbarem Aufwand möglich ist, muß man sich in
die Funktionsweise eines Computers hineinversetzen können, um Vermutungen
darüber anstellen zu können, ob das Programm das tut was es soll. Die beste
Möglichkeit zu prüfen, ob jemand dazu in der Lage ist, ist, wenn er
zumindest einfache Programme selber schreiben kann, denn erst dann hat er
meiner Meinung nach Computer richtig verstanden. Vielleicht sollten wir das
aber weiter in de.sci.philosophie fortführen, Stichwort Qualia: Es ist
etwas anderes, wenn ein von Geburt an Blinder weiß, welche Wellenlänge die
Farbe rot hat und wenn ein Sehender die Farbe rot sieht.

--
Frank Buss, ***@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Jochen Theodorou

2007-03-06 10:10:16 UTC

Frank Buss schrieb:
[...]

Post by Frank Buss
Auf den Informatiker übertragen: Es ist nicht notwendig, daß jemand der
Informatik studiert hat, einen effizienten H.264 Video-Encoder schreiben
kann (wie ein Mathematiker nicht unbedint komplexe Intetrale lösen können
muß), aber wenn er sowas wie FizzBuzz nicht lösen kann, dann würde ich
bezweifeln, daß er überhaupt Aufgabenstellungen jeglicher Art im
Informatikbereich selbständig lösen kann.

der Informatikbereich ist längst nicht mehr so eng mit der
Programmierung verzahnt.

Post by Frank Buss
Ich gehe dabei vielleicht von der falschen Annahme aus, daß die Fähigkeit
zu programmieren etwas Grundsätzliches ist, vergleichbar damit, Anleitungen
zu schreiben,

öhm... es gibt sehr schlechte Anleitungen ;)

Post by Frank Buss
Kochrezepte (analog zu imperativen Programmierstil) oder
Gesetzestexte (analog zu deklarativen Programmierstil).

urks... bitte lass Gesetzestexte weg.. wenn man mehrere Gerichtsurteile
braucht um das Gesetz richtig interpretieren zu können, dann hat das
nichts mit Programmieren zu tun.

Post by Frank Buss
Also allgemein
gesprochen, die Fähigkeit, anhand einer gegebenen Aufgabenstellung,
Anweisungen so zu verfassen, daß die eine gegebene Zielperson, in die der
Autor sich hineinversetzt, lösen kann, ohne groß nachdenken zu müssen. Beim
Programmieren ist die "Zielperson" ein Computer. Auch wenn das nicht jeder
kann und es vielleicht nicht nötig ist, wenn man einen Korrektheitsbeweis
für ein Programm führt, hilft es meiner Meinung nach ungemein, wenn ein
Informatiker zumindest ansatzweise diese Fähigkeit besitzt, wenn er mit
"richtigen" Programmierern zusammenarbeitet.

Bitte beachte, es geht weniger darum dass die Aufgabe nicht lösbar wäre
für ihn, es geht um den Zeitrahmen der dafür notwendig ist.

Gruss theo

--
Jochen "blackdrag" Theodorou
Groovy Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/

Ingo R. Homann

2007-03-06 10:30:17 UTC

Hi,

Post by Frank Buss
Ich gehe dabei vielleicht von der falschen Annahme aus, daß die Fähigkeit
zu programmieren etwas Grundsätzliches ist, vergleichbar damit, Anleitungen
zu schreiben,

öhm... es gibt sehr schlechte Anleitungen ;)

Stimmt. Aber ich glaube, Du verfehlst Frank's Punkt (oh, ein
Anglizismus!): Er meint IMHO, dass man die Fähigkeit zu programmieren
oder die Fähigkeit, (gute) Anleitungen zu schreiben entweder hat oder
nicht hat, und dass sie, wenn man die "Veranlagung" dazu nicht hat, sie
nur in bestimmtem (geringen) Maße antrainieren kann.

(Wobei ich Frank im übrigen zustimmen würde.)

Post by Frank Buss
Kochrezepte (analog zu imperativen Programmierstil) oder
Gesetzestexte (analog zu deklarativen Programmierstil).

urks... bitte lass Gesetzestexte weg.. wenn man mehrere Gerichtsurteile
braucht um das Gesetz richtig interpretieren zu können, dann hat das
nichts mit Programmieren zu tun.

Ich finde den Vergleich sehr schön. Was Dich daran irritiert, ist
vermutlich was anderes (was dann aber wieder sehr schön zum
Programmieren passt) - Gesetzestexte müssen zwischen verschiedenen
Aspekten austariert sein:

(A) sie sollten so allgemein verfasst sein, dass sie möglichst *viele*
(Einzel-)Fälle abdecken.

(B) sie sollen natürlich eine gewisse Einzelfallgerechtigkeit
berücksichtigen

(C) sie sollten möglichst kurz und verständlich sein und im Idealfall
wenig Interpretationsspielraum lassen

(D) sie sollten "konsistent" zu anderen Gesetzen sein

...

Alle diese Aspekte lassen sich idR nicht unter einen Hut bringen. Und
nur aus dem Grund gibt es eben den Interpretationsspielraum. Was Dich
bei dem Vergleich zur Informatik irritiert ist, dass es in der
Informatik nicht den "Interpretationsspielraum" für eine JVM
(="Anwendung des Gesetzes") gibt. Aber auf Seite des Programmierers
(="Gesetzgebung") gibt es schon einen Interpretationsspielraum: Kann
diese Problemklasse mit jener Problemklasse sinnvoll unter einen Hut
gebracht werden, um sie gemeinsam mit einem Programm (=Gesetz) abzudecken.

Natürlich hinkt jeder Verglich ein wenig - sonst wäre es keiner!
Trotzdem finde ich die Veranschaulichung "imperative Sprache=Kochrezept,
deklarative Sprache=Gesetzestext" insgesamt ziemlich treffend.

Ciao,
Ingo

Jochen Theodorou

2007-03-06 11:23:38 UTC

Post by Ingo R. Homann
Hi,

Post by Frank Buss
Ich gehe dabei vielleicht von der falschen Annahme aus, daß die Fähigkeit
zu programmieren etwas Grundsätzliches ist, vergleichbar damit, Anleitungen
zu schreiben,

öhm... es gibt sehr schlechte Anleitungen ;)

ah, ok, ja, dem stimme ich auch zu. Das ist so ähnlich wie mit dem
unterschied von Genie und normalen Menschen. beide können gleich gut
sein, nur muss sich das Genie für das gleiche Ergebnis weit weniger
anstrengen.

[...]

Post by Ingo R. Homann
Alle diese Aspekte lassen sich idR nicht unter einen Hut bringen. Und
nur aus dem Grund gibt es eben den Interpretationsspielraum. Was Dich
bei dem Vergleich zur Informatik irritiert ist, dass es in der
Informatik nicht den "Interpretationsspielraum" für eine JVM
(="Anwendung des Gesetzes") gibt. Aber auf Seite des Programmierers
(="Gesetzgebung") gibt es schon einen Interpretationsspielraum: Kann
diese Problemklasse mit jener Problemklasse sinnvoll unter einen Hut
gebracht werden, um sie gemeinsam mit einem Programm (=Gesetz) abzudecken.

in beiden Fällen wird etwas beschrieben, ja. soweit ist der Vergleich
schon korrekt. Aber das ist auch schon alles. Insofern hat ein LKW auch
viel mit einem Fahrrad gemin, beides hat Räder, beides kann Menschen
transportieren, beides kann auf der Strasse fahren.

Programmiersprachen enthalten eine sehr limitierte Menge an Wörtern.
Wenn man Methoden/Funktionen/Variablen/... als Wörter auffasst, dann
kann man neue schaffen, aber nicht ohne sie zu definieren. Gesetzestexte
basieren auf der menschlichen Sprache und können niemals so formal sein,
dass alles definiert ist. Wenn es da heisst: Die Würde des Menschen ist
unantastbar. Dann stellen sich doch sofort die Fragen: Was ist ein
Mensch? Was ist Würde? Wann ist die Würde wirklich angetastet? Die Frage
wann ein Mensch tatsächlich ein Mensch ist, ist durchaus relevant wenn
es um Embryonen geht. Und Würde ist ein Begriff der dem Zeitgeist und
der jeweiligen Kultur unterliegt.

Selbst wenn man deklarativ programmiert, so befasst man sich doch noch
immer mit dem limitierten Satz an Wörtern, die die Sparache zur
Verfügung stellt. Es widerstrebt mir sehr, einen Menschen mit einem Satz
Daten zu vergleichen.

Gruss theo

--
Jochen "blackdrag" Theodorou
Groovy Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/

Ingo R. Homann

2007-03-06 12:19:31 UTC

Hi Theo,

in beiden Fällen wird etwas beschrieben, ja. soweit ist der Vergleich
schon korrekt....
Programmiersprachen enthalten eine sehr limitierte Menge an Wörtern.
Wenn man Methoden/Funktionen/Variablen/... als Wörter auffasst, dann
kann man neue schaffen, aber nicht ohne sie zu definieren. Gesetzestexte
basieren auf der menschlichen Sprache und können niemals so formal sein,
dass alles definiert ist. Wenn es da heisst: Die Würde des Menschen ist
unantastbar. Dann stellen sich doch sofort die Fragen: Was ist ein
Mensch? Was ist Würde? Wann ist die Würde wirklich angetastet? Die Frage
wann ein Mensch tatsächlich ein Mensch ist, ist durchaus relevant wenn
es um Embryonen geht. Und Würde ist ein Begriff der dem Zeitgeist und
der jeweiligen Kultur unterliegt.

OK, das deklarative Programm "Gesetzestext" greift also auf eine API zu,
von der es unterschiedliche Versionen gibt! ;-)

Naja, wie gesagt: Natürlich hinkt jeder Vergleich, wenn man ihn
überstrapaziert. Man sollte das nicht zu hoch hängen...

Post by Jochen Theodorou
Selbst wenn man deklarativ programmiert, so befasst man sich doch noch
immer mit dem limitierten Satz an Wörtern, die die Sparache zur
Verfügung stellt.

OK.

Post by Jochen Theodorou
Es widerstrebt mir sehr, einen Menschen mit einem Satz
Daten zu vergleichen.

Hä? Wie kommst Du jetzt darauf? Der Gedankensprung ist mir nicht klar...

Ciao,
Ingo

Jochen Theodorou

2007-03-06 15:38:16 UTC

Ingo R. Homann schrieb:
[..]

Post by Jochen Theodorou
Es widerstrebt mir sehr, einen Menschen mit einem Satz
Daten zu vergleichen.

Hä? Wie kommst Du jetzt darauf? Der Gedankensprung ist mir nicht klar...

na, wenn die Gesetzestexte eine beschreibung eines Programmes wären und
die Judikative+Executive die VM, dann sind die Daten für das daraus
resultierende Programm doch wohl die Menschen, oder? Schliesslich muss
ja auch was verarbeitet werden.

Gruss theo

--
Jochen "blackdrag" Theodorou
Groovy Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/

Wanja Gayk

2007-03-06 18:48:53 UTC

Post by Jochen Theodorou
na, wenn die Gesetzestexte eine beschreibung eines Programmes wären und
die Judikative+Executive die VM

Dann ist System.exit(0) Selbstmord und wir müssen uns die Frage stellen
welche Strafe auf "kill -9" steht: Kündigung des Admins?

Gruß,
-Wanja-

Jochen Theodorou

2007-03-06 19:44:37 UTC

Post by Jochen Theodorou
na, wenn die Gesetzestexte eine beschreibung eines Programmes wären und
die Judikative+Executive die VM

Dann ist System.exit(0) Selbstmord und wir müssen uns die Frage stellen
welche Strafe auf "kill -9" steht: Kündigung des Admins?

es gibt einen SecurityManager der das verhindert ;)

Gruss theo

--
Jochen "blackdrag" Theodorou
Groovy Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/

Ingo R. Homann

2007-03-07 08:27:37 UTC

Hi,

Post by Jochen Theodorou
Es widerstrebt mir sehr, einen Menschen mit einem Satz
Daten zu vergleichen.

Hä? Wie kommst Du jetzt darauf? Der Gedankensprung ist mir nicht klar...

Achso. Hmmm, OK, aber ich seh' da das Problem nicht: Ansonsten dürftest
Du ja keine Anwendung schreiben, die irgendwie mit echten Personen-Daten
arbeitet, weil man damit ja "den Menschen auf ein paar Daten reduziert".

Ciao,
Ingo

Jochen Theodorou

2007-03-07 09:32:59 UTC

Post by Ingo R. Homann
Hi,

Post by Jochen Theodorou
Es widerstrebt mir sehr, einen Menschen mit einem Satz
Daten zu vergleichen.

Hä? Wie kommst Du jetzt darauf? Der Gedankensprung ist mir nicht klar...

na, wenn die Gesetzestexte eine beschreibung eines Programmes wären
und die Judikative+Executive die VM, dann sind die Daten für das
daraus resultierende Programm doch wohl die Menschen, oder?
Schliesslich muss ja auch was verarbeitet werden.

ja, aber Judikative and Executive obligen da normalerweise immernoch
Menschen, die hoffentlich genug Verstand haben nicht einfach einem
Programm zu folgen

Gruss theo

--
Jochen "blackdrag" Theodorou
Groovy Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/

Ingo R. Homann

2007-03-07 09:56:59 UTC

Hi,

Post by Ingo R. Homann
Achso. Hmmm, OK, aber ich seh' da das Problem nicht: Ansonsten
dürftest Du ja keine Anwendung schreiben, die irgendwie mit echten
Personen-Daten arbeitet, weil man damit ja "den Menschen auf ein paar
Daten reduziert".

ja, aber Judikative and Executive obligen da normalerweise immernoch
Menschen, die hoffentlich genug Verstand haben nicht einfach einem
Programm zu folgen

Nun, ich könnte jetzt sagen, dass die Justiz ja eigentlich blind dafür
sein sollte, ob auf der Anklagebank z.B. ein Politiker oder aber ein
Ottonormalverbraucher sitzt.

Aber ich glaube, Du meinst etwas anderes (dem ich durchaus zustimmen würde).

Wie gesagt: Man sollte Vergleiche nicht überstrapazieren.

EOT?

Ciao,
Ingo

Frank Buss

2007-03-06 23:27:22 UTC

Post by Ingo R. Homann
Stimmt. Aber ich glaube, Du verfehlst Frank's Punkt (oh, ein
Anglizismus!): Er meint IMHO, dass man die Fähigkeit zu programmieren
oder die Fähigkeit, (gute) Anleitungen zu schreiben entweder hat oder
nicht hat, und dass sie, wenn man die "Veranlagung" dazu nicht hat, sie
nur in bestimmtem (geringen) Maße antrainieren kann.

Ich wollte zunächst mal nur beschreiben, was Programmieren für eine Art von
Tätigkeit ist. Ich bin mir nicht sicher, ob es mehr eine Fertigkeit, also
rein antrainierbar, oder eine Fähigkeit, also rein angeboren, ist, tendiere
allerdings auch dazu, es mehr als Fähigkeit anzusehen, wobei aber wohl
jeder halbwegs begabte Mensch es auch lernen kann, aber dann länger für die
Anwendung braucht, ähnlich zu dem Sport-Vergleich hier in diesem Thread.

Post by Jochen Theodorou
Programmiersprachen enthalten eine sehr limitierte Menge an Wörtern.
Wenn man Methoden/Funktionen/Variablen/... als Wörter auffasst, dann
kann man neue schaffen, aber nicht ohne sie zu definieren.

Na und? Gesetzestexte enthalten eine sehr limitierte Anzahl von möglichen
Zeichen :-)

Gut fand ich das Zitat von Knuth, daß man etwas nicht vertanden hat, wenn
man es nicht programmiert hat. Vielleicht hat er ja auch deswegen die
merkwüdige Assembler-Sprache in seiner Buchserie eingeführt?

Als Anekdote fällt mir dazu ein, daß jemand, der nicht programmieren
konnte, aber fit darin war, Entity-Relationship Diagramme zu zeichnen,
versucht hat, ein Regelsystem zur Beschreibung von komplexen Produkten
(Versicherungen) zu entwerfen. In 8 Punkte Schriftgröße passten dann
schließlich all die netten Kästchen und Linien gut auf ein DIN-A2 Blatt,
wenn man es etwas quetsche, und was man normalerweise per Programmmodul und
ein paar Zeilen if-then, for-Schleifen usw. hätte abbilden können, wäre
damit dann theoretisch per Instanzen der Entitäten abbildbar gewesen, was
auch auf den ersten Blick plausibel klang. Nur war das Modell leider so
kompliziert, daß es nie jemand vernünftig hätte implementieren, warten oder
auch nur einsetzen können. Es wurde dann nicht umgesetzt und viele
Sachbearbeiter verwenden heute noch die Großrechner-Terminalanwendungen,
die sie schon seit 20 Jahren gewohnt sind einzusetzen und mit denen man im
Vergleich zu manchen Java-Anwendungen auch noch effizient arbeiten kann
(wenn man denen mal zuschaut, wie die über die Tasten fliegen, da kommt
keine Maus mit :-)

--
Frank Buss, ***@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Stefan Offermann

2007-03-06 15:45:45 UTC

Ich meine, Programmieren ist wie Sport: Eine gewisse Veranlagung muss
man mitbringen, danach hilft nur üben, üben, üben. Wer nicht regelmässig
trainiert, der wird schlecht. Je öfter man eine gewisse Übung
wiederholt, desto besser absolviert man sie wenn es drauf ankommt (zB
Schleifen, Programmabläufe programmieren).

my2cent, Stefan

--
student of geoinformatic

ifgi - institute for geoinformatics
www.ifgi.de

Wanja Gayk

2007-03-06 18:44:33 UTC

Post by Ingo R. Homann
Stimmt. Aber ich glaube, Du verfehlst Frank's Punkt (oh, ein
Anglizismus!)

Eher ein falscher Apostroph.

SCNR,
-Wanja-

Paul Ebermann

2007-03-07 23:55:39 UTC

Post by Frank Buss
Kochrezepte (analog zu imperativen Programmierstil) oder
Gesetzestexte (analog zu deklarativen Programmierstil).

urks... bitte lass Gesetzestexte weg.. wenn man mehrere Gerichtsurteile
braucht um das Gesetz richtig interpretieren zu können, dann hat das
nichts mit Programmieren zu tun.

Ich finde den Vergleich sehr schön. Was Dich daran irritiert, ist
vermutlich was anderes (was dann aber wieder sehr schön zum
Programmieren passt) - Gesetzestexte müssen zwischen verschiedenen

[...]

Hmm, es gibt da doch noch einigen Spielraum. Bei Java
verhältnismäßig wenig (z.B. bei Multithreading-Verhalten
und neuerdings etwa, wie viele (neben den minimal
vorgeschriebenen) Werte eines Wrapper-Typs für das
Boxing vorgehalten werden).

Bei C z.B. lässt die Spezifikation viel mehr Luft für verschiedene
Implementationen, dazu gibt es in de.comp.lang.c ja regelmäßig
Diskussionen (bzw. gab es, als ich da vor einigen Jahren mal
mitgelesen habe).

Paul

--
Nun ludigxas: Persone: La Levigxo de la Lun' (Povus Esti Simple)

Sven Drieling

2007-03-06 18:11:41 UTC

Jochen Theodorou wrote:

Hallo,

der Informatikbereich ist längst nicht mehr so eng mit der
Programmierung verzahnt.

"Man versteht etwas nicht wirklich, wenn man nicht versucht,
es zu implementieren."

-- Donald E. Knuth, http://www.heise.de/ct/02/05/190/

tschuess
[|8:)

Jochen Theodorou

2007-03-06 19:47:08 UTC

Post by Sven Drieling
Hallo,

der Informatikbereich ist längst nicht mehr so eng mit der
Programmierung verzahnt.

"Man versteht etwas nicht wirklich, wenn man nicht versucht,
es zu implementieren."
-- Donald E. Knuth, http://www.heise.de/ct/02/05/190/

ja, passt zu ihm. Ich bin auch so einer der es anders nicht wirklich
verstehen kann. Allerdings gibt es da auch andere

Gruss theo

--
Jochen "blackdrag" Theodorou
Groovy Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/

Ivan Dolvich

2007-03-07 09:29:57 UTC

Post by Sven Drieling
"Man versteht etwas nicht wirklich, wenn man nicht versucht,
es zu implementieren."
-- Donald E. Knuth, http://www.heise.de/ct/02/05/190/

Auch Peter Norvig ist ein Wissenschaftler (hat Bücher über KI
geschrieben) und super Programmierer (Lisp-Guru). Hier seine Lösung zu
einer Aufgabe, die in einem Programmierwettbewerb gestellt wurde.

http://norvig.com/java-lisp.html (Lösung)
http://www.flownet.com/ron/papers/lisp-java/ (Aufgabe)

Viele Grüße

Daniel Alder

2007-03-05 23:41:20 UTC

die Mehrzahl aller Informatik Absolventen kann nicht programmieren
Programmierer getroffen, bei denen ich vermuten würde, daß sie
längere Zeit für die Lösung brauchen würden, ähnlich wie der im
Artikel erwähnte "senior programmer".

Informatik Absolvent != Programmierer

Ralf Ullrich

2007-03-06 01:52:19 UTC

Post by Daniel Alder

die Mehrzahl aller Informatik Absolventen kann nicht programmieren
Programmierer getroffen, bei denen ich vermuten würde, daß sie längere
Zeit für die Lösung brauchen würden, ähnlich wie der im
Artikel erwähnte "senior programmer".

Informatik Absolvent != Programmierer

Na und was willst du uns damit sagen?

Schließlich gilt auch:

Kfz-Mechanikermeister != Autofahrer

trotzdem wird man gewöhnlich von einem solchen Meister erwarten, dass er
selbst auch Autofahren kann. Nicht nur wegen der vorgeschriebenen
Testfahrten, sondern auch um sich in die Problembeschreibungen der Kunden
einfühlen zu können.

Und ein Informatik-Absolvent, der absolut keine Ahnung von Programmieren
hat, sollte besser keine API designen, die dann einen Programmierer zur
Verzweiflung bringt, weil sie schlicht nicht umsetzbar ist.

Komm also bitte von deinem hohen Ross runter. Programmieren können ist für
einen Informatiker eine Grundlage, wie für beinahe jeden Beruf Lesen und
Schreiben eine Grundlage ist. Und wenn dir das immer noch nicht einleuchtet:

Musik-Absolvent != Notensetzer

Aber ein Musikabsolvent, der nicht mal ein kleines Stück passend für eine
bestimmte Bandzusammensetzung umarrangieren kann, oder mal die Tonlage der
Stimmlage der Leadsängerin anpassen kann, der putzt sich mit seinem
Abschluß besser gleich den Hintern. Einen professionellen Job braucht er
jedenfalls nicht suchen. Dito. IMHO für Informatik-Absolventen die nicht
Programmieren können.

cu

Gerd K.

2007-03-06 07:32:18 UTC

Hi!

Post by Ralf Ullrich
Komm also bitte von deinem hohen Ross runter. Programmieren können ist für
einen Informatiker eine Grundlage, wie für beinahe jeden Beruf Lesen und
Schreiben eine Grundlage ist.

Das stimmt so nicht. Ein Informatiker sollte getreu der Wahrheit ;-)
"Der Weg von der Theorie zur Praxis ist eine Frage des Wollens,
der Weg von der Praxis zur Theorie eine Frage des Könnens"
in der Lage sein, nach einer ausreichenden Einarbeitungszeit gut
programmieren zu können. Aber das dieser sich notwendigerweise
mit Programmierung gut auskennen muss, stimmt nicht. Ganz im Gegenteil:
Es gibt Aufgabenbereiche, da kann eine zu gute Programmierfähigkeit
bei nicht so guten Informatikern schädlich sein: Requirements
Engineering z.B. Hier wird die Realwelt abgebildet. Und wenn man
da nicht sauber die Abstraktionsebenen auseinanderhält und mit dem
Scheuklappenblick eines Programmieres analysiert, führt dies zu
schlechten Ergebnissen.

Programmierung=Codierung wird immer "unwichtiger" bei der Erzeugung
qualitativ hochwertiger Software mittels Methoden und Werkzeugen
des Software Engineerings.
Ein sehr lesenswerte Stellungnahme von führenden Experten und
Vertretern der Industrie zum Thema Software Engineering:

www.sse.cs.tu-bs.de/publications/Dagstuhl_Manifest_SE.pdf

Ein Fazit: Software Engineering ist so anspruchsvoll und komplex,
dass es nur in einem Diplom- bzw. Masterstudiengang sinnvoll
vermittelt werden kann, nicht in einem FH oder Bachelor-Studium.
Was nicht zuletzt an den notwendigen theoretischen mathematischen
Grundlagen liegt, von denen ein "normaler Programmierer" gar nicht
einmal ahnt, das es sowas gibt.

Ein etwas hinkender Vergleich zum Thema "Informatiker und Programmieren"
zum Schluß:
Hitzfeld ist ein guter Fußballtrainer obwohl er während eines
Spiels nicht selber die Tore schiesst. ;-)

(Das Hinken resultiert aus der Tatsache, dass er nach
beliebiger Trainingszeit als Fußballspieler nie so gut
sein kann, um in irgendeiner Kreisliga-Mannschaft zu spielen) ;-)

Grüße!
Gerd

Ralf Ullrich

2007-03-06 08:36:42 UTC

Ich Frage mich zusehends, ob eigentlich Grundlagen der Logik auch zum
Studienpensum eines Diplom Informatikers gehören. Vielleicht liegts auch
am Leseverständnis, oder warum werden mir die Worte im Mund verdreht?
Juristen werden ja darin geschult, geshcriebene Texte zu verstehen,
vielleicht sollten das manche Informatiker auch wenigstens mal im
Nebenfach beigebracht bekommen.

Post by Gerd K.
Aber das dieser sich notwendigerweise
mit Programmierung gut auskennen muss, stimmt nicht.

Wo genau habe ich geschrieben, dass ein Informatiker sich _gut_ auskennen
muss?

Von einer Sekretärin erwartet man auch dass sie Schreiben kann und
Rechtschreibung wenigstens durchschnittlich gut beherrscht. Keiner
verlangt von ihr ein zweiter Goethe, oder vielleicht passender eine zweit
Droste-Hülshoff

Nochmal deutlich: Ich spreche von Grundlagen. "Programmieren können" und
zwar egal wie gut und egal in welcher Sprache ist eine Grundlage, die ein
Informatiker beherrschen muss. Wenn die Frage lautet, "Wie zeichnet man
ein Quadrat in den Schnee?", dann muss der Informatiker sagen können
"Tripple einen Meter geradeaus, drehe dich um 90° nach rechts, und
widerhole das ganze noch dreimal." Wenn er das nicht aus dem Stegreif
hinbekommt, wird auch nicht herausfinden können welche Daten wie in ein
relationales Datenmodell überführt werden können, oder wie ein Anwender
durch notwendige Arbeitsschritte geführt werden kann, ohne verwirrt zu
werden.

Post by Gerd K.
Programmierung=Codierung wird immer "unwichtiger" bei der Erzeugung
qualitativ hochwertiger Software mittels Methoden und Werkzeugen
des Software Engineerings.

Ich nehme das mal als dein Fazit aus dem Dagstuhl Manifest (das ja
eigentlich ein ganz anderes Thema behandelt*, als das um das es hier geht,
aber es scheint ja offenbar ein dir sehr am Herzen liegendes Dokument
darzustellen, so oft wie du es hier in die Diskussionen einstreust; steckt
da gar die Hoffnung auf eine lang ersehnte quasi-offizielle Bestätigung
für die hochgetragene Nase dahinter?).

Wenn du einen Konstrukteur einstellst, würdest du dann nicht erwarten,
dass er z.B. die Formel für das Volumen eines Fasses mal schnell im Kopf
wenigstens näherungsweise bestimmen kann? Brauchen tut er das sicher
nicht, wenn er es braucht spuckt ihm sein CAD System die korrekt
berechneten Werte aus. Oder wie ist es mit Grundlagen der Intergral- und
Differentialrechnung? Braucht er die nicht mehr, nur weil er in seinem Job
sowieso nur noch die hübschen bunten Bildchen der finiten
Elementesimulation auswerten muss?

Aber das ist gar nicht das Problem mit deinem Fazit. Das Problem ist, dein
Fazit ist ein Trugschluss.

"Metallbearbeitung wird immer unwichtiger bei der Erzeugung qualitativ
hochwertiger Kochtöpfe mittels Methoden und Werkzeugen der
metallverarbeitenden Industrie."

Hä? Klingt blöde nicht wahr? Aber der gleiche Satz in Bezug auf
Softwareentwicklung soll plötzlich korrekt sein?

Klar, je weiter fortgeschritten deine Methoden und Werkzeuge im
Software-Engineering sind, desto seltener wirst du im klassichen
Texteditor arbeiten und Programmcode einhacken. Aber heißt das, dass du
nicht mehr programmierst?

Programmieren in einer Programmiersprache im Texteditor ist nur eine
zugegeben "niedere" Ausprägung des Programmierens. Ebenso wie das bloße
Ausrechnen eine zugegeben "niedere" Ausprägung des "Rechnens" (=
Mathematik-Betreibens) ist.

Bevor ich glaube, dass einer die "höheren Weihen" erhalten hat, muss doch
wohl erlaubt sein, zu fordern, dass er die niederen Grundlagen vorführt.
Also lass es mich wiederholen: Kommt von eurem hohen Ross herunter und
behauptet nicht, Informatiker müssten erst gar nicht programmieren können.
Sie müssen es können, aber sie müssen nicht unbedingt geübt darin sein,
ach sie müssen noch nicht mal eine gebräuchliche Programmiersprache
beherrschen, sie müssen nur zur Not eine neue Sprache definieren können um
das von ihnen geforderte Programm schreiben zu können.

cu

*) Seien wir doch ehrlich: Das Dagstuhl Manifest ist nichts weiter als der
Bettelbrief einer Forschungslobby. Und als solcher noch nicht mal ein
guter, strotzt er doch nur so vor Allgemeinplätzen und unverhohlenen
Geldforderungen.

Gerd K.

2007-03-06 10:25:33 UTC

Hi!

Post by Ralf Ullrich
Aber das ist gar nicht das Problem mit deinem Fazit. Das Problem ist, dein
Fazit ist ein Trugschluss.
"Metallbearbeitung wird immer unwichtiger bei der Erzeugung qualitativ
hochwertiger Kochtöpfe mittels Methoden und Werkzeugen der
metallverarbeitenden Industrie."
Hä? Klingt blöde nicht wahr? Aber der gleiche Satz in Bezug auf
Softwareentwicklung soll plötzlich korrekt sein?

Die Erstellung von Software ist Transformation von Informationen
über verschiedenste Abstraktionsebenen hinweg. Das Codieren ist
dabei nur der letzte Schritt in die Programmiersprache. Dabei hat der
Programmierer spezifiziert durch die Entwurfsdokumente enge
Vorgaben. Dieser letzte Schritt ist natürlich aus Sicht der
lauffähigen Software nicht unwichtig ;-) aber aus Sicht des
ganzen Produktionsprozess gesehen unkreativ, teilweise automatisier-
bar.

Post by Ralf Ullrich
Bevor ich glaube, dass einer die "höheren Weihen" erhalten hat, muss doch
wohl erlaubt sein, zu fordern, dass er die niederen Grundlagen vorführt.

Wir sind uns doch fast einig: Ich halte es für ein Armutszeugnis, wenn
ein Informatiker nach Einarbeitungszeit nicht auch programmieren
=codieren kann.

Post by Ralf Ullrich
Also lass es mich wiederholen: Kommt von eurem hohen Ross herunter und
behauptet nicht, Informatiker müssten erst gar nicht programmieren können.

Nein, so habe ich das auch nie gemeint. Ein Informatiker ist (sollte ;-)
aufgrund seiner grundlagenorientierten Ausbildung in der Lage sein,
in jeder Programmiersprache zu programmieren, wenn er es denn
will.

Thema "hohes Ross". Es hat nichts mit Arroganz zu tun, aufzuzeigen, dass
Informatik weit mehr als Programmieren ist. Zwischen einem Informatiker
und einem Programmierer liegt in der Regel ein Studim an einer
Uni. Aber wo ist das Problem? Für beide Gruppen gibt es Aufgaben.
Was wäre ein Architekt ohne Maurer? Und in einem von einem Architekten
gemauerten Haus möchte ich nicht wohnen, genausowenig wie in einem
von einem Maurer entworfenem Haus *g*

Es gibt gerade bei Programmieren oft eine völlig falsche
Einschätzung von dem Fach Informatik. Die Arroganz liegt nicht
bei uns Informatikern sondern viel mehr bei der Selbstüberschätzung
einiger sogenannter Programmierprofis, die glauben, nur weil man 20.000
Zeilen Code produziert hat, dass Diplom schon gleich erhalten
könne. Scheitern solche im Informatikstudium, dann ist
der Studiengang halt weltfremd, zu theorielastig oder die
Vorlesungen wurden alle von unmotivierten, unfähigen
Professoren gehalten...

Grüße,
Gerd

Ivan Dolvich

2007-03-06 10:43:41 UTC

Post by Gerd K.
Programmierung=Codierung wird immer "unwichtiger" bei der Erzeugung
qualitativ hochwertiger Software mittels Methoden und Werkzeugen
des Software Engineerings.

Codierung mag immer unwichtiger werde, sie wirde aber nie unwichtig
sein! Qualitativ hochwertige Software sollte auch von einem hochwergigen
Code produziert sein. Falls du hierSprichst du von MDA?

Post by Gerd K.
Ein sehr lesenswerte Stellungnahme von führenden Experten und
www.sse.cs.tu-bs.de/publications/Dagstuhl_Manifest_SE.pdf
Ein Fazit: Software Engineering ist so anspruchsvoll und komplex,
dass es nur in einem Diplom- bzw. Masterstudiengang sinnvoll
vermittelt werden kann, nicht in einem FH oder Bachelor-Studium.
Was nicht zuletzt an den notwendigen theoretischen mathematischen
Grundlagen liegt, von denen ein "normaler Programmierer" gar nicht
einmal ahnt, das es sowas gibt.
Ein etwas hinkender Vergleich zum Thema "Informatiker und Programmieren"
Hitzfeld ist ein guter Fußballtrainer obwohl er während eines
Spiels nicht selber die Tore schiesst. ;-)
(Das Hinken resultiert aus der Tatsache, dass er nach
beliebiger Trainingszeit als Fußballspieler nie so gut
sein kann, um in irgendeiner Kreisliga-Mannschaft zu spielen) ;-)
Grüße!
Gerd

Ivan Dolvich

2007-03-06 11:08:02 UTC

Sorry, für den ersten unvollständigen Post, hier nochmal

Post by Gerd K.
Programmierung=Codierung wird immer "unwichtiger" bei der Erzeugung
qualitativ hochwertiger Software mittels Methoden und Werkzeugen
des Software Engineerings.

Codierung mag immer unwichtiger werden, sie wird aber in absehbarer Zeit
nie unwichtig sein! Qualitativ hochwertige Software sollte auch
hochwergigen Code haben. Falls du hier von MDA sprichst, ist das kein
Wundermittel und kein ersatz fürs Codieren:

"As an example, consider behavioral logic. I can't see that drawing
sequence diagrams or activity diagrams is as good, let alone better,
than writing code in a modern language." aus
http://www.martinfowler.com/bliki/ModelDrivenArchitecture.html

Post by Gerd K.
Ein Fazit: Software Engineering ist so anspruchsvoll und komplex,
dass es nur in einem Diplom- bzw. Masterstudiengang sinnvoll
vermittelt werden kann, nicht in einem FH oder Bachelor-Studium.

Das ist eine Aussage die IMHO aus einem Schubladen-Denken ausgeht.

Post by Gerd K.
Was nicht zuletzt an den notwendigen theoretischen mathematischen
Grundlagen liegt, von denen ein "normaler Programmierer" gar nicht
einmal ahnt, das es sowas gibt.

Und sind die "theoretischen mathematischen Grundlagen" wirklich so
wichtig bei der Softwareentwicklung? Wie oft hast du denn die höhere
Mathematik in deiner Softwareentwicklung wirklich gebraucht? Und wie oft
hast du über Architektur, Struktur etc. nachgedacht? Für mich hat
Softwareentwicklung viel mehr mit Bauen und Malen als mit Analysis und
Differenzialgleichungen zu tun. Die wenigen mathematischen Dinge die ich
je gebraucht habe sind Graphentheorie, Mengenlehre und Logik, etwas
Kombinatorik und Geometrie.

Post by Gerd K.
Hitzfeld ist ein guter Fußballtrainer obwohl er während eines
Spiels nicht selber die Tore schiesst. ;-)

OK, dazu eine philosophische Frage - wer hat zum Sieg mehr beigebracht -
der Trainer, oder die Spieler?

Viele Grüße, Ivan

Gerd K.

2007-03-06 11:30:13 UTC

Hi!

Post by Ivan Dolvich
Codierung mag immer unwichtiger werden, sie wird aber in absehbarer Zeit
nie unwichtig sein! Qualitativ hochwertige Software sollte auch
hochwergigen Code haben. Falls du hier von MDA sprichst, ist das kein
"As an example, consider behavioral logic. I can't see that drawing
sequence diagrams or activity diagrams is as good, let alone better,
than writing code in a modern language." aus
http://www.martinfowler.com/bliki/ModelDrivenArchitecture.html

100% meine Meinung! In der "klassischen" Form hat MDA einige
Schwächen. Aber es gibt sehr interessante Ansätze,
die die Vorteile der modellbasierten Entwicklung aufgreifen,
ohne diese Schwächen mitzunehmen: Z.B. MOOS von Prof. Winter:
"Methodische objektorientierte Softwareentwicklung. Eine Integration
klassischer und moderner Entwicklungskonzepte", dpunkt-Verlag.

Post by Ivan Dolvich
Und sind die "theoretischen mathematischen Grundlagen" wirklich so
wichtig bei der Softwareentwicklung?

Ja. Denn mit deren Hilfe hat der Informatiker gelernt zu abstrahieren.
Er hat wirkliches systematisches Denken gelernt uvm.

Post by Ivan Dolvich
Wie oft hast du denn die höhere
Mathematik in deiner Softwareentwicklung wirklich gebraucht? Und wie oft
hast du über Architektur, Struktur etc. nachgedacht? Für mich hat
Softwareentwicklung viel mehr mit Bauen und Malen als mit Analysis und
Differenzialgleichungen zu tun. Die wenigen mathematischen Dinge die ich
je gebraucht habe sind Graphentheorie, Mengenlehre und Logik, etwas
Kombinatorik und Geometrie.

Aber die restliche Studiums-Mathematik ist für die oben
angesprochenen Aspekte extrem hilfreich *g*

Post by Gerd K.
Hitzfeld ist ein guter Fußballtrainer obwohl er während eines
Spiels nicht selber die Tore schiesst. ;-)

OK, dazu eine philosophische Frage - wer hat zum Sieg mehr beigebracht -
der Trainer, oder die Spieler?

Beide gleich viel!

Viele Grüße,
Gerd

Daniel Alder

2007-03-08 00:19:24 UTC

Post by Ralf Ullrich

Post by Daniel Alder
Informatik Absolvent != Programmierer

Kfz-Mechanikermeister != Autofahrer

Wohl eher:

Kfz-Mechanikermeister != Formel1-Mechaniker

Programmieren ist die Königsklasse in der Informatik. Jeder muss wissen,
wie man die Befehle tippt, aber wenn ich mich unter meinen
Klassenkameraden umschaue, merke ich, dass die meisten - krass gesagt -
nicht wissen, welche Befehle sie in welcher Reihenfolge zusammenbringen
müssen, damit was sinnvolles rauskommt.
Natürlich gibts Projektarbeiten und ähnliches, aber
"Real-World-Programmieren" lernt man so halt doch nicht. Wenn du einen
Piloten ausschliesslich im Simulator ausbildest, wird er in der Luft
wahrscheinlich auch versagen, wenn er das erste mal 5G spürt...

Marcus Woletz

2007-03-06 12:06:21 UTC

Hallo Leute,

also die Diskussion über die Unterscheidung zwischen Informatiker und
Programmierer stimmt mich doch nachdenklich. Zuerst einmal frage ich
mich zuerst einmal, was denn ein Programmierer, der hier mit einem
Maurer verglichen wurde, denn eigentlich tut? Völlig geistfrei irgend
welchen Code hacken? Wie sehen dann dessen Vorgaben aus, nach denen er
codiert? Und die Informatiker distanzieren sich hier gleichzeitig von
jeder Form praktischen Arbeitens und sehen sich einzig und allein in der
Forschung aufgehoben. Ich behaupte jetzt mal, dass 99% der besetzten
Informatikerstellen nicht den Arbeitsschwerpunkt haben, der hier so
wehement eingefordert wird. Also bleibt den Informatikern halt nichts
anderes übrig, als sich mal die Finger schmutzig zu machen. Dasselbe
Problem haben alle derartigen Fachbereiche, z.B. die Physik und
Mathematik. Ich habe bisher sehr selten erlebt, dass die
Softwareentwicklung, hier als akademisches Betätigungsfeld, völlig
losgelöst agierte von der Implementierung. In beinahe allen Fällen
findet man "Softwaredesigner" und "Programmierer" in einer Person
vereinigt, zumindest in den Firmen. "Echte Forschung" ist wieder ein
anderes Thema.

ciao

Marcus

Stefan Ram

2007-03-06 12:14:14 UTC

Zuerst einmal frage ich mich zuerst einmal, was denn ein
Programmierer, der hier mit einem Maurer verglichen wurde, denn
eigentlich tut? Völlig geistfrei irgend welchen Code hacken?

http://www.bleading-edge.com/Publications/C++Journal/Cpjour2.htm

http://c2.com/xp/TheSourceCodeIsTheDesign.html

Stefan Ram

2007-03-06 12:20:08 UTC

Zuerst einmal frage ich mich zuerst einmal, was denn ein
Programmierer, der hier mit einem Maurer verglichen wurde, denn
eigentlich tut? Völlig geistfrei irgend welchen Code hacken?

»Most current software development processes try to
segregate the different phases of software design into
separate pigeon-holes. The top level design must be
completed and frozen before any code is written. Testing
and debugging are necessary just to weed out the
construction mistakes. In between are the programmers, the
construction workers of the software industry. Many
believe that if we could just get programmers to quit
"hacking" and "build" the designs as given to them (and in
the process, make fewer errors) then software development
might mature into a true engineering discipline. Not
likely to happen as long as the process ignores the
engineering and economic realities.

(...)

The overwhelming problem with software development is that
everything is part of the design process. Coding is
design, testing and debugging are part of design, and what
we typically call software design is still part of design.
Software may be cheap to build, but it is incredibly
expensive to design. Software is so complex that there are
plenty of different design aspects and their resulting
design views. The problem is that all the different
aspects interrelate (just like they do in hardware
engineering). It would be nice if top level designers
could ignore the details of module algorithm design.
Likewise, it would be nice if programmers did not have to
worry about top level design issues when designing the
internal algorithms of a module. Unfortunately, the
aspects of one design layer intrude into the others. The
choice of algorithms for a given module can be as
important to the overall success of the software system as
any of the higher level design aspects. There is no
hierarchy of importance among the different aspects of a
software design. An incorrect design at the lowest module
level can be as fatal as a mistake at the highest level. A
software design must be complete and correct in all its
aspects, or all software builds based on the design will
be erroneous.«

http://www.bleading-edge.com/Publications/C++Journal/Cpjour2.htm

http://c2.com/xp/TheSourceCodeIsTheDesign.html

Supersedes: <codieren-***@ram.dialup.fu-berlin.de>

Stefan Ram

2007-03-06 12:24:57 UTC

Post by Stefan Ram
http://www.bleading-edge.com/Publications/C++Journal/Cpjour2.htm

Oder - noch kürzer als das vorige Zitat:
»
o Programming is a design activity -- a good software
design process recognizes this and does not hesitate to
code when coding makes sense.

o Coding actually makes sense more often than believed.
Often the process of rendering the design in code will
reveal oversights and the need for additional design
effort. The earlier this occurs, the better the design
will be.
«

Gerd K.

2007-03-06 12:39:45 UTC

Hi!

Post by Stefan Ram
http://www.bleading-edge.com/Publications/C++Journal/Cpjour2.htm

Das Paper ist von 1992!
In den letzten 15 Jahren hat das Fach Software Engineering einige
Fortschritte gemacht. *g*

Für jede Aktivität der Softwareerstellung gibt es angemessene, das
entsprechende Abstraktionsniveau und die Aktivitätsziele
berücksichtigende Beschreibungsmechanismen (und Tools).
Die Verwendung einer Programmiersprache ist eigentlich nur zur
Beschreibung des Codes sinnvoll.

Wie willst Du z.B. funktionale Anforderungen mit einer Programmier-
sprache formulieren? Und zwar so formulieren, dass der Kunde
diese validieren kann? Nur ein Beispiel...
Während beim Requirements Engineering die Problemadäquatheit
und Verständlichkeit im Vordergrund stehen muss, ist es
beim Implementieren die Präzision und syntaktische Genauigkeit.
Da reicht eine einzige Beschreibungstechnik einfach nicht aus.

Aber das hatten wir ja an dieser Stelle schon diskutiert.

Viele Grüße,
Gerd

Marcus Woletz

2007-03-06 16:06:23 UTC

Hallo Gerd,

Gerd K. schrieb:

[einige interessante Ausführungen]

Post by Ivan Dolvich
Viele Grüße,
Gerd

was Du schreibst, mag ja alles richtig sein. Ich sehe allerdings, wie
gerade Großprojekte, häufig von vermeintlich führenden Firmen in diesem
Bereich, katastrophal scheitern. Vor allem sind mir da diverse Projekte
bei Arbeitsagentur, Polizei und Bundeswehr im Gedächtnis. Ach ja, und
TollCollect nicht zu vergessen ;-)

Ich denke, es ist gefährlich, sich blind auf irgendwelche Tools zu
verlassen. Wenn ich die Softwareentwicklung auf den Bereich des
Sondermaschinenbaus projektiere, sind folgende Punkte ausschlaggebend
für das Gelingen oder Scheitern eines Projektes:

1.) Zusammenarbeit zwischen Kunden und Lieferanten
2.) Fähigkeiten der Konstrukteure
3.) Qualität der Zulieferteile
4.) Fähigkeiten der Mechaniker beim Zusammenbau
5.) Qualität der Werkzeuge und des Materials

Obwohl man die Bereiche doch sehr klar trennen kann, muss immer ein
erfolgreicher Austausch zwischen Konstrukteuren und Mechanikern
stattfinden. Besonders wichtig ist allerdings das Klima zwischen Kunde
und Lieferant. Funktioniert hier die Kommunikation nicht, ist das
Projekt bereits gefährdet.

ciao

Marcus

Ingo R. Homann

2007-03-07 08:39:43 UTC

Hi,

Post by Marcus Woletz
was Du schreibst, mag ja alles richtig sein. Ich sehe allerdings, wie
gerade Großprojekte, häufig von vermeintlich führenden Firmen in diesem
Bereich, katastrophal scheitern. Vor allem sind mir da diverse Projekte
bei Arbeitsagentur, Polizei und Bundeswehr im Gedächtnis. Ach ja, und
TollCollect nicht zu vergessen ;-)

Phfft. 9 von 10 Produkten der Industrie scheitern am Markt. Warum sollte
das in der Softwareentwicklung anders sein? Im übrigen ist z.B. Toll
Collect gerade *kein* gutes Beispiel für ein "katastrophal gescheitertes
Projekt". Es hat lange Verzögerungen gegeben, OK. Es ist sicher kein
Vorzeige-Projekt was die Start-Schwierigkeiten anbelangt, OK. Aber es
ist eben auch ein Groß-Projekt mit etlichen beteiligten Konzernen und
Komponenten. Und - es läuft mittlerweile. Wie gesagt: Vielleicht kein
Vorzeige-Projekt, aber weit davon entfernt, "katastrophal gescheitert"
zu sein. Bei der Software für die Arbeitsagenturen z.B. ist wohl ein
Haupt-Problem, dass sich die Anforderungen schneller ändern, als
irgendwer programmieren kann. Das kann man auch nur bedingt der
Software-Industrie anlasten. Wie es mit den anderen Projekten, die Du
nennst, aussieht, kann ich nur schwer beurteilen.

Post by Marcus Woletz
Besonders wichtig ist allerdings das Klima zwischen Kunde
und Lieferant.

Full ACK!

Ciao,
Ingo

Marcus Woletz

2007-03-07 16:23:32 UTC

Hallo Ingo,

Ingo R. Homann schrieb:
[...]

Post by Ingo R. Homann
Phfft. 9 von 10 Produkten der Industrie scheitern am Markt. Warum sollte

Evtl. habe ich andere Zielgruppen im Auge. Ich entwickle ausschließlich
Individualsoftware, unter anderem für die Automobilzulieferer. Das
heißt, ist der Auftrag erteilt, dann geht es darum, das Projekt für den
Kunden optimal zu realisieren. es gibt da keinen "Markt", wie bei
Standardsoftware. Oder meinst Du mit "am Markt" etwas völlig anderes?

Post by Ingo R. Homann
das in der Softwareentwicklung anders sein? Im übrigen ist z.B. Toll
Collect gerade *kein* gutes Beispiel für ein "katastrophal gescheitertes
Projekt". Es hat lange Verzögerungen gegeben, OK. Es ist sicher kein

Ich sags mal so: hätte nicht der Bund finanziert, wäre das Projekt
vermutlich gescheitert.

[...]

Post by Ingo R. Homann
zu sein. Bei der Software für die Arbeitsagenturen z.B. ist wohl ein
Haupt-Problem, dass sich die Anforderungen schneller ändern, als
irgendwer programmieren kann. Das kann man auch nur bedingt der

Das halte ich, mit Verlaub, für ein Märchen der beteiligten Firmen. Ich
meine, bei einem Projekt diesen Ausmaßes sollte doch ein vernünftiger
Anforderungskatalog vorhanden sein. Wenn dann später so umfangreich
nachgebessert werden muss, dann haben beide versagt: Der Kunde, weil er
den Lieferanten mit unzureichenden Anforderungen ins Rennen geschickt
hat (hier haben also die Planer des Kunden versagt), und der Lieferant,
weil Änderungen der Anforderungen nur mit massivem Aufwand in die
Software eingepflegt werden können. Hier haben dann zumindest ebenso die
Systemdesigner des Lieferanten versagt.

[...]

Post by Ingo R. Homann
Ciao,
Ingo

ciao

Marcus

Thorsten J. Krause

2007-03-07 23:01:57 UTC

Hallo,

Post by Marcus Woletz
[...]

Post by Ingo R. Homann
Phfft. 9 von 10 Produkten der Industrie scheitern am Markt. Warum sollte

Keine Ahnung worauf Ingo jetzt eigentlich hinaus wollte, aber gerade erst
vor einigen Tagen habe ich einen Artikel gelesen, der folgende These
aufstellt:

| Weare practically the only industry where completion and success are
| synonymous. If the foundation of a one-year-old home is crumbling and its
| roof is plagued with leaks, would anybody actually call that a success?
| [...] Of course not! So why are the products we create – complex
| information systems that should last at least fifteen years – be held to a
| different standard?
<http://worsethanfailure.com/Articles/What_Could_Possibly_Be_Worse_Than_Failure_0x3f_.aspx>

-Thorsten

Ingo R. Homann

2007-03-08 07:54:52 UTC

Hi Marcus,

Post by Marcus Woletz
Evtl. habe ich andere Zielgruppen im Auge. Ich entwickle ausschließlich
Individualsoftware, unter anderem für die Automobilzulieferer. Das
heißt, ist der Auftrag erteilt, dann geht es darum, das Projekt für den
Kunden optimal zu realisieren. es gibt da keinen "Markt", wie bei
Standardsoftware. Oder meinst Du mit "am Markt" etwas völlig anderes?

Nein, bei Individualsoftware ist es natürlich was anderes, da hast Du Recht.

Ich sags mal so: hätte nicht der Bund finanziert, wäre das Projekt
vermutlich gescheitert.

Inwiefern?

In gewisser Weise hast Du natürlich recht. Aber ich habe den Eindruck,
dir ist nicht ganz klar, wie die Behörden ticken: Wenn die Politik oder
zur Not das Verfassungsgericht entscheidet, dass das Arbeitslosengeld
jetzt doch anders berechnet werden soll, dann denken sie nicht im
entferntesten daran, inwieweit die gerade angeschaffte Software das neue
Berechnungsverfahren abdeckt, oder inwieweit, in welchem Umfang
entsprechende Änderungen vertraglich festgelegt sind!

Mal ein Beispiel aus der Praxis: Für Kindergärten ist ein entsprechendes
Entgeld zu zahlen. Dieses ist natürlich gestaffelt nach Einkommen. Die
Politik kommt auf die Idee, nicht nur die Beitragshöhe für die einzelnen
Stufen, sondern auch die Staffelung der Stufen selbst geringfügig zu
modifizieren (konkret: die unterste Einkommensstufe geht jetzt nicht
mehr bis 12.000,-, sondern bis 15.000,- Euro im Jahr). In dem Fall war
sogar ganz einfach, die Software entsprechend anzupassen. Allerdings:
"Aus Datenschutzrechtlichen Gründen" sollten in das Verfahren
ursprünglich nicht die Einkommen in Euro eingegeben werden, sondern nur
die Einkommens*stufe*.

Kurz: Für eine ziemlich winzige Gesetzesänderung musste bei einem nicht
zu vernachlässigenden Teil aller Einzelfälle das Einkommen neu
nachgewiesen und erfasst werden, was ein nicht unerheblicher manueller
Aufwand war, der eigentlich nicht nötig gewesen wäre, hätten sich die
Politiker von vorneherein mehr Gedanken über die Umsetzung gemacht.

Ciao,
Ingo

Uwe Plonus

2007-03-08 07:57:03 UTC

Post by Marcus Woletz
Das halte ich, mit Verlaub, für ein Märchen der beteiligten Firmen. Ich
meine, bei einem Projekt diesen Ausmaßes sollte doch ein vernünftiger
Anforderungskatalog vorhanden sein. Wenn dann später so umfangreich
nachgebessert werden muss, dann haben beide versagt: Der Kunde, weil er
den Lieferanten mit unzureichenden Anforderungen ins Rennen geschickt
hat (hier haben also die Planer des Kunden versagt), und der Lieferant,
weil Änderungen der Anforderungen nur mit massivem Aufwand in die
Software eingepflegt werden können. Hier haben dann zumindest ebenso die
Systemdesigner des Lieferanten versagt.

Wenn ich solche Aussagen lese, dann muss ich das Gefühl bekommen, dass
der Schreiber keine Ahnung von der Realität hat...

Leider ist es so bei der Entwicklung von Individualsoftware, dass der
Kunde beileibe nicht weiß, was er will. Als Designer/Architekt musst Du
dem Kunden häufig erstmal sagen, was er wirklich möchte.

Ich habe bis heute noch keinen Anforderungskatalog gesehen, der dazu
geeignet wäre ein fertiges Produkt danach zu bemessen.

Wenn ich Software strikt nach Anforderungskatalog umsetzen würde, so
wäre das Produkt anschließend unbrauchbar. Selbst wenn ich alle
impliziten Anforderungen berücksichtige. Daher ist es wichtig, dass auch
der Architekt sich fachlich in der Domäne des Kunden auskennt und ihm
vorgibt, was er möchte. Das hört sich jetzt extrem an, ist aber leider so.

Uwe

Gerd K.

2007-03-08 08:55:37 UTC

Hi!

Post by Uwe Plonus
Leider ist es so bei der Entwicklung von Individualsoftware, dass der
Kunde beileibe nicht weiß, was er will. Als Designer/Architekt musst Du
dem Kunden häufig erstmal sagen, was er wirklich möchte.
Ich habe bis heute noch keinen Anforderungskatalog gesehen, der dazu
geeignet wäre ein fertiges Produkt danach zu bemessen.

Es gibt nichts Wichtigeres bei der Erstellung von qualitativ
hochwertiger Software als die Anforderungsermittlung! Eine
ganze Teildisziplin der Informatik beschäftigt sich damit:
Requirements Engineering!

Wenn Du nicht weisst, was der Kunde überhaupt will, wie willst
Du denn Software für Ihn erstellen? Der RE-Experte kennt Mittel
und Wege die Anforderungen mit dem Kunden zu erarbeiten.
Das ist anspruchsvoll und sehr zeitaufwendig, aber machbar!

Ohne (stabile) Anforderungen hast Du nicht nur ein schweren Start
bei der Erstellung der Software ;-), Du hast auch keinerlei
Vertragsgrundlage. Wer soll denn ohne einen Anforderungskatalog
entscheiden, ob die Software "fertig" ist? (Stichwort Lastenheft
was später zum Pflichtenheft werden muss)

Die Kunst und das Kreative bei der Anforderungsermittlung
ist es, einerseits die Anforderungen so abstrakt zu formulieren,
dass der Kunde sie versteht, andererseits so präzise zu sein, dass
die Anforderungen den Ausgangspunkt zur Erzeugung der Software
bilden. Hier gibt es interessante Ansätze: Anwendungsfallmodellierung,
Domänenklassenmodellierug, Verhaltensmodellierung, Ober-
flächenprototypen zum Validieren der Anforderungen uvw.

Post by Uwe Plonus
Wenn ich Software strikt nach Anforderungskatalog umsetzen würde, so
wäre das Produkt anschließend unbrauchbar. Selbst wenn ich alle
impliziten Anforderungen berücksichtige.

Man muss dafür sorgen, dass der Anforderungskatalog so vollständig
und genau wie möglich ist. (s.o.)

Post by Uwe Plonus
Daher ist es wichtig, dass auch
der Architekt sich fachlich in der Domäne des Kunden auskennt und ihm
vorgibt, was er möchte. Das hört sich jetzt extrem an, ist aber leider so.

Das wird der Architekt nicht können, dafür gibt es mittlerweile
eigene Experten (s.o.)

Der Hauptgrund, warum Ansätze wie XP oder andere agile Methode
so gefährlich sind und oft zu katastrophalen Ergebnissen führen ist
u.a. die fehlende Anforderungsermittlung. Das ist nicht nur meine
meinung, sondern auch solche Gurus wie Boehm teilen sie.

Es muss Gründe haben, warum wir in der Lage sind, Menschen
zum Mond zu schicken, genauer: lebend zum Mond zu schicken und sie
lebend wieder zurück holen können (was das Problem ungleich komplexer
macht ;-)), warum wir in verschiedensten Bereichen enorme
technische Fortschritte machen aber bis heute nicht in der Lage
sind, gute Software zu erzeugen. Die Softwarekrise existiert
immer noch und, volkswirtschaftlich gesehen, ist sie so groß wie
nie zu vor!

Zum einen ist der Vorgang der Erstellung von Software extrem
komplex (viel komplexer und anspruchsvoller, als sich das manch
Firmenchef oder manch "Programmier" vorstellt), zum anderen
stösst man dabei schnell an Grenzen des theoretisch Möglichen
(z.B. Nachweis der Terminierung eines Programms i.A. nicht
möglich. Das Finden von Invarianten nicht berechenbar uvm.)
Aber das Bild der Komplexität muss sich in "der Industrie" erst noch
durchsetzen!
Wer weiss denn von der Personalchefs etwas von RE-Experten
oder gar von der Notwendigkeit eines Software Engineerings?
Wer ahnt denn von diesen Leuten, dass zwischen einem Uni-
Informatiker und einem FH-Informatiker Welten liegen?
Wer ahnt denn von diesen, dass ein Informatiker kein
Programmierer ist usvm.

Eine sehr lesenwerte Übersicht zum Thema findet man hier:
"Facts und Fallacies of Software Engineering" Robert L. Glass,
Addison-Wesley

Grüße!
Gerd

Jochen Theodorou

2007-03-08 09:50:20 UTC

Post by Gerd K.
Hi!

Es gibt nichts Wichtigeres bei der Erstellung von qualitativ
hochwertiger Software als die Anforderungsermittlung! Eine
Requirements Engineering!
Wenn Du nicht weisst, was der Kunde überhaupt will, wie willst
Du denn Software für Ihn erstellen? Der RE-Experte kennt Mittel
und Wege die Anforderungen mit dem Kunden zu erarbeiten.
Das ist anspruchsvoll und sehr zeitaufwendig, aber machbar!

Der sit aber machtlos wenn dem Kunden eine Anforderung plötzlich nicht
mehr gefällt. Was machst du wenn der Kunde plötzlich nach 5% der
Entwicklungszeit kommt und meint dass das so nicht funktioniert? Wobei
das ja noch ein günstiger Fall wäre.. in der Regel passiert das kurz vor
Schluss.

Post by Gerd K.
Ohne (stabile) Anforderungen hast Du nicht nur ein schweren Start
bei der Erstellung der Software ;-),

die sind fast nie stabil im Bereich der Individualsoftware.

Post by Gerd K.
Du hast auch keinerlei
Vertragsgrundlage. Wer soll denn ohne einen Anforderungskatalog
entscheiden, ob die Software "fertig" ist? (Stichwort Lastenheft
was später zum Pflichtenheft werden muss)

tja, vielleicht muss man das einfach anders machen.

[...]

Post by Gerd K.

Post by Uwe Plonus
Wenn ich Software strikt nach Anforderungskatalog umsetzen würde, so
wäre das Produkt anschließend unbrauchbar. Selbst wenn ich alle
impliziten Anforderungen berücksichtige.

Man muss dafür sorgen, dass der Anforderungskatalog so vollständig
und genau wie möglich ist. (s.o.)

ist dir das in der Praxis schon mal vorgekommen?

Post by Gerd K.

Das wird der Architekt nicht können, dafür gibt es mittlerweile
eigene Experten (s.o.)

die dann selber Architekten sind und so bezeichnet werden und keinen
eigenen Namen bekommen. Ist ja kleine geschützte Berufsbezeichnung.

Post by Gerd K.
Der Hauptgrund, warum Ansätze wie XP oder andere agile Methode
so gefährlich sind und oft zu katastrophalen Ergebnissen führen ist
u.a. die fehlende Anforderungsermittlung. Das ist nicht nur meine
meinung, sondern auch solche Gurus wie Boehm teilen sie.

ähh... ich nehme an du meinst Barry Boehm, der sich sehr mit der
Risikoanalyse befasst hat. Sagt der wirklich "gefährlich" und
"katastrophal"? Das würde mich doch sehr wundern.

Ausserdem bedeutet agile Programmierung nicht, dass es keine
Anforderunsermittlung gibt. Sie ist lediglich nicht so genau und wird in
Zusammenarbeit mit dem Kunden äwrend der Entwicklung ausgearbeitet. Aber
warum sollte man bei der agilen Programmierung keine Protoypen von
Oberflächen erstellen? Dann gibt es ja auch die "user stories" und
andere Dinge.

[...]

Post by Gerd K.
Zum einen ist der Vorgang der Erstellung von Software extrem
komplex (viel komplexer und anspruchsvoller, als sich das manch
Firmenchef oder manch "Programmier" vorstellt),

ja, solange sie es nicht einmal selbst gemacht haben.

Post by Gerd K.
zum anderen
stösst man dabei schnell an Grenzen des theoretisch Möglichen
(z.B. Nachweis der Terminierung eines Programms i.A. nicht
möglich. Das Finden von Invarianten nicht berechenbar uvm.)

uns ist das auch notwendig?

Post by Gerd K.
Aber das Bild der Komplexität muss sich in "der Industrie" erst noch
durchsetzen!

Komplexität hat die eigenschaft, dass man sich kein Bild von ihr machen
kann, weil sie so komplex ist ;)

Post by Gerd K.
Wer weiss denn von der Personalchefs etwas von RE-Experten
oder gar von der Notwendigkeit eines Software Engineerings?

von der Notwendigkeit der Kenntnisse angepasst auf die Lage der Firma?
Viele.

Post by Gerd K.
Wer ahnt denn von diesen Leuten, dass zwischen einem Uni-
Informatiker und einem FH-Informatiker Welten liegen?
Wer ahnt denn von diesen, dass ein Informatiker kein
Programmierer ist usvm.

wenn der Grundsatz gilt, dass man einen Uni-Informatiker erst 1 Jahr
einarbeiten muss (und das habe ich oft gehört), dann ahnen das schon
sehr viele.

Gruss theo

--
Jochen "blackdrag" Theodorou
Groovy Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/

Wolfgang Rostek

2007-03-08 10:52:17 UTC

Stimme Uwe und Jochen voll zu.

Aus meiner Erfahrung sind die Anforderungen zum Zeitpunkt des
Vertragsabschlusses zumindest nicht dass, was der Anwender
wirklich haben will. Oft eher eine nicht abgestimmte 'Sammlung'
von Wünschen. Im Lauf der Umsetzung muß man im gegenseitigen
Interesse oft einiges überarbeiten/korrigieren.

Das Problem mit der Abnahme gegenüber den Dokumenten zu
Vertragsabschluss haben wohl die meisten.

Zudem hat der Kunde oft auch das Problem zu sehr in eingefahrenen
Bahnen zu denken, was einer guten Lösung entgegensteht. Ohne
Hilfe von außen kann es dies nicht besser.

Post by Jochen Theodorou
Komplexität hat die eigenschaft, dass man sich kein Bild von ihr machen
kann, weil sie so komplex ist ;)

Ein schöner Spruch. Wenn ich aber nochmal darüber nachdenke, kann
er eigentlich nicht richtig sein. Wenn ich mir kein Bild machen kann,
kann ich es auch nicht realisieren, oder?

Gruß
Wolfgang R.

Jochen Theodorou

2007-03-08 11:16:48 UTC

Wolfgang Rostek schrieb:
[...]

Post by Wolfgang Rostek

Post by Jochen Theodorou
Komplexität hat die eigenschaft, dass man sich kein Bild von ihr machen
kann, weil sie so komplex ist ;)

Ein schöner Spruch. Wenn ich aber nochmal darüber nachdenke, kann
er eigentlich nicht richtig sein. Wenn ich mir kein Bild machen kann,
kann ich es auch nicht realisieren, oder?

Hattest du noch nie den Effekt dass du ein Problem gelöst hast ohne zu
wissen warum eigentlich? Oder das du ein Problem nebenbei gelöst hast
von dem du garnicht wusstest das es existiert?

Gruss theo

--
Jochen "blackdrag" Theodorou
Groovy Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/

Florian Weimer

2007-03-08 08:00:00 UTC

Das halte ich, mit Verlaub, für ein Märchen der beteiligten Firmen. Ich
meine, bei einem Projekt diesen Ausmaßes sollte doch ein vernünftiger
Anforderungskatalog vorhanden sein.

Der Anforderungskatalog ist völlig schnuppe, wenn der Gesetzgeber die
Rahmenbedingungen ändert. Natürlich kann man das Projekt vertragsgemäß
durchziehen, aber dann ist die Software in Teilen unbrauchbar (oder
völlig, wenn es zentrale Änderungen gab).

Daniel Urban

2007-03-07 20:15:55 UTC

"Marcus Woletz"

Post by Marcus Woletz
Ich behaupte jetzt mal, dass 99% der besetzten
Informatikerstellen nicht den Arbeitsschwerpunkt haben, der hier so
wehement eingefordert wird. Also bleibt den Informatikern halt nichts
anderes übrig, als sich mal die Finger schmutzig zu machen.

Ich weiß nicht, in welchen Firmen Du so gearbeitet hast, aber meine
Erfahrung ist da anders. Von 100 Personen haben ca. 90 eine
akademische Ausbildung. Wenn man Management, Fachbezogene,
Systemadministration, Verwaltung, Projektleiter usw. abzieht, bleiben
vielleicht 20-30 Entwickler übrig. Von denen sind in der Regel nicht
alle Informatiker, sondern auch Mathematiker, Physiker o.ä.

Es ist also eher die Minderheit, die entwickelt und meist auch nur
die ersten Jahre. Die wenigsten Informatiker entwickeln nach 10
Jahren selber noch Programme.

Gruß,

Daniel

Peter Katzmann

2007-03-07 20:18:04 UTC

Wow,
was müssen wir für einen Wasserkopf inzwischen haben.
Wenn das stimmt was du sagts spricht hier wieder voll das Peter Prinziep
durch.
Du wirst solange befördert bis du an die Stelle deiner größten
Inkompetenz kommst :)

peter

Post by Daniel Urban
Es ist also eher die Minderheit, die entwickelt und meist auch nur
die ersten Jahre. Die wenigsten Informatiker entwickeln nach 10
Jahren selber noch Programme.

Stefan Ram

2007-03-07 22:20:46 UTC

die Mehrzahl aller Informatik Absolventen kann nicht programmieren

... und nicht schreiben?

Es muß natürlich »Informatik-Absolventen« oder
»Informatikabsolventen« heißen.

»I've found that some of the best developers of all are
English majors. They'll often graduate with no programming
experience at all, and certainly without a clue about the
difference between DRAM and EPROM.

But they can write. That's the art of conveying
information concisely and clearly. Software development
and writing are both the art of knowing what you're going
to do, and then lucidly expressing your ideas.«

http://praisecurseandrecurse.blogspot.com/2007/03/english-majors-as-programmers.html

Ich zitiere das, weil es auch meiner Meinung nahekommt:

1. Ich entdecke immer mehr allgemeine linguistische
Strukturen, die es sowohl in der natürlichen Sprache als auch
den meinsten Programmiersprachen gibt (nämlich Verbal- oder
Nominalphrasen mit Kernen und Satelliten).

2. »Gute Geschichtenerzähler unter Kindern im Vorschulalter
sind später auch besonders gut in Mathematik. Das zeigt eine
Studie kanadischer Forscher.«

http://www.purl.org/stefan_ram/pub/lernen-lernen

3. Man merkt es auch hier: Diejenigen, welche grundsätzliche
Schwierigkeiten haben, bestimmte Verfahren in Java zu
formulieren, und dann hier danach fragen, haben oft auch
Schwierigkeiten damit, hier in deutscher Sprache zu erklären,
was sie eigentlich wollen.

Vielleicht ist es aber auch so, wie mein Lateinlehrer sagte:
»Man muß /einmal/ richtig Denken lernen.« - und dann wäre es
egal, ob dazu ein Studium der Mathematik oder des Englischen
dient. Vielleicht geht es sogar mit einem Informatikstudium!

Frank Buss

2007-03-07 23:18:36 UTC