Lektuere zum o.g. Thema

[Lude]

Hi,

mich interessiert, wie man richtig programmiert, bzw. entwickelt. Was man machen kann, habe ich zu Genuege erfahren. - Benoetige aber etwas wirklich Brauchbares. Lektueretipps willkommen; idealerweise in Deutsch, soll naemlich im Bettchen vor dem Einschlafen gelesen werden.

Gruss,
Lude

[Reiner]

Hi,

mich interessiert, wie man richtig programmiert, bzw. entwickelt. Was man machen kann, habe ich zu Genuege erfahren. - Benoetige aber etwas wirklich Brauchbares. Lektueretipps willkommen; idealerweise in Deutsch, soll naemlich im Bettchen vor dem Einschlafen gelesen werden.

zu welchem Thema genau?
Und welche Aufgabe soll primär erfüllt werden: daß Du besser schlafen kannst oder willst Du was lernen?

Gruß
Reiner

[Lude]

Hallo, Reiner,

mich interessiert, wie man richtig programmiert, bzw. entwickelt. Was man machen kann, habe ich zu Genuege erfahren. - Benoetige aber etwas wirklich Brauchbares. Lektueretipps willkommen; idealerweise in Deutsch, soll naemlich im Bettchen vor dem Einschlafen gelesen werden.

zu welchem Thema genau?
Und welche Aufgabe soll primär erfüllt werden: daß Du besser schlafen kannst oder willst Du was lernen?

benoetige etwas Allgemeines. Lernen will ich natuerlich nichts mehr - es geht mir nur um Ideologie. Darf auch unterhaltsam sein, muss aber lesbar und werthaltig sein. (moeglicher Titel: 'Wie ich mit QDOS und Windows den Schotter gemacht habe und warum' - Autor B.Gates.)

Gruss,
Lude

[werndt]

N'abend Lude,

zwei Bücher, die ich zwar nur auf Englisch kenne, kann ich Dir empfehlen:

'Computer Sience & Perl Programming'
Edited by Jon Orwant, O'Reilly, ISBN 0-596-00310-2

'Python Cookbook'
Edited by Alex Martelli, David Ascher, O'Reilly, ISBN 0-596-00167-3

Wenn man sich erst einmal eingelesen hat, eignen die sich sehr gut zum
Schmökern.

Sie sind zwar insofern spezifisch, als eben eine Sprache vorausgesetzt wird,
allerdings werden eine ganze Reihe verschiedener Fragestellungen behandelt.

Und wenn's ein wenig ungemütlich werden darf, schaust Du vielleicht mal
in Donald E. Knuths 'The Art of Computer Programming'.

gruß

werndt

[Lude]

Hi,

danke fuer den Tipp. - Habe das erste ("Best of Perl Journal") und den Dreivolumer von Knuth bestellt. - Das erste wird mich hoffentlich etwas aufheitern, wenn das zweite grausam ungemuetlich zu werden droht.

Gruss,
Lude

[Linksetzer]

http://aktuell.de.selfhtml.org/links/programmiertechnik.htm

[Michael Schröpl]

Hi Lude,

mich interessiert, wie man richtig programmiert, bzw. entwickelt. Was man machen kann, habe ich zu Genuege erfahren. - Benoetige aber etwas wirklich Brauchbares. Lektueretipps willkommen; idealerweise in Deutsch, soll naemlich im Bettchen vor dem Einschlafen gelesen werden.

hm ... klingt so, als würde "Software Engineering" der Google-Suchbegriff sein, der Dich weiter bringen könnte. (Obwohl er englisch ist - ich kenne keine deutsche Übersetzung dafür.)

Ansonsten: Wissen über den Umgang mit großen Programmier-Projekten bekommt man, indem man welche macht. Es gibt einfach Grenzen des Lernens für etwas, das zu einem gewissen Teil eine "handwerkliche" Fähigkeit ist.

Du kannst Dir beispielsweise Wissen über objektorientierte Entwurfsmethoden anlesen - aber einem Projekt anzusehen, welche Herangehensweise in diesem Falle die richtige ist, das erfordert viel Übung und Erfahrung.

Viele Grüße
      Michael
(der erst letzte Woche die Idee, ein Modulsystem algorithmisch "anzuordnen", in die Tonne treten und danach mit einem objektorientierten Ansatz desselben Problems zu einem wunderbaren Erfolgsergebnis gelangen durfte - dabei war das eigentlich eher eine Entscheidung aus der Verzweiflung heraus ...)

[Lude]

Hallo, Michael,

mich interessiert, wie man richtig programmiert, bzw. entwickelt. Was man machen kann, habe ich zu Genuege erfahren. - Benoetige aber etwas wirklich Brauchbares. Lektueretipps willkommen; idealerweise in Deutsch, soll naemlich im Bettchen vor dem Einschlafen gelesen werden.

hm ... klingt so, als würde "Software Engineering" der Google-Suchbegriff sein, der Dich weiter bringen könnte. (Obwohl er englisch ist - ich kenne keine deutsche Übersetzung dafür.)

richtig.

Ansonsten: Wissen über den Umgang mit großen Programmier-Projekten bekommt man, indem man welche macht. Es gibt einfach Grenzen des Lernens für etwas, das zu einem gewissen Teil eine "handwerkliche" Fähigkeit ist.

Erfahrung ist ja da.

Du kannst Dir beispielsweise Wissen über objektorientierte Entwurfsmethoden anlesen - aber einem Projekt anzusehen, welche Herangehensweise in diesem Falle die richtige ist, das erfordert viel Übung und Erfahrung.

Leider.

Viele Grüße
      Michael
(der erst letzte Woche die Idee, ein Modulsystem algorithmisch "anzuordnen", in die Tonne treten und danach mit einem objektorientierten Ansatz desselben Problems zu einem wunderbaren Erfolgsergebnis gelangen durfte - dabei war das eigentlich eher eine Entscheidung aus der Verzweiflung heraus ...)

Das wuerde meine(?) Theorie der "Programmier-Spielstaerke" bestaetigen.

Dennoch: Was ich anforderte war eine gute Bettlektuere, idealerweise in Deutscher Sprache, die zum Thema 'Software-Engineering" Werthaltiges liefert. Darf durchaus auch etwas ins Philosophische gehen. - Vorschlaege duerfen weiterhin gemacht werden.

Gruss,
Lude

[Klaus Mock]

Hallo,

Dennoch: Was ich anforderte war eine gute Bettlektuere, idealerweise in Deutscher Sprache, die zum Thema 'Software-Engineering" Werthaltiges liefert. Darf durchaus auch etwas ins Philosophische gehen. - Vorschlaege duerfen weiterhin gemacht werden.

Vielleicht ineressiert dich ja so etwas wie 'Refactoring' von Martin Fowler (bzw. einige andere Bücher  rund ums Extreme Programming). Das angesprochen Buch finde ich einerseits auch für Nicht-Extremisten wertvoll, andererseits ist es recht unterhaltsam zu lesen.
Imho sind theoretische Bücher aus dem amerikanischen Raum allein wegen ihres Unterhaltungswertes den oft trockenen Abhandlungen aus deutschen Landen vorzuziehen. ich habe mit der zweiten Gruppe immer wieder das Problem, nicht im Stehen einzuschlafen, so lähmend sind die meist.

Grüße
  Klaus

[Lude]

Hi,

Dennoch: Was ich anforderte war eine gute Bettlektuere, idealerweise in Deutscher Sprache, die zum Thema 'Software-Engineering" Werthaltiges liefert. Darf durchaus auch etwas ins Philosophische gehen. - Vorschlaege duerfen weiterhin gemacht werden.

Vielleicht ineressiert dich ja so etwas wie 'Refactoring' von Martin Fowler (bzw. einige andere Bücher  rund ums Extreme Programming). Das angesprochen Buch finde ich einerseits auch für Nicht-Extremisten wertvoll, andererseits ist es recht unterhaltsam zu lesen.

ja, wir hatten hier (in der Firma) auch mal zwei Extremisten. Da habe ich das Buch gesehen (bin mir allerdings nicht 100% sicher). Da geht es darum, wie man die Software eines Unternehmens "extrem" reorganisiert: Software-Reengineering
(Anekdote: Der Vorstandsvorsitzende in persona soll das Buch auf dem Schreibtisch eines Extremisten vorgefunden haben. Die Konsequenz war koestlicherweise eine neue Aufgabenverteilung fuer den Kollegen und ein baldiger Firmenwechsel. Ob da eine Kausalitaet vorlag, ist allerdings nie ganz herausgekommen. - Merke: Buecher sind maechtig)

Imho sind theoretische Bücher aus dem amerikanischen Raum allein wegen ihres Unterhaltungswertes den oft trockenen Abhandlungen aus deutschen Landen vorzuziehen.

Deutsche haben meist einfach keinen Humor und sind selten unterhaltsam.

ich habe mit der zweiten Gruppe immer wieder das Problem, nicht im Stehen einzuschlafen, so lähmend sind die meist.

Eigentlich sollte das Buch ja vor dem Einschlafen gelesen werden.

Gruss,
Lude

[Klaus Mock]

Hallo,

ja, wir hatten hier (in der Firma) auch mal zwei Extremisten. Da habe ich das Buch gesehen (bin mir allerdings nicht 100% sicher). Da geht es darum, wie man die Software eines Unternehmens "extrem" reorganisiert: Software-Reengineering

Ich bin zwar kein Extremist, habe aber doch für mich sehr vieles aus dem Buch heraus holen können, das mir bei meiner täglichen Arbeit weiter hilft. Vor allem wenn es um das Design von Klassen n Hierarchien usw. geht, kann man über diesen 'Umweg' viel lernen. (Ich bin ja ein Quereinsteiger)

(Anekdote: Der Vorstandsvorsitzende in persona soll das Buch auf dem Schreibtisch eines Extremisten vorgefunden haben. Die Konsequenz war koestlicherweise eine neue Aufgabenverteilung fuer den Kollegen und ein baldiger Firmenwechsel. Ob da eine Kausalitaet vorlag, ist allerdings nie ganz herausgekommen. - Merke: Buecher sind maechtig)

Dann sollte man dem VV vielleicht einmal das Buch 'Warum Softwareprojekte meist scheitern' (oder so ähnlich) unterjubeln, vielleicht 'rationalisiert' er sich dann selbst weg;-)

Imho sind theoretische Bücher aus dem amerikanischen Raum allein wegen ihres Unterhaltungswertes den oft trockenen Abhandlungen aus deutschen Landen vorzuziehen.

Deutsche haben meist einfach keinen Humor und sind selten unterhaltsam.

Wissenschaft ist etwas Ernstes, also muß es auch ernst vorgetragen werden, oder? *g*

Eigentlich sollte das Buch ja vor dem Einschlafen gelesen werden.

Schon, aber nicht _zum_ Einschlafen;-)

Grüße
  Klaus

[Lude]

Hi,

(Anekdote: Der Vorstandsvorsitzende in persona soll das Buch auf dem Schreibtisch eines Extremisten vorgefunden haben. Die Konsequenz war koestlicherweise eine neue Aufgabenverteilung fuer den Kollegen und ein baldiger Firmenwechsel. Ob da eine Kausalitaet vorlag, ist allerdings nie ganz herausgekommen. - Merke: Buecher sind maechtig)

Dann sollte man dem VV vielleicht einmal das Buch 'Warum Softwareprojekte meist scheitern' (oder so ähnlich) unterjubeln, vielleicht 'rationalisiert' er sich dann selbst weg;-)

80%-90% scheitert, bzw. scheitert mit (teilweise unglaublichen :-) Teilloesungen.

Ich denke, dass 50% Scheitern normal ist.

Warum ist das so?

Gruss,
Lude

[Michael Schröpl]

Hi Lude,

80%-90% scheitert, bzw. scheitert mit (teilweise unglaublichen :-) Teilloesungen.
Ich denke, dass 50% Scheitern normal ist.

ich denke, daß sich die Zahl derjenigen Projekte, die "scheitern", gar nicht messen läßt.

Dazu ist der Anteil derjenigen Projekte, bei denen überhaupt nicht eindeutig feststellbar ist, _ob_ sie gescheitert sind (weil die Aufgabenstellung nicht hinreichend präzise formuliert wurde, um entscheiden zu können, ob sie erfüllt wurde oder nicht: "Ja - aber _so_ habe ich das doch nicht gemeint ... ich habe mir das ganz anders vorgestellt ..."), viel zu hoch. :-(

Viele Grüße
      Michael

(der gerade wieder so ein Kundenprojekt auf dem Schreibtisch hat, wo der Auftraggeber über das Stadium "Schreiben Sie ein Programm." noch nicht signifikant hinaus gekommen ist ... ich verspüre in solchen Fällen jedes Mal den unwiderstehlichen Drang, ein "Hello World" als 'Lösung' abzuliefern ...)

[Lude]

Hallo, Michael,

80%-90% scheitert, bzw. scheitert mit (teilweise unglaublichen :-) Teilloesungen.
Ich denke, dass 50% Scheitern normal ist.

ich denke, daß sich die Zahl derjenigen Projekte, die "scheitern", gar nicht messen läßt.

Man kann's nicht messen, weil die Anforderungs-Spezifikation nie erarbeitet wurde. Und dann gilt auch noch der Satz: What you cannot measure, you cannot manage!

"Ja - aber _so_ habe ich das doch nicht gemeint ... ich habe mir das ganz anders vorgestellt ..."

Oder auch: "Schauen Sie doch einfach, wie das alte Programm funktioniert." oder "Machen Sie einfach" oder "Es ist doch alles klar, oder?"   :-(

(der gerade wieder so ein Kundenprojekt auf dem Schreibtisch hat, wo der Auftraggeber über das Stadium "Schreiben Sie ein Programm." noch nicht signifikant hinaus gekommen ist ... ich verspüre in solchen Fällen jedes Mal den unwiderstehlichen Drang, ein "Hello World" als 'Lösung' abzuliefern ...)

Was die Frage aufwirft, ob dieses Anforderungsverhalten dann leicher oder schwerer zu bearbeiten ist, wenn der Abnehmer der Leistung extern oder intern "sitzt".

Gruss,
Lude

[Michael Schröpl]

Hi Lude,

Oder auch: "Schauen Sie doch einfach, wie das alte Programm funktioniert."

Aha - her mit dessen Quelltext, und einige Mann-Monate zusätzlicher Aufwand?

oder "Machen Sie einfach"

Das ist in der Tat der worst case.

oder "Es ist doch alles klar, oder?"   :-(

Das hingegen kann man sofort mit "nein - haben Sie denn alle denkbaren Fälle aufgelistet?" beantworten.

Was die Frage aufwirft, ob dieses Anforderungsverhalten dann leicher oder schwerer zu bearbeiten ist, wenn der Abnehmer der Leistung extern oder intern "sitzt".

Gegen eine interne Blockade kann man Druck machen (schlimmstenfalls auf dem Dienstweg) - aber mach Du mal Druck gegenüber einem Kunden, von dem Du einen Auftrag, also Geld haben willst ...

Viele Grüße
      Michael