Zuschauen beim Softwareentwurf

Konzepte, Notationen, Methoden auf Papier sind geduldig. Darüber zu lesen, ist eine Sache. Sie dann aber anzuwenden, auch mit dem besten Willen, eine andere. Was im Artikel oder im Buch noch verständlich war und einfach aussah, erweist sich in der Praxis schnell als knifflig. Der Transfer fällt schwer – und dann lässt man es einfach sein und macht weiter wie bisher.

Dem möchten Stefan Lieser und ich nun etwas entgegenstellen. Wir sind überzeugt, dass leichtgewichtiger Softwareentwurf möglich und wünschenswert ist. Wir finden, dass er mit Flow-Design und Softwarezellen vor dem Hintergrund des Softwareuniversums wirksam ist. Und wir wollen das nun auch live demonstrieren.

Bisher haben wir dazu viel geschrieben, in diesem Blog, in der dotnetpro und anderen Zeitschriften und schließlich auch in einem Buch: The Architect´s Napkin – Der Schummelzettel.

Was in den Artikeln über Jahre durch eine Evolution gegangen ist, fasst das Buch zusammen. Es ist eine Referenz unserer Konzepte und Notationselemente. Wir benutzen es als Schulungsunterlage in unseren Clean Code Developer Trainings z.B. bei der CCD Akademie. Es ist bei leanpub.com und sogar bei amazon erhältlich.

Wir wir erleben, braucht es einige Übung, um vom traditionellen schwergewichtigen Entwurfsdenken – das deshalb oft vermieden wird – auf diesen Ansatz umzuschalten. Bei aller Leichtgewichtigkeit ist er doch sehr anders.

In Trainings können wir das anleiten und begleiten. Was aber danach?

Für die Zeit danach bzw. zwischen Trainingseinheiten, für das Selbststudium haben wir nun ein gemeinsames Buchprojekt gestartet:

In diesem Buch wenden wir unsere Methode an. Wir lösen mit ihr kleine und große Aufgaben aus dem Coding Dojo der CCD School.

Das tun wir jedoch nicht wieder nur im Text, sondern auch per Video. Und die Resultate stehen in einem öffentlichen Git-Repository.

Zu jeder Kata führen wir den Entwurf live durch. Wir treffen uns online ohne weitere Vorbereitung und gehen die Anforderungen gemeinsam an. Hier als Beispiel der Entwurf zur ersten Kata im Buch. Die ist natürlich noch klein und einfach, doch sie zeigt den grundsätzlichen Ansatz:

In dieser Weise geht es weiter mit den anderen Katas bis zu Application und Architecture Katas, die wir dann verteilt implementieren.

Das Buch dient der Zusammenfassung von Video und Code. Es destilliert das Wichtigste nochmal zum Nachlesen heraus. Denn in Text lässt sich leichter navigieren als in einem Video. Und es kommentiert und ergänzt den live Entwurf.

Wir hoffen, in dieser Weise einem stiefmütterlich behandelten und zu Unrecht als trocken oder gar irrelevant angesehenem Thema neues Leben einzuhauchen. Softwareentwurf ist ein systematischer Prozess unter Anwendung einer Methode. Dabei kann man nun zuschauen. Das zeichnet ein realistisches Bild des Vorgehens. Das nimmt hoffentlich Unsicherheit.

So wie wir Software entwickeln, so arbeiten wir auch an dem Buch: agil. Es ist nicht fertig, sondern wächst in Inkrementen. Das erste Inkrement veröffentlichen wir heute. Weitere Releases folgen in den nächsten Wochen.

So können wir aus unserer Erfahrung bei der Videoaufzeichnung, beim Schreiben, beim Publizieren lernen. Und Feedback aus der Community können wir auch einfließen lassen.

Ich würde mich freuen, wenn Sie Lust hätten, uns beim Softwareentwurf zuzuschauen. Über neue Releases erfahren Sie bei Twitter hier und hier.

Kinderleicht eine Programmiersprache lernen – Das Nostalgie-eBook

Ich hatte das Buch echt vergessen, das ich 1985 geschrieben hatte. Jetzt ist es mir beim Ausmisten meiner Regale in die Hand gefallen. 220 Manuskriptseiten ausgedruckt auf einem Nadeldrucker. Wahnsinn!

Damals war ich noch beseelt vom Informatikunterricht in der Schule, den ich zwei Jahre zuvor mit dem Abi hinter mir gelassen hatte. Und seitdem war ich mächtig auf einem Apple II mit Z-80 Karte und CP/M zugange. Dort konnte ich mit Turbo Pascal fortsetzen, was wir auf einer Dietz Mehrplatzanlage mit Bernsteinmonitoren angefangen hatten. Seufz… Sweet memories…

So hatte ich begonnen – zunächst mit meinem Schulfreund Helge Baumann –, eine Anleitung zum Programmieren für Pascal zu schreiben. Die trockenen, eher akademischen Bücher, die ansonsten verfügbar waren, schienen ungeeignet für den Schulgebrauch. Wenn ich mich recht erinnere, hatten wir im Unterricht auch kein Lehrbuch.

1983 oder so begonnen, dauerte es allerdings bis 1985, um das Werk fertigzustellen. Abitur, Bundeswehr, Studiumsbeginn in Hamburg und Liebeskummer hielten die Arbeit am Manuskript immer wieder auf.

Irgendwie habe ich es dann aber doch geschafft. Nur gelangte der Text dann weder an meine alte Schule, noch zu einem Verlag, der ihn hätte veröffentlichen wollen. Teubner war zwar grundsätzlich interessiert an mir als Autor, nur nicht mit dem Thema und der Form. Und so ist das Manuskript in einem Ordner geblieben und mehrfach umgezogen.

Das Ziel damals war, eine Einführung in die Programmierung für eine populäre, nicht akademische Programmiersprache zu liefern, die auch den Laien anspricht. Alles sollte ganz einfach und konkret beschrieben werden. In kleinen Schritten.

Die Beispielprogramme sollten durchaus ganze Anwendungen sein, nicht nur Algorithmen. Und auch der Entwurf und die Lesbarkeit von Software waren wichtig. Deshalb gibt es viele Struktogramme. Niedlich, oder? Aber das war damals state-of-the-art.

Vor allem aber sollte die Sprache entspannt sein und der Text durch Bilder aufgelockert werden. So finden sich im Manuskript denn auch mehr als 60 liebevoll von Hand gezeichnete Illustrationen.

Die in den Text zu bringen, war 1985 nicht einfach. Da gab es keine Textverarbeitungsprogramme wie Word, auch keinen Scanner, keine Grafiksoftware. Also habe ich im Text beim Schreiben Platz für die Zeichnungen gelassen und sie nach dem Ausdruck direkt aufs Blatt gezeichnet. Wenn ich mir überlege, wieviel Mühe das gemacht haben muss… Aber ich kann mich nicht mehr daran erinnern.

Und nun liegt es nach 28 Jahren wieder vor mir. Fühlt sich ein Stück wie ein fremdes Buch an. Aber wenn ich dann drin lese, merke ich natürlich schon, dass das von mir ist ;-) Vieles hat sich seitdem verändert an mir, aber eben nicht alles.

Spannend finde ich, dass mir das Manuskript wirklich entfallen ist. Anfang der 2000er, als ich einige Bücher zu .NET und Datenbankprogrammierung geschrieben habe, war mir, als hätte ich noch nie so lange Texte entwickelt.

Heute schaue ich sogar ein wenig neidisch auf mein früheres Selbst. Wie hat der das geschafft, der damalige Ralf, diese Ausdauer aufzubringen? Mir macht es heute große Schwierigkeiten, Texte von mehr als 50-60 Seiten zu schreiben. Dabei wäre das sehr nötig, um mal eine kompakte und kohärente Darstellung von Flow-Design anbieten zu können.

Durch das Schreiben von Artikeln und Blogpostings bin ich aber so auf kurze Texte getrimmt, dass mir immer wieder der Atem für Längeres fehlt. Ich muss mich wohl noch ein bisschen mehr anstrengen. Vielleicht macht mir der Manuskriptfund in einem Regal ja Mut. Oder ich finde eine Form für die Darstellung, die zu meiner Ausdauer passt.

Nach soviel Schwelgen in Erinnerungen hier nun aber meine ambitionierte Einführung in die Programmierung mit Turbo Pascal. Zum Schmunzeln und als Anregung für Ausflüge in die eigene Vergangenheit.

Mit den heutigen Möglichkeiten ist es nun kein Problem mehr, so ein Manuskript zu veröffentlichen. Ich könnte mittels lulu.com auch in wenigen Stunden ein Papierbuch machen, das “der geneigte Leser” dann online erstehen kann. Wahnsinn, wie weit wir in den letzten 28 Jahren gekommen sind.

Und andererseits… Wahnsinn, wieviel dann doch bei der Programmierung gleich geblieben ist. Die Syntax hat sich verändert - Java, C#, JS statt Pascal –, auch das Programmierparadigma ist anders – objektorientiert statt prozedural – dennoch stehen Menschen, die ins Programmieren einsteigen wollen, vor denselben Problemen. Mit einer Programmiersprache statt mit Hammer oder Pinsel umzugehen, ist eine ganz eigene Herausforderung.

Und da unter den aktuellen Sprachen immer noch grundsätzlich dieselben Konzepte liegen wie damals… Vielleicht könnte der Text dem einen oder anderen Programmieranfänger auch heute noch mit seiner Anschaulichkeit helfen.

Viel Spaß beim Durchblättern!

Pascal - Eine kinderleichte Einführung by Ralf Westphal

P.S. Wer mag, kann übrigens die Einführung online mitprogrammieren. Hier ein Beispiel aus dem Text ausgeführt in der online IDE http://www.compileonline.com/compile_pascal_online.php:

P.P.S. Natürlich ist mir aufgefallen, dass die Sprache bzw. der Dialekt, mit dem ich damals programmiert habe vom selben Erfinder stammt wie die Sprache, mit der ich heute arbeite. Turbo Pascal wie C# sind von Anders Hejlsberg.

Ob das aber auch für die Sprache gelten wird, mit der ich in 28 Jahren arbeite…? Ich bezweifle es. Abe wer weiß… ;-)

Lesenswerte Widerlegung

Eine Allaussage geht um: “Es kann nur sein, wie es ist.”

Unternehmen geht es schlecht, weil der Markt halt so ist, wie er ist; böse Globalisierung. Oder die Mitarbeiter sind halt, wie sie sind; böse Ausbildungsdefizite und Konsumentenhaltung. Daran kann man kaum was ändern. Höchstens sollte man die bisherigen Anstrengungen verstärken: “Nachsitzen”, wenn das Release noch raus muss; mehr Incentives, damit endlich die Softwarequalität steigt; strengere Budgetschrauben, damit alles unter Kontrolle bleibt; weniger Investition in Mitarbeiterfortbildung, weil dadurch wertvolle Zeit zur Kundenwunscherfüllung verloren geht. Usw. usf. ad nauseam.

[Pause]

Mir ist ein wenig übel geworden, da ich diese Litanei geschrieben habe. Die komprimiert und verkürzt zwar, ist aber ein Abbild der Stimmung, die mir in Beratungen, Trainings oder auf Community-Veranstaltungen entgegenschlägt. Früher war vor allem Klagen über Tools oder Microsoft. Veteranengeschichten folgten dann schnell. Wie es damals mit dem C64 war… und die Lochkarten…

Heute scheint das weniger Thema. Vielleicht liegt es auch an meinem neuen Fokus, der nicht mehr auf Technologien, sondern auf Softwarequalität liegt. Heute höre ich Klagen über Arbeitsbedingungen. Immer wieder werden da Mauern beschrieben, gegen die Entwickler laufen, weil sie nicht so dürfen, wie sie wollen. ReSharper darf nicht angeschafft werden: zu teuer. Automatisiertes Testen darf nicht in Anschlag gebracht werden: dafür hat der Kunde nicht bezahlt. Eine Fortbildung darf nicht besucht werden: vier Monate Urlaubssperre, weil die Projekte weit jenseits des Plans liegen.

Dahinter – wie schon gesagt – der Glaubenssatz: Irgendwie kann es nicht anders sein. So ist die Welt halt. Vor allem ist sie kein Wunschkonzert. Dem Schicksal und den Marktgesetzen den ehernen sollte man sich daher ergeben.

Widerlegung

Die Allaussage, der unumstößliche Glaubenssatz wird ad absurdum geführt durch den Nachweis der Existenz auch nur eines Gegenbeispiels.

Wenn es auch nur einmal anders gehen kann, als die Überzeugung diktiert… dann ist die Welt anders als gedacht. Dann ist Hoffnung auch in schlimmsten Zeiten.

Und solche Hoffnung gibt es. Der campus Verlag hat eine mehr als 200 Seite starke Widerlegung des allgegenwärtigen Glaubenssatzes herausgebracht, die Unternehmensverhältnisse könnten kaum anders sein. Ihr Titel: “Nur Tote bleiben liegen” vom Autorenduo Förster und Kreuz.

Gelesen habe ich das Buch, weil Rezensionsexemplare davon im Blog der Autoren an andere Blogger vergeben wurden. Da konnte ich nicht nein sagen ;-)

Gefallen hat mir das Buch aber nicht wegen seiner Kostenlosigkeit für mich. Nein, keine Sorge. Es ist seine “Schwingung”, die gute Laune, der Optimismus, die Hoffnungsfülle, der Gegenentwurf, das Ja zu Neu und Anders, die es für mich zu einer Empfehlung machen.

Ich will deshalb auch gar nicht lange auf den Inhalt eingehen. Man muss es einfach aufschlagen und loslesen. Irgendwo. Jede Seite eine Widerlegung. (Naja, vielleicht übertreibe ich ein wenig ;-) Jede Seite ein Beispiel dafür, dass andere Arbeitsverhältnisse, andere Organisation von Unternehmen möglich ist. Und zwar ganz handfest. Dies ist kein Thesenbuch, sondern eine Beispielsammlung. Förster und Kreuz berichten aus der Realität. Die mag mal fern sein, auf anderen Kontinenten, aber sie ist immer relevant. Auch das ein Effekt der schlimmen Globalisierung. Oder ist die gar nicht so schlimm?

Wer glaub, man können nicht anders umgehen mit der Arbeitszeit oder der Führung oder der Aus-/Fortbildung oder der Kontrolle oder dem Kunden, der schlage dieses Buch auf uns lasse sich eines Besseren belehren. Es geht anders, als die allermeisten Unternehmen es heute tun und meinen nicht anders tun zu können. Irgendwo geschieht schon die kleine oder große Revolution, die Kunden zufrieden macht, Unternehmen prosperieren lässt und Mitarbeiter ganz einfach motiviert.

Internet, Globalisierung, neue Medien, anspruchsvolle Kunden, Digital Natives als Mitarbeiter… das alles und mehr muss keine Bedrohung althergebrachter Ruhe und Ordnung sein. Es liegt an uns, das Glas als halb voll und nicht als halb leer zu betrachten. Die Chancen auf etwas Besseres lauern überall. Das beweist “Nur Tote bleiben liegen” mit einem Feuerwerk an weltweit gesammelten Impressionen.

Im Maul vom Gaul

So empfehlenswert ich das Buch finde, man darf keine Tiefründigkeiten erwarten und auch keine Tipps für die Praxis. Wer von der Lektüre motiviert das Berichtete selbst ausprobieren möchte, ist auf sich gestellt.

Das soll keine Klage sein, sondern nur ein Hinweis, um falsche Erwartungen zu zerstreuen. Förster und Kreuz haben einen hochfrequenten Impulsgeber und Motivator geliefert, kein Handbuch.

Nein, eine tiefergehende Kritik am Inhalt habe ich nicht. Man nehme einfach das Buch für das, was es will und kann. Die knapp 25 EUR für das Hardcover sind nicht zuviel für die Portion Zuversicht, die sich daraus löffeln lässt.

Aber -- denn ohne Aber geht es nicht ;-) -- eines hat mir nicht gefallen. Es ist mir erst nach einiger Zeit aufgefallen, als ich nachfragte, ob es auch eine elektronische Version des Buches gäbe, die ich mit meinem iPad auf den prio.walk hätte nehmen können. Das, was fehlt, ist eben oft schwerer zu erkennen, als das, was da ist.

Nein, ich meine nicht eine eBook-Version oder ein Hörbuch. Beides gibt es.

Ich meine die Abwesenheit von Innovation bei Verlag und Autoren.

Es hat einen Moment gedauert, weil auch ich in Jahrzehnten konditioniert wurde, bei Büchern ersteinmal an Papier zu denken. Aber was für ein Quatsch! Bücher müssen weder aus Papier bestehen noch als zusammenhängendes PDF ausgeliefert werden. Sie müssen auch nicht daheim am Schreibtisch verfasst, zu einem Verlag getragen und dann von einem Vertriebler an den Buchhändler gebracht werden. All das inklusive eBook und Hörbuch ist so Buch 1.0, dass es kaum auszudenken ist. Das ist so un-innovativ und so un-mutig, dass es mich bei diesem Buch erschreckt und enttäuscht hat. Schade.

Warum haben Förster und Kreuz, die als Erfolgsautorenduo genügend Reichweite auch ohne Verlag haben, ihr neues Buch “im stillen Kämmerlein” geschrieben? Sie haben natürlich ein Blog, dessen Inhalte früher oder später wahrscheinlich in der einen oder anderen Weise auch wieder in einem Buch auftauchen werden. Dennoch findet das Schreiben ab von der Öffentlichkeit und somit ab vom Feedback statt.

Wie Buch 2.0 ist dagegen dieser Titel:

Der Autor hat sich schon beim Schreiben dem detaillierten Feedback der Community gestellt, indem er den kompletten Text online veröffentlicht hat – mit der Möglichkeit, absatzweise Kommentare zu geben. Hier ein Auszug:

Das ist Web 2.0 gelebt. Vom Autor wie vom Verlag.

Oder warum haben Förster und Kreuz den potenziellen Rezensenten überhaupt als Default ein Papierbuch angeboten? Warum nicht einen Link auf ein PDF oder einen Kindle-Gutschein? Der ganze Aufwand mit Verpackung und Porto ist überflüssig. Allemal für Rezensenten. Mich interessiert doch nur am äußersten Rand, ob das Papierbuch geschmeidig in der Hand liegt. Auch hier also eine merkwürdige Zurückhaltung in Bezug auf das, was möglich und zukunftsweisend ist.

Wo ist auch das virale Marketing? Warum nicht das Buch launchen im Blog mit einem befristeten kostenlosen Download für jedermann? Von mir aus kann es dabei ja durch Einbinden des Namens des Herunterladenden personalisiert werden.

Oder wenn schon nicht ganz umsonst für eine gewisse Zeit, dann zumindest Zahlen mit einem Tweet. Das ist ja trivial aufzusetzen: http://www.paywithatweet.com/

Nett, dass die Blogeinträge der Rezensenten am Ende von den Autoren zusammengefasst werden. Aber auch das ist letztlich Buch 1.0, weil es auf Zentralisierung setzt.

Oder wie wäre es, das Buch sofort in “Module” zu zerlegen. Und nicht nur dieses Buch, sondern auch die bisherigen von Förster und Kreuz? Dann die Module mit Tags versehen oder in eine Concept Map o.ä. einbinden und ab ins Internet damit.

Dann könnte der Inspiration suchende Leser sich durch das Förster und Kreuz Universum bewegen, online lesen z.B. mit Scribd, sich am Ende sein persönliches Buch aus den interessantesten Modulen zusammenstellen, alles in ein PDF “zusammenschweißen” und das womöglich noch ad hoc in der Auflage 1 für sich z.B. durch www.epubli.de drucken lassen. Das (!) wäre Buch 2.0. Das würde dem amerikanischen Sprichwort “Put your money where your mouth is!” entsprechen.

Aber ich will nicht abschweifen. Dies ist ja nur eine Buchrezension und keine Verlagsberatung ;-) Eine Beratung wäre für viele Verlage wohl auch eher das falsche Mittel, um aus deren Klagehaltung herauszukommen. Da scheint mir eher eine Therapie angezeit. Aber das ist ein anderes Thema…

Also komme ich mal zum Schluss:

“Nur Tote bleiben liegen” finde ich lesenswert, weil kurzweilig und inspirierend. Lockere Schreibe, lockerer Inhalt, macht gute Laune. Einfach mal auf den Wunschzettel für Weihnachten setzen – oder gleich dem Chef schenken ;-)

Denn wer sagt, es ginge nicht anders in den Unternehmen, Erfolg und Zufriedenheit seien nur mit Verstärkung tradierter Maßnahmen – Management 1.0 – zu erreichen oder gar nicht, der findet in diesem Buch einen bunten Strauß an Widerlegungen.

Und ganz vielleicht sind Förster und Kreuz ja beim nächsten Buch auch selbst mutiger. Raus aus der Komfortzone gilt nicht nur für die, über die sie berichten, würd´ ich mal sagen.

Lesen heute für Softwareentwickler

Neulich wurde ich gefragt, ob das CCD-Wiki es ernst meine mit der Empfehlung, 6 Fachbücher pro Jahr zu lesen. Das sei doch wohl etwas viel verlangt.

Hm… ist das wirklich viel, ja, zuviel verlangt von geplagten Softwareentwicklern? 6 Fachbücher lesen pro Jahr, also alle 2 Monate ein anderes. Oder wenn wir mal 400 Seiten pro Fachbuch annehmen, knapp 7 Seiten pro Tag lesen. Jahrein, jahraus… Das würde bei 2 Minuten Lesezeit, oder sagen wir 3, damit das Lesen gründlich ist, pro Tag 21 Minuten kosten, also immerhin 1,5% der Tageszeit und wackere 2,5% der Wachzeit.

Tja, wie sieht es aus? Sind 21 Minuten Fachbuchlektüre pro Werk-, Sonn- und Feiertag jahrein, jahraus zuviel verlangt? Dazu kommen ja noch andere Quellen, die wir auch empfehlen zu lesen. Blogartikel, Zeitschriftenartikel, Twitternachrichten… Wenn wir da mal annehmen, CCD würde empfehlen, pro Woche – horribile dictu! – auch noch 4 Fachartikel zu lesen… - Moment, ich rechne, 4 * 5 Seiten à 3 Minuten = 60 Minuten pro Woche oder knapp 9 Minuten pro Tag… - Wir wären am Ende bei 21 + 9 = 30 Minuten pro Wochentag jahrein, jahraus… Puh… Ist das nicht ein bisschen viel?

Das ist die Frage: Sind 6 Fachbücher und 208 Fachartikel pro Jahr zuviel für einen Softwareentwickler? Setzt das sein Zeitbudget unter inakzeptablen Stress? Bringt das seine Aufnahmefähigkeit an ihre Grenzen? 3% der Wachzeit hingegeben an Fachlektüre?

Meine persönliche kurze Antwort: Nein. Das ist natürlich nicht zuviel.

Das kostet weder zuviel Zeit, noch sollte es einen erwachsenen Menschen an sein Aufnahmelimit führen. Oder wenn, dann erwäge man ein Umsatteln auf den ehrenwerten Beruf des Bäckereifachverkäufers.

Und jetzt die lange Antwort:

Verantwortung

30 Minuten Fachlektüre pro Tag dürfen nicht zuviel sein. Denn jede Minute Fachlektüre ist eine Investition in die Erhaltung und sogar die Verbesserung der Vermittlungsfähigkeit. Angesichts von Entity Framework, Code Contracts, TPL, WF, Scrum, WPF, dynamische Typen, Rx, Fit, EBC, WCF, TDD, AppSpace, Complex Event Processing, Kanban und was der Technologien/Konzepte/Methoden noch mehr sein mag, angesichts dieses Sperrfeuers konstanter Neuerungen und Veränderungen sind 30 Minuten täglich ein Tropfen auf den heißen Stein, um auch nur annähernd uptodate zu bleiben.

Muss man denn aber uptodate bleiben? Ja, aus zwei Gründen:

Erstens sollte es jedem am Herzen liegen, seine Kompetenz hoch zu halten. Denn hohe Kompetenz bedeutet Freiheit. Wer kompetent ist, kann sich im Notfall oder auch ohne Not den Job aussuchen. Wer mit veraltetem Wissen auf seinem Sessel sitzt, der hat diese Freiheit nicht.

Das ist wie mit alten Leuten, die stolpern. Warum brechen die sich so leicht etwas? Weil sie keine “Freiheit” haben. Sie sind nicht mehr reaktionsschnell, sie haben keine elastischen Knochen mehr und sie haben wenig Kraft. Das Resultat ist ein ungebremster Fall, der direkt auf einen spröden Knochen trifft.

Dasselbe gilt für “eingerostete” Kompetenz. Statt eines gebrochenen Knochens, der in einigen Wochen wieder heilt, ist das Ergebnis hier jedoch schlimmer, weil es viel länger anhält. Die Unsicherheit nimmt zu, die Motivation nimmt ab, alles dauert länger, die Zahl der Konflikte mit anderen steigt, Veränderungen werden schwieriger. Bottom line: “Eingerostete” Kompetenz erzeugt Stress. Garantiert.

Zweitens ist die Erhaltung bzw. Vergrößerung eine Frage des Verantwortungsgefühls gegenüber Kunde und Arbeitgeber. Bezahlt wird für gute Arbeit. Und das bedeutet nicht nur, dass die Software irgendwie funktioniert. Das bedeutet auch, dass sie auf der Höhe der Zeit ist. Oder zumindest, dass der Entwickler weiß, was state-of-the-art ist, wenn er sich gegen eine Lösung auf der Höhe der Zeit entscheidet. Für etwas anderes würde ich als Kunde oder Arbeitgeber jedenfalls kein Geld ausgeben. Und ich denke, denselben Anspruch stellen Sie an einen Bauingenieur, Architekten, Elektrotechniker oder Landwirt.

Wer sich also nicht fit hält, der erfüllt den Anspruch an ihn nicht. 30 Minuten Lektüre pro Tag – die selbstverständlich in der Arbeitszeit liegen – sollten also nicht auf Widersprich stoßen.

Anspruch

Zähneknirschend mögen Sie sich nun in die Lektür schicken. Bei allem Verantwortungsgefühl erscheinen Ihnen die knapp 3400 Seiten pro Jahr “Zwangslesen” aber immer noch enorm.

Dazu kann ich nur sagen: Sehen Sie das Lesen nicht so eng.

Sie mögen noch “Großvaters Anspruch” ans Lesen im Kopf haben. Zu dem gehört, dass jedes Buch ganz gelesen werden muss, dass man ein Buch zur Zeit liest, dass man ein Buch fertig liest und erst dann das nächste anfängt.

Vergessen Sie diesen Anspruch. Er gehört wie Großvater einer vergangenen Epoche an. Er ist entstanden in einer Mangelsituation. Früher gab es einfach nicht soviel zu lesen. Und Lesestoff war vergleichsweise teuer.

Heute haben wir Fachlektüre im Überfluss und zu kleinen Preisen. (6 * 35 EUR = 210 EUR/Jahr für Fachbücher – wenn Sie die denn selbst bezahlen müssen – halte ich für nicht viel Geld angesichts dessen, was auf dem Spiel steht: ihr Gehalt bzw. ihre Gehaltserhöhung. Kosten für Artikel setze ich mal gar nicht an. Davon gibt es soviele kostenlos im Internet; aber selbst wenn Sie noch das eine oder andere Zeitschriftenabo haben sollten, ändert sich die Größenordnung der Fachlektüreausgaben nicht.) Also können und sollen wir anders mit ihr umgehen.

Hier einige Tipps, nach denen ich lese:

• Lesen Sie, was Sie interessiert. Versuchen Sie nicht, überall uptodate zu sein. Fokussieren Sie sich besonders auf 2-3 Schwerpunkte, die Sie besonders mögen. Aber lesen Sie auch sonst, was Ihr Interesse weckt.
  Und lassen Sie soweit es geht aus, was Sie langweilt. Denn nur bei hoher Lesemotivation nützt das Lesen etwas. Außerdem geht es dann schneller.
  Glauben Sie übrigens nicht, dass Sie auf diese selektive Leseweise etwas Wichtiges verpassen. Was wirklich, wirklich wichtig ist, kommt wieder und drängt sich früher oder später auch in Ihren Interessenshorizont.
• Lesen Sie soweit es Sie interessiert, soweit Sie mitkommen. Zwingen Sie sich nicht, einen Artikel oder ein Buch zuende zu lesen. Geben Sie dem Text eine Chance, halten Sie durchaus auch einen Moment aus, wenn es mal zäh wird – aber prügeln Sie sich nichts rein. Brechen Sie also Lektüre guten Gewissens ab. Vielleicht kommen Sie später wieder zurück und lesen weiter. Vielleicht aber auch nicht. Manche Themen müssen sich in Ihnen erst entwickeln. “Ist der Schüler bereit, kommt der Lehrer” heißt es.
• Lesen Sie quer. Springen Sie im Text. Verschaffen Sie sich einen Überblick (Inhaltsverzeichnis, Bilder, Überschriften) und lesen Sie dann, was Sie anzieht. Lesen Sie in der Mitte oder am Ende. Oder von allem ein bisschen.
• Lesen Sie mehrere Fachbücher parallel. 50 Seiten in einem, dann 100 Seiten im anderen, dann wieder 70 Seiten im ersten, 150 Seiten in einem Dritten. Wie es Ihnen Spaß macht. Die Lektüre kann sich gegenseitig befruchten. Und Sie gewinnen Inkubationszeit: Nach 50 Seiten im ersten Buch mögen Sie erstmal genug haben. Das Thema muss sich bei Ihnen setzen. Schieben Sie es in den Hinterkopf und fangen Sie etwas Neues an. Später hat sich das erste Thema in Ihnen weiterentwickelt, dann lesen Sie ab Seite 51 weiter.
• Verfolgen Sie viele Quellen (Blogs, Zeitschriften, Fachbücher), aber lesen Sie nicht alles. Vertrauen Sie auf Ihr Unterbewusstsein, dass es aus dem Informationsstrom für Sie Relevantes hervorhebt. Lassen Sie sich von Themen “anspringen”. Blättern Sie durch und verweilen Sie, wo es Sie hält.
• Haben Sie nicht den Anspruch, alles, was Sie lesen, auch auszuprobieren. Tun Sie das, wenn es Ihnen wirklich wichtig erscheint oder Spaß verheißt. Ansonsten lassen Sie es sein und beobachten ggf. das Thema weiter.

Wenn Sie sich ein Thema konkret “draufschaffen” wollen, müssen Sie Ihren Modus natürlich etwas verändern. Um jedoch uptodate zu bleiben, reicht der hinter diesen Tipps stehende Anspruch: Lesen Sie selektiv. Hoffen Sie nicht auf das eine Buch, das es bringt. Surfen Sie die Welle des Überflusses.

Texte durcharbeiten, sich an ihnen abarbeiten, sie bis ins Letzte zu verstehen… das war gestern. (Nein, das kann natürlich auch heute noch sein. Aber solche Texte sind relativ selten. Setzen Sie stattdessen darauf, dass am Ende mehrere Texte zu einem Thema Ihnen den Durchblick mit weniger Mühe verschaffen, den Sie sich früher mit dem “Studium” eines Textes hätten mühsam erarbeiten müssen. Sie haben heute den Vorteil, Themen von vielen Autoren beleuchtet sehen zu können, wo früher der Quellenmangel sie auf einen festgenagelt hat.)

Was denken Sie nun? Ist die CCD-Forderung von 6 Fachbüchern pro Jahr wirklich so gewaltig? Oder sah sie nur so groß aus, weil Sie sie im Lichte eines veralteten Leseanspruchs verstanden haben?

Ich hoffe, Sie können nun entspannt(er) denken: “Alles halb so schlimm.” Und vor allem: “Das Lesen bringt mich weiter. Ich übernehme damit Verantwortung für meine Kompetenz. Es macht mich zu einem besseren Softwareentwickler. Und besser zu werden, das macht auch Spaß.”

Was treibt uns an?

Mit der Softwarequalität steht´s nicht zum Besten. Könnte das aber nicht nur an den ewig suboptimalen Programmiersprachen, unzulänglichen Werkzeugen, imperfekten Konzepten und inkompetenten Entwicklern liegen, sondern womöglich daran, dass viele die Arbeit als nicht so befriedigend empfinden, wie sie sein sollte, um wirklich gute Ergebnisse abzuliefern?

In einem Artikel meiner Sandbox-Reihe in der dotnetpro habe ich mir darüber einmal Gedanken gemacht. Den gibt es heute exklusiv vorab zu lesen. Auch für die, die keine dotnetpro-Abonnenten sind.

Ich glaube, dass wir einiges an unseren Produkten und auch in unserem (Arbeits)Leben verbessern können, wenn wir uns Gedanken machen, warum wir eigentlich arbeiten. Was treibt uns da wirklich an?

Wen meine Überlegungen dazu interessieren, der kann ja mal in meinen Artikel reinschauen. Und dann diskutieren wir hier. Würde mich freuen.

Den Artikel zu lesen, kostet nichts – außer eine Tweet. Wie ist das? Ein fairer Preis?

Linksammlung zum Thema Monads [OOP 2010]

Bei der Beschäftigung mit Funktionaler Programmierung stoße ich immer wieder auf den Begriff Monad. Leider bringt mich jedoch der zugehörige Wikipedia-Artikel bei dessen Verständnis nicht weiter. Deshalb habe ich jetzt ein wenig gegooglet. Für mich als Entwickler, der bisher (vor allem) mit imperativen Programmiersprachen zu tun hatte, sind dabei die folgenden Beiträge herausgekommen, die ich als verständnisfördernd empfinde.

• http://weblogs.asp.net/podwysocki/archive/2008/10/13/functional-net-linq-or-language-integrated-monads.aspx: "Simply put, a monad, unlike your normal function results, stores function results and side-effect representations. This allows side effects to be propagated through the return values of functions without breaking the pure functional model."
• http://www.reddit.com/r/programming/comments/64th1/monads_in_python_in_production_code_you_can_and/c02u9mb: "For example, it is possible to write out messages in a purely functional way using a monad. The idea is, instead of just returning a value, you return a value and the string that you want to write to the screen. Why do it that way, instead of just writing out to the screen? Because that way, your functions don't have side-effects, you preserve referential transparency, and you -- and more importantly, your compiler -- can reason about your code algebraically, allowing it to simplify your code the way you would an equation."
• http://www.haskell.org/tutorial/monads.html, "What [Monads] really provide is modularity. That is, by defining an operation monadically, we can hide underlying machinery in a way that allows new features to be incorporated into the monad transparently."
• http://www.inf.fu-berlin.de/lehre/SS09/PI02/docs/monaden.pdf, "Monaden sind einfach eine Möglichkeit, Funktionen elegant miteinander zu kombinieren, bei denen es auf Grund ihrer Typen zu Problemen bei der Benutzung der normalen Funktionskomposition kommt."
• http://www.algorithm.com.au/downloads/talks/monads-are-not-scary/monads-are-not-scary-chak.pdf, “Monads are a programming pattern for library APIs. […] What kind of libraries benefit from monads? Answer: Libraries that manipulate contextual information. Contextual information is implicit and the monad hides it.”
• http://channel9.msdn.com/shows/Going+Deep/Brian-Beckman-Dont-fear-the-Monads/ (sehr empfehlenswertes Video zur funktionalen Programmierung im Allgemeinen und Monaden im Besonderen)
• http://leibnizdream.wordpress.com/2008/10/21/why-use-computation-workflows-aka-monads-in-f/
• http://www.paul-abraham.com/MonadsInFSharp.doc
• http://blogs.msdn.com/wesdyer/archive/2008/01/11/the-marvels-of-monads.aspx
• http://codebetter.com/blogs/matthew.podwysocki/archive/2009/01/28/much-ado-about-monads-maybe-edition.aspx
• http://www.aboutcode.net/2008/01/14/Async+WebRequest+Using+LINQ+Syntax.aspx
• http://codebetter.com/blogs/matthew.podwysocki/archive/2009/12/30/much-ado-about-monads-state-edition.aspx
• http://community.bartdesmet.net/blogs/bart/archive/2008/08/19/probably-the-most-powerful-linq-operator-selectmany.aspx (zur Rolle von SelectMany() für Monad-Implementationen in C#)
• http://higherlogics.blogspot.com/2008/01/almost-type-safe-general-monad-in-c-aka.html
• http://blog.sigfpe.com/2006/10/monads-field-guide.html (interessante Visualisierung von Monads)
• http://www.haskell.org/haskellwiki/Monad_tutorials_timeline (Linksammlung von Monad Tutorials)
• http://www.haskell.org/haskellwiki/What_a_Monad_is_not (zur Abgrenzung)

So ganz bin ich mit diesen Beiträgen allerdings immer noch nicht zufrieden. Ich finde die Erklärungen für Monads immer noch recht theoretisch und fern der imperativen objektorientierten Programmierpraxis.

Wie würde ich nun Monads erklären? Hm... mal sehen. In einem zukünftigen Beitrag versuche ich das mal.

Getting Things Done - ganz anders und ganz einfach [OOP 2009]

Ja, auch ich habe den Zeitmanagement-Klassiker "Getting Things Done" ("Wie ich die Dinge geregelt kriege") von David Allen gelesen. Und ich habe daraus auch etwas gelernt:

1. Habe einen (!) Platz, an dem du alle Aufgaben bzw. Hinweise darauf, sammelst.
2. Nutze diesen Platz konsequent und regelmäßig, um die nächste Aufgabe "abzuholen" bzw. zukünftige Aufgaben zu hinterlegen.
3. Erledige Kleinstaufgaben sofort, plane größere Aufgaben ein.

Ziel dieser Praktik sind mentale Entlastung und Kontrolle. Aufgaben, die man nicht gerade erledigt, sollen die Konzentration im Hier und Jetzt nicht behindern. Äußere Umstände beherrschen nicht, sondern werden durch aktive Planung beherrscht.

That´s it.

Mehr hat mir David Allen nicht gebracht - außer einem schlechten Gewissen, sein ausgefeiltes System nicht genauso ausgefeilt zu benutzen.

Naja, in einem Punkt habe ich es noch angepasst: Wo er empfiehlt, "Abteilungen" für Aufgaben anzulegen, die mit bestimmten Orten oder Gelegenheiten zu tun haben (z.B. "Wenn ich das nächste Mal beim Faxgerät bin"), da nutze ich diese Orte selbst. Habe ich eine Aufgaben, die mit dem Faxgerät oder dem Lebensmitteleinkauf zu tun haben, dann lege ich mir Aufgabenzettel genau dorthin, also zum Faxgerät und zur Wohnungstür (durch die ich zum Einkauf gehe). So "stolpere" ich über meine Aufgaben. Ich muss sie also nicht im Hinterkopf halten.

Ansonsten aber... da grüble ich eher darüber nach, was mich an David Allens gutgemeinten Ratschlägen stört. Und meine Erkenntnis ist inzwischen:

"Getting Things Done" (GTD) ist keine Lösung, sondern ein Symptom.

Das Buch ist ein Symptom für eine Kultur oder auch nur Arbeitshaltung, in der man soviel "auf dem Zettel hat", dass man überhaupt ein ausgefeiltes System braucht, um es zu bewältigen. Es scheint geradezu eine Tugend zu sein, sich soviel aufzuladen, dass man sich nur mit modernen Hilfsmitteln organisieren kann. Eine Aufgabenliste, ein Kalender, eine Wiedervorlagemappe oder auch (im fortgeschrittenen Stadium) eine Assistenz reichen nicht mehr. Nein, es muss ein mehrdimensionales Verwaltungs- und Erinnerungssystem sein.

Seit ich das erkannt habe, geht es mir besser. Ich brauche GTD nicht. Ich brauche nur Mut, mein Leben/meine Arbeit so einfach zu halten, dass ich gar nicht erst in eine organisatorische Überlastungssituation komme. Wenn ich an soviel denken muss, dass ein simpler Kalender und eine Aufgabenliste nicht mehr reichen, dann (!) habe ich ein Problem. Denn dann bin ich sehr wahrscheinlich auch so unter Druck, dass mir als Softwareentwickler schlicht Spielräume fehlen und der Raum für Kreativität begrenzt ist.

Dass GTD mir dann ja gerade helfen würde, diese Räume wieder zu eröffnen durch gute Planung... nun, das halte ich für eine Empfehlung wie "Putz die Zähne öfter, damit die ganzen Süßigkeiten ihnen nicht schaden."  Hier ist die Wurzel des Übels ein übermäßiger Zuckerkonsum, dort ist es eine Hypertrophie des Verantwortungsbewusstseins. Denn nur wer sich für viele Dinge verantwortlich fühlt, der hat auch viele Aufgaben, um diese Dinge geregelt zu kriegen.

Die wahre Lösung des Problems, mit dem sich GTD beschäftigt, lautet daher: Reduktion und Delegation. Weniger tun müssen und/oder andere an der Bewältigung beteiligen.

Wenn die zu regelnden Dinge soviel werden, dass man überhaupt merklich Zeit für ihre Regelung aufwenden muss, wenn also auch die Regelung zu regeln ist... dann ist Gefahr im Verzug. Soviel mal zur Abwechslung ins Stammbuch der ewig geschäftigen Manager geschrieben - zumindest derjenigen, die sich über ihre Aufgabenlast bewusst beklagen oder körperliche/psychische Symptome der Überlastung zeigen.

GTD hat nun einen Platz bei mir im Schrank als Mahnung, mich nicht von den Dingen beherrschen zu lassen und in eine Situation zu kommen, wo ich sie mit "normalen Mitteln" nicht mehr im Griff habe.

So freue ich mich auch, dass es Literatur gibt, hinter denen ein anderes Menschenbild steht und die aus der Regelung von Dingen nicht noch eine weitere, umständlich zu erwerbende Kompetenz machen. Wer bisher an GTD geglaubt hat, der versuche es doch mal zur Abwechslung mit einer anderen Einstellung:

oder ganz simplen Werkzeugen, die sich viel eher auch von Fall zu Fall einsetzen lassen:

Ein bisschen Papier in Form von Notizblock, Notizbuch oder Post-It Zetteln reicht oft in Kombination mit dem Willen zu Überschaubarkeit von Verantwortlichkeiten und Aufgabe von Kontrolle.

Die Dinge geregelt kriegen ist dann ganz einfach. Viel einfacher, als GTD meint.

Datenzugriff heute - Die Qual der Wahl beleuchtet

ADO.NET oder LINQ to SQL oder Entity Framework... was leisten eigentlich diese Datenzugriffstechnologien? War schon ADO.NET bei seiner Einführung ein rechter Brocken, den wir als cursorliebende Entwickler zu schlucken hatten, so ist die Datenzugriffswelt seitdem nicht wirklich einfacher geworden - aber vielfältiger. LINQ to SQL und Entity Framework versprechen zwar viel, wie stehen sie aber wirklich im Vergleich zu einander und mit ADO.NET da?

Etwas Ordnung in dieses Gemenge versucht dieser Tage ein Artikel im hierzulande recht wenig bekannten, aber nicht minder guten CoDe Magazine zu bringen. Unter dem Titel "Data Access Options in Visual Studio 2008" stellt Julia Lerman diese drei Datenzugriffstechnologien recht lesenswert nebeneinander. Der Artikel kann - obwohl ziemlich lang - das Feld zwar nicht komplett ausleuchten, doch er gibt einen guten Überblick, wie ich finde. Und das sogar ganz kostenlos in der online Version des Magazins.

Für knapp 20 EUR gibt´s das CoDe Magazine aber auch auf Papier ins Haus geliefert - um es ganz bequem im Lehnstuhl oder auch am Strand lesen zu können. Das gönne ich mir gern. (Und der Herausgeber, Markus Egger, ist ein Netter, mit dem man auf der VSone oder der ADC auch in Deutschland plaudern kann.)

Neues Blog zum Thema Softwarearchitektur - The Architect´s Napkin

So, nun kann ich es nicht länger aufschieben. Ich muss einfach mal meine Ideen zum Thema Softwarearchitektur zusammenfassen. Immer wieder fragen mich meine Beratungskunden, ob ich nicht ein Buch für sie hätte, in dem sie das, worüber wir sprechen und was wir gemeinsam üben, nachlesen könnten.

Nicht, dass ich nicht schon über meine Ideen oder gar meine "Methode" geschrieben hätte. In meinem englischen Blog hatte ich die Softwarezellen eingeführt, hier im deutschen Blog dann "Software als System". In der dotnetpro beschreibe ich auch immer wieder Aspekte der Softwarearchitektur. Allein ein Ort, an dem alles gesammelt zu finden ist, fehlte bisher. Das soll nun mit meinem neuen Blog The Architect´s Napkin - "Des Architekten Serviette" anders werden. (Sorry, ich sah mich genötigt, es auf Englisch zu verfassen, da ich nur so die Chance habe, eine größere Leserschaft zu finden, die vielleicht mit mir auch über dieses wichtige Thema und meinen Ansatz diskutiert.)

In dem Blog entwickle ich meine Ideen nochmal von Grund auf, fasse zusammen, was ich bisher schon geschrieben habe und füge dann natürlich auch Neues, Unveröffentlichtes hinzu. Die Reihenfolge ist dort lose - Theorie und Praxis werden sich abwechseln -, aber der Fokus ist klar. Ich habe sozusagen meine Blog-Aktivitäten ein weiteres Mal partitioniert bzw. refaktorisiert. So steigt die Kohäsion, die thematische Nähe in den jeweiligen Blogs.

Unmittelbaren Anstoß für diese Aktion war die Lektüre von "The Back of the Napkin", das mit klar gemacht hat, wie wichtig Visualisierungen sind und wie wichtig darüber hinaus einfache Visualisierungen sind. Denn Architektur scheint auch immer schwieriger als nötig wahrgenommen zu werden, weil eine diffuse Angst herrscht, ob man denn auch alle Darstellungsansprüche erfüllen kann.

Dem und jedem anderen Nimbus von Softwarearchitektur als Elfeinbeinturmkunst werfe ich deshalb mit einer sehr konsequent minimalistischen Darstellungsweise entgegen: alle Architekturdiagramme finden Platz auf einer Serviette.

Das sieht dann z.B. so aus

oder so

Des Gedanke dahinter: Wenn etwas nicht auf eine Serviette in übersichtlicher Weise passt, dann ist es schon zu kompliziert. Architekturdiagramme sollen nicht nur gezeichnet, sondern vor allem verstanden werden. Deshalb sollten Softwarearchitekten darauf achten, ihre Gesprächspartner nicht mit visuellen und konzeptionellen Details zu überfordern.

So meine These, die ich versuchen werde, mit meinem Blog zu bestätigen. Ich würde mich freuen, wenn Sie mitlesen und mitdiskutieren würden. Bis bald bei...

The Architect´s Napkin

OOP 2008: Zurück zum Papier - Leseempfehlungen für 2008

Das gute, alte Papier hat mich wieder.

Ich habe gerade ein Abo der "Traditionszeitschrift" aller Softwareentwickler bestellt, dem Dr Dobb´s Journal. Nicht obwohl, sondern weil es nicht .NET-lastig ist.

 

 

 

Und dann habe ich heute gleich noch ein Abo des in Deutschland recht unbekannten, aber nicht minder guten CoDe Magazines drauf gelegt. Das bietet immer wieder sehr gute Artikel zum Thema .NET.

 Neulich hat es mich auch überkommen und ich habe endlich auch das MSDN Magazine, die Entwicklerpostille von Microsoft, geordert. Die gibt es zwar auch monatlich kostenlos im Internet - aber was soll´s? Der USD steht grad so günstig.

Und völlig im Rausch habe ich mir Ende 2007 dann auch noch - quasi als Weihnachtsgeschenk - eine Mitgliedschaft bei der "Association of Computing Machinery" (ACM) gegönnt. Die haben ein exzellentes online Archiv wissenschaftlicher Artikel zu allen Informatikthemen der letzten Jahrzehnte. Da findet sich immer mal wieder sehr interessantes Hintergrundmaterial. Damit lege ich sozusagen mein Ohr an die Grasnarbe der Informatik. Das ist der ultimative Blick über den Tellerrand in die Forschung hinein. Die ACM-Hauszeitschrift "Communications of the ACM" bringt mir jeden Monat einen bunten Blumenstrauß an Themen ins Haus, die ich in den anderen sehr praxislastigen Publikationen nicht finde.

Aber damit nicht genug! Das sind ja nur meine neuesten Zeitschriftenerrungenschaften. Ohnehin schiebt mir der Postbote jeden Monat die dotnetpro, das dot.net Magazin und das OBJEKTspektrum durch den Schlitz. Und um auch mal etwas ganz anderes zu lesen, lasse ich auch noch brandeins jeden Monat in meinen Postkasten brummen.

Puh. Ganz schön viel zu lesen. (Ganz zu schweigen von den Bücherbergen an meinem Nachttisch...) Aber so spannend, so interessant. Naja, nicht immer alles in allen Publikationen... Aber genug, um durchgängige alle zu beziehen.

Damit komme ich zu meiner neuen Lesegewohnheit Nr. 1 für 2008: Ich werde konsequent nur noch das lesen, was 1. für mich relevant ist, d.h. zu meinen Arbeitsschwerpunkten .NET-Softwarearchitektur/-Test/-Softwareproduktion und "Softwarekollaboration" gehört. Darüber hinaus lese ich dann noch das, was 2. mein Interesse auf den ersten Blick erregt. Und das meine ich so: auf den ersten Blick. Ich werde mich nicht reinknien und lange überlegen, ob ich etwas lesen sollte, sondern zur Abwechslung mal mein Gefühl entscheiden lassen ;-)

Daraus ergibt sich dann direkt meine neue Lesegewohnheit Nr. 2: Ich beende die Lektüre einer Zeitschrift, wenn ich alle Artikel gem. Lesegewohnheit Nr. 1 gelesen habe. Dabei ist es egal, ob das 2 von 20 oder 18 von 20 waren. Ich habe keine Skrupel mehr, fast ungelesene Zeitschriften wegzuschmeißen. Insbesondere die wunderbaren online Archive von dotnetpro, Dr. Dobb´s, MSDN Magazine, CoDe Magazine, CACM und brandeins machen es mir leicht, die Zeitschriften wirklich in den Müll zu tun, statt Regalmeter damit zu füllen.

So erklärt sich auch meine Lesegewohnheit Nr. 3: Falls ich aus irgendeinem Grund selbst die nach Nr. 1 ausgewählten Artikel nicht bis zur nächsten Ausgabe geschafft haben sollte, dann schmeiße ich die Zeitschrift trotzdem weg. In diesem Punkt habe ich lange mit mir gerungen. Es schien mir nicht respektvoll gegenüber den Publikationen, sie nicht zu lesen, wenn ich sie schon habe. Und ich hatte das latente Gefühl, etwas zu verpassen. Aber beide Gefühle habe ich nun aufgegeben. Sie entstammen einer langen Prägung durch Mangel, wie er im Grunde immer herrschte - bis heute. Noch bis Ende der 1990er haben wir an Informationsmangel der einen oder anderen Art gelitten. Aber das ist nun endgültig vorbei.

Weder bin nicht respektvoll gegenüber den Publikationen, denn sie sind ja auch, wenn das Papier schon im Mülleimer ist, immer noch online zugänglich. (Naja, alle bis auf zwei ;-) Ich schmeiße also nur eine Manifestation der Arbeit der Autoren in den Müll, nicht deren Arbeit. Auf die kann ich weiterhin zugreifen.

Und auch das Gefühl des Verpassens ist überflüssig. Denn erstens kann ich alles in den online Archiven dann doch noch lesen. Ich verpasse höchstens etwas auf Papier. Zweitens aber - und das ist die für mich viel wichtigere Erkenntnis - ist heute nicht mehr der Artikel A in Ausgabe N der Zeitschrift Z wichtig. Er mag interessant sein, aber nicht wichtig. Denn angesichts des Contentüberflüsses, in dem wir heute bis zum Hals stehen, sind Themen nicht mehr mit einzelnen Veröffentlichungen gleichgesetzt. Klar, es mag ein Thema besonders gut in einer bestimmten Veröffentlichung behandelt sein. Eine konkrete Veröffentlichung ist natürlich auch immer die erste, die ein Thema aufreißt. Aber durch die Veröffentlichungsflut ist gewährleistet, dass wirklich wichtige Themen (langsam, aber sicher) auch zu mehreren Veröffentlichungen führen. Ich kann sie also auf Dauer nicht übersehen.

Insofern lehne ich mich ganz beruhigt zurück und vertraue auf Lesegewohnheit Nr. 1. Damit bleibe ich zu meinen Themen auf dem Laufenden. Und ich habe die Garantie, auch auf Inspirationen zu stoßen. Wenn nicht in dieser Ausgabe, dann in der nächsten oder übernächsten... Es gibt keinen Mangel an Inspirationsquellen. Also muss ich sie nicht suchen und sammeln, sondern kann mich an ihnen laben, wenn mir danach ist. Und da vertraue ich mal auf mein Gefühl beim ersten Blick.

Jetzt noch zu Lesegewohnheit Nr. 4: Ich lese wieder mehr auf Papier. Am PC lesen ist nett für das ad hoc Lesen, z.B. von Email oder einen Überblick. "Lesen zwischendurch" tue ich gern am PC. In elektronischen Inhalten kann ich leichter suchen und ich kann mich mit Links durch Inhalte hangeln. So kann ich entweder sehr gezielt auf Stoff zugreifen oder genau das Gegenteil tun: mir ein Themenfeld grob erschließen, indem ich wie mit dem Finger auf der Landkarte das Terrain schnell und aus großer Höhe vorerkunde.

Um dann aber eine Publikation von mehreren Seiten wirklich zu lesen, brauche ich Papier. Ja, immer noch. So sehr ich ein Freund von online Publikationen bin (ich schreibe ja immerhin auch dieses Block), so ist das Lesen von Publikationen immer noch etwas anderes.

Erstens sind Texte auf Papier immer noch besser zu lesen, als am Bildschirm. Daran ändern auch Amazon´s Kindle und die hübsch wie funktional aufbereitete digitale Ausgabe der CACM nichts.

Zweitens sind Texte auf Papier immer noch mobiler. Sie sind leichter und in der Form flexibler. Ich kann sie in eine kleine Tasche stecken oder am Frühstückstisch lesen. Selbst mit meinem 12" Laptop wäre das mit elektronischen Texten nicht so leicht.

Beide Gründe zusammen genommen - dazu noch der vorteilhafte USD-Kurs - waren für mich nun genug Anlass, das Jahr 2008 mit einer "Abo-Manie" zu beginnen. Denn die Abos liefern mir ohne weiteren Aufwand Inhalte auf Papier für´s leichte Lesen. Ich muss mir keine Gedanken über´s Wegschmeißen machen, da (fast) alle Inhalte auch noch komplett online verfügbar sind. Dafür bezahlte ich auch gern die Abo-Gebühr. Und schließlich ist es angenehmer, eine Zeitschrift in der Hand zu halten, als die ewigen doppelseitigen FinePrint-Ausdrucke.

PS: Ach ja, bevor ich es vergesse, es gibt noch eine Lesegewohnheit Nr. 5: Mehr redaktioneller Inhalt. Ich abonniere in Zukunft weniger Blogs in meinem RSS-Reader. Ein paar werden übrig bleiben von Autoren, die ich schätze und die sich wirklich kontinuierlich Mühe geben. Dazu zähle ich z.B. Jeff Atwood, Joel Spolsky oder Martin Fowler. Für die ist ein Blog keine Nebensache. Sie kippen nicht nur Datenschnippsel ins Internet. Dort findet vielmehr öffentliches Nachdenken über unsere "Kunst" statt. Für "Tipps & Tricks" von einer Produktgruppe in Redmond oder auch zum Thema XYZ abonniere ich kein Blog mehr. Schön, dass es auch solche Blogs gibt - aber für mich ohne Abo. Wenn ich mal Bedarf habe an solchen Inhalten, dann stolpere ich schon mit Google darüber.

Je technischer also ein Blog, desto weniger "abowürdig" ist es für mich. Oder besser: je weniger unmittelbar relevant für meinen Arbeitsschwerpunkt ein Blog ist, desto weniger "abowürdig" ist es. Denn wenn ich den ganzen Tag WinForms-Programmierung machen würde, dann würde ich auch ein technisches WinForms-Blog abonnieren - sofern das Blog für den Autor keine Nebensache ist und er sich Mühe gibt.

Der bewusste Umgang bei der Produktion von Inhalten wird mir immer wichtiger. Der, der produziert, soll mir Arbeit abnehmen, indem er filtert. Das ist insbesondere bei den Zeitschriften der Fall. Also lese ich mehr davon, statt unredigiertes im Web. Dafür ist mir meine Zeit zu schade. Wirklich Wichtiges kann ich ja auch bei den Zeitschriften nicht verpassen (s.o.).

So, jetzt aber genug für heute. Die Abos sind bestellt... Upps, eines habe ich noch vergessen Microsofts Architektur-Journal zu ordern. Das gibt es kostenlos auf Papier. Vier Mal im Jahr. Da kann ich nicht Nein sagen, oder? ;-)

WCF Literaturhinweise

Der ganze Indigo-Hype ist an mir früher genauso vorbeigegangen wie es heute der Orcas-Hype tut. Ich habe einfach keine Zeit, mich mit Technologien zu beschäftigen, die so wenig real sind und noch so unbestimmt weit in der Zukunft liegen. Vielen von Ihnen wird es nicht anders gehen.

Jetzt aber ist Indigo real und heißt Windows Communication Foundation (WCF) und ist echt cool geworden. Und jetzt lohnt es sich auch, sich damit näher auseinanderzusetzen. Auch ich habe mich deshalb auf den Weg durch das WCF-Labyrinth gemacht. Wie bei Jules Vernes "Reise zum Mittelpunkt der Erde" stellt sich dabei allerdings die Frage: Wo einsteigen in die unterirdischen Gänge? Was ist der Snaeffellsjökull für die Reise durch WCF? Welche Gänge sind anschließend zielführend? Was gibt es überhaupt zu entdecken? WCF ist ja so groß, so groß.

Nachfolgend finden Sie quasi meine Expeditionsaufzeichnungen, d.h. die Literaturstationen, die ich auf meiner Reise durch WCF als hilfreich empfunden habe. Vielleicht helfen sie Ihnen ja auch beim Einstieg in das Thema. Google macht am Ende zwar recht glücklich bei der Wegfindung - aber braucht viel Zeit. Ich würde mich also freuen, wenn Ihnen diese Quellenliste Zeit sparte.

Aber Achtung: Meine kleine Landkarte für WCF erhebt keinen Anspruch auf Vollständigkeit. Sie ist subjektiv, d.h. geprägt von meinen persönlichen Interessensgebieten in Bezug auf WCF. So bekümmere ich mich z.B. nicht um Aspekte der plattformübergreifenden Kommunikation. Aber auch zu meinen Interessengebieten sind natürlich nicht alle Quellen zu finden, weil es erstens eine unüberschaubare Vielzahl gibt und zweitens nicht alle lesenswert sind.

Wenn Sie nun mit diesen Einschränkungen leben können oder - positiver ausgedrückt - meinen Fokus teilen, dann wünsche ich viel Spaß beim Lesen:

WCF Ressourcen

• Windows Communication Foundaton, MSDN
• Windows Communication Foundation, MSDN Library
• .NET 3.0 Community
• .NET 3.0 Download
• MSDN Magazine "Service Station" Kolumne
• Christian Weyers Blog "Smells like service spirit"

WCF Einführungen und Überblicke

Bücher

• Juval Löwy, Programming WCF Services, O'Reilly 2007
  Scheint mir derzeit die umfassendste Darstellung von WCF zu sein. Sehr detailreiche Darstellung, für einen ersten Einstieg im Grunde zuviel. In jedem Fall aber ein must-have als Nachschlagewerk. Gut gefallen hat mir der Versuch am Ende des Buches, "WCF Coding Standards" aufzustellen, d.h. knackige Dos and Donts zu formulieren.
  Die Kehrseite der Medaille ist, Juvals Darstellung ist zu einem großen Teil feature fucking. WCF wird weitestgehend ohne Anwendungszusammenhang dargestellt; der Leser wird mit dem Transfer in die Praxis, d.h. mit dem Abwägen der vielfältigen Optionen alleingelassen. Auch kann man geteilter Meinung darüber sein, ob Juval das Thema konzeptionell optimal angeht. Seine Beschreibungen lassen eine, hm, gewisse Verhaftung mit der guten alten COM+/Enterprise Services Welt vermuten. Die Andersartigkeit echt nachrichtenorientierter Kommunikation im Gegensatz zum RPC-orientierten Umgang mit verteilten Objekten wird nicht wirklich thematisiert.
  Insofern ist Juvals Buch vielleicht nicht das beste, aber zumindest derzeit das kleinste Übel. Ich habe es jedenfalls gern gelesen.
  
• Ralf Westphal, Christian Weyer, .NET 3.0 kompakt, Spektrum Akademischer Verlag 2007
  Mein eigenes Buch, das ich zusammen mit Christian geschrieben habe, empfehle ich nicht, weil es eben unser Buch ist, sondern weil es mir wirklich beim Einstieg in WCF geholfen hat. Ich hatte für meine ersten Gehversuche nach Beispielen gesucht, die kleinschrittig sind - und sie bei Christian gefunden. Darüber hinaus bietet das Buch aber natürlich noch mehr... ;-)

Andere Darstellungen in Buchform zu WCF habe ich auch durchgesehen (z.B. von MSPress, Apress, Wrox), war aber nicht überzeugt. Den Detaillierungsgrad von Juvals Buch erreichen sie nicht. Und sie gefallen mit vom Layout her auch nicht genauso gut wie Juvals. Oft ist die Schrift groß und die Informationsmenge pro Seite klein. Das macht auf mich dann den Eindruck, der Verlag hätte vor allem ein dickes Buch im Auge gehabt, um einen hohen Preis verlangen zu können, und nicht unbedingt ein inhaltsreiches.

Artikel

• Laurance Moroney, The Windows Communication Foundation: A Primer, DevX.com 10/2005
• Aaron Skonnard, Learn the ABCs of Programming Windows Communication Foundation, MSDN Magazine 2/2006
• Clemens Vasters, Introduction to Building Windows Communication Foundation Services, MSDN Online 2005
• Dennis van der Stelt, WCF Part 0: Introduction, Dennis´ Blog 10/2006
• Ralf Westphal, A truely simple example to get started with WCF, Ralf´s Sudelbücher 5/2007
• Christian Weyer, Windows Communication Foundation, dotnetpro 1/2006
• Christian Weyer & Ralf Westphal, dotnetpro.tv #16 - Windows Communication Foundation, dotnetpro 6/2006

WCF Details

• Juval Löwy, WCF Transaction Propagation, MSDN Magazine 5/2007
• Juval Löwy, What you Need to Know About One-Way-Calls, Callbacks, And Events, MSDN Magazine 10/2006
• Juval Löwy, Discover Mighty Instance Management Techniques For Developing WCF Apps, MSDN Magazine 6/2006
• Aaron Skonnard, WCF Addressing in Depth, MSDN Magazine 6/2007
• Aaron Skonnard, WCF Messaging Fundamentals, MSDN Magazine 4/2007
• Aaron Skonnard, Serialization in Windows Communication Foundation, MSDN Magazine 8/2006

BizTalk Connectivity Services [home]

• Clemens Vasters, TweetieBot - A BizTalk Services Experiment, Clemens Vasters´ Blog 5/2007
• Clemens Vasters, Some fun with the BizTalk Services ISB, Clemens Vasters´ Blog 5/2007
• Christian Weyer, Cannot get latest BizTalk Services SDK (May 2) working?, Christians Weyers Blog 5/2007
• Christian Weyer, When you think things are not possible: WCF duplex callbacks through NATs and firewalls - safe and secure, Christian Weyers Blog 4/2007

Themen im WCF Umfeld

• Juval Löwy, Volatile Resource Managed in .NET Bring Transactions to the Common Type, MSDN Magazine 12/2005
• Sahil Malik, System.Transactions: Implement Your Own Resource Manager, codeguru 11/2005

.NET 3.0 kompakt - Mein neues Buch ist da!

Endlich ist es nun herausgekommen. Die neue Auflage oder eher die komplette Überarbeitung meines ersten Buches: .NET kompakt.

Anlässlich des .NET 3.0 Release haben Christian Weyer und ich es unternommen, sozusagen die entscheidenden "Neuzugänge" beim .NET Framework von Version 2.0, 3.0 und auch schon darüber hinaus wieder einmal von einem recht grundlegenden Blickwinkel aus zu beschreiben.

.NET 3.0 kompakt

Ralf Westphal, Christian Weyer

Spektrum Akademischer Verlag, 2007, ISBN 382741458X

221 Seiten, 17 EUR

Klappentext:

.NET hat sich als Plattform etabliert. Dennoch ist Orientierungshilfe für .NET nötig, denn die Plattform wächst kontinuierlich. ".NET 3.0 kompakt" arbeitet deshalb die großen Strömungen in der Entwicklung der .NET-Sprachen und -APIs heraus. Das daraus entstehende big picture hilft Ihnen einzuschätzen, welche Bedeutung .NET für Ihre Projekte heute und in Zukunft haben wird. Die Autoren erklären Ihnen die grundlegenden Konzepte der Plattform; dabei geht es nicht um technische Details, sondern um die Zusammenhänge in einer komplexen technologischen Landschaft. ".NET 3.0 kompakt" beantwortet Fragen wie:

-Was ist neu bei C# 2.0 und VB8 und warum wurden gerade diese Features eingeführt?

-Was steckt hinter WCF, WPF, WF, Windows CardSpace, Linq, Generics?

-Welchen Einfluss haben die neuen Plattform-Features auf die Architektur von Software?

-Wie sieht die Zukunft der .NET-Plattform aus?

Viel Spaß beim Lesen!