Bessere Prozesse für den Rest von uns

Die “Gurus” können es. Die können ihr TDD, OOP, XP, Scrum usw. Aber was ist mit dem Rest der Entwicklergemeinde?

In den meisten Teams gibt es auch einen, der es kann. Einen der ansagt. Aber was ist, wenn der mal ausfällt? Was ist mit dem Rest des Teams.

Mein Eindruck ist, wir verlassen uns noch zu sehr auf “Gurus”, “Meister” und “starke Persönlichkeiten”. Die bestimmen unsere Arbeit. Entweder verteilen sie sie. Oder sie definieren Methoden auf ihrem Level – die dann Normalsterbliche nur schwer selbst in ihren Arbeitsalltag transferieren können.

Wie anders ist es zu erklären, dass zum Beispiel TDD nach 10 Jahren immer noch kein Standard ist? Wie anders ist es zu erklären, dass Entwurf mit der UML nach mehr als 10 Jahren immer noch kein Standard ist? Mit Standard meine ich so etwas wie “Bei 80% der Entwickler akzeptiert und in täglichem Gebrauch.”

Ich behaupte nicht, dass TDD oder UML schlecht seien. Fragt sich nur, wem sie real helfen. Ich sehe einfach eine große Differenz zwischen Anspruch und Implementation. An der Verfügbarkeit von sprachgewandten Verkündern dieser und anderer Techniken oder Literatur darüber kann es nicht liegen. Woran dann?

Eine Folie in einem Vortrag von Sam Aaron hat mich darauf gebracht:

Sam hat eine Geschichte von Schachgroßmeister Gary Kasparov erzählt: Nachdem Kasparov gegen IBMs Deep Blue verloren hatte, hat er den Gegner Computer nicht verteufelt. Er hat ihn umarmt und versucht, mit Hilfe von Software insgesamt zu einem besseren Spieler zu werden. Er hat sich von Software beim Schachspiel sozusagen beraten lassen. Damit hat er dann jeden der willig war herausgefordert. Und geschlagen wurde Kasparov von zwei Unbekannten.

Darauf bezieht sich das Zitat. Kasparov war überrascht, dass ihn, den Großmeister (strong human), der sich auch noch von einer Maschine unterstützen ließ, zwei Nobodys in Schachdingen (weak human) übertreffen konnten, die sich auch von einer Maschine unterstützen ließen. Sein Schluss daraus: Sie hatten einen “better process”, mit dem sie gearbeitet haben.

Wenn mir eines immer bewusster geworden ist in den letzten Jahren, dann ist das die Begrenztheit der Möglichkeiten zu Veränderungen in Teams. Alle sind nämlich heute am Limit. Inwiefern das selbstverschuldet oder schlechtem Management anzuhängen ist, lasse ich mal dahingestellt. Es ist einfach so. Damit müssen wir leben.

Außerdem ist die Ausbildung von Softwareentwicklern immer noch (oder inzwischen?) schlecht. Nicht überall natürlich, aber weitestgehend.

Unterm Strich bedeutet das, Software wird vor allem von “weak humans” geschrieben. Wir brauchen daher Techniken, Methoden, Konzepte für diese “weak humans”. Das bedeutet, sie müssen sehr explizit und konkret sein. Sie müssen stark an die Hand nehmen. Sie müssen in kleinen Schritten zwischendurch erlernbar sein. Sie müssen in einer Welt voller legacy code und mittelalterlichem Management “bootstrapfähig” sein.

Das sage ich mit einer guten Portion Selbstkritik. Was Stefan Lieser und ich unter www.clean-code-developer.de zusammengetragen haben, entspricht dieser Forderung auch nicht immer. Und auch der Flow-Design Ansatz kann noch darauf zugefeilt werden.

Insgesamt jedoch habe ich in dem Kasparov-Zitat meinen Anspruch formuliert gefunden: Ich bemühe mich und will mich noch mehr bemühen, “normalsterblichen” Entwicklern zu helfen. Die große Zahl “weak humans” ist meine Zielgruppe. Für sie muss ich versuchen, was immer ich beschreibe, verständlich und nützlich zu machen.

Und ich glaube, danach sollten wir in der Branche insgesamt mehr streben. Wir müssen erkennen, dass die Softwarekrise nur mit mehr Entwicklern bewältigbar ist. Das führt allerdings fast notwendig dazu, dass deren allgemeines Ausbildungsniveau nicht steigt. Also sind Veränderungen im Alltag nur erfolgversprechend, wenn sie “weak humans” und “weak teams” und “weak companies” adressieren.

Damit will ich niemanden von einer (Selbst)Verantwortung zum Lernen und Streben nach Verbesserung entheben. Es geht mir vielmehr um die Anerkenntnis der schwierigen Umstände in und um Teams. Wir reden ja bei all den zitierten Methoden vor allem darüber, “Softwareherstellungsmaschinen” während des Laufens umzubauen. Und das ist eben schwierig. Da müssen wir bescheiden werden. Wir müssen auch sensibel werden für die Grunde, warum diese Methode oder jener Ansatz nicht so fruchtet, wie wir es uns vorstellen. Liegt das wirklich an unfähigen Entwicklern – oder sollten wir häufiger selbstkritisch sein und schauen, wo Methode und Ansatz verbessert werden können?

Als Lohn der Mühe winkt gem. Kasparov, dass noch bessere Methoden und Prozesse als heute diese “weak humans” in die Lage versetzen, bessere Software zu schreiben, als die heutigen “Meister” mir ihren Helfern es können. Ist das nicht ein attraktives Ziel, das wir versuchen sollten zu erreichen?

Wo Erfolge heute zu verzeichnen sind, ist das selbstverständlich toll. Aber wir sollten uns von diesen Erfolgen nicht einlullen lassen. Sie können unversehens zum Feind des Besseren mutieren. Das wäre doch schade, oder?

Also: Es gibt keine Methode, kein Konzept, keine Technik, keine Technologie, die nicht noch besser, vor allem einfacher gemacht werden könnte - und somit für “weak humans” leichter zu adaptieren ist. Usability ist auch hier Trumpf.

Experiment Selbstverlag - Mein erstes Kindle-Buch

Mein neues Buch ist endlich erschienen:

Systematisch produktiver und zufriedener
Pragmatische Schritte raus aus der Überlastung am Arbeitsplatz

Als Kindle-Buch bei amazon. Hurra, geschafft, endlich, nach ein paar Anläufen.

Vor Jahren hatte ich ja schon einige Bücher geschrieben, Bücher auf Papier, pBooks. Da gab es allenfalls zaghafte Versuche, die auch mal in PDF herauszubringen. Aber jetzt, knapp 10 Jahre später, ist alles anders. Heute sind Bücher elektronisch gleichwertig, eben echte eBooks. Und deshalb sind Produktion und Veröffentlichung anders möglich. Einen Verlag braucht man dafür nicht mehr – höchstens für das Marketing.

Und so habe ich mich mal aufgemacht, ein eBook im Selbstverlag herauszubringen. Bei diesem Experiment geht es mir um die Form und den Prozess, weniger um den Inhalt. Deshalb ist der Inhalt auch eine Zweitverwertung von Blogartikeln. Das soll aber natürlich den Wert des eBooks nicht schmälern, denn als Zusammenfassung für bequemes Lesen in einem Stück und aufbereitet für eReader bietet es etwas fürs Geld.

Insofern ist das eBook natürlich auch ein Experiment in puncto Monetarisierung von Inhalten. Ja, das will ich nicht verschweigen. Es geht auch ums Geld. Warum auch nicht?

Allerdings finde ich die Monetarisierung über Werbung sehr unschön. Sie mag funktionieren, doch hat sie für mich den Beigeschmack des Unehrlichen. In ihr steckt auch immer der latente Keim von Prostitution. Aber ich will nicht abschweifen… ;-)

Ohne Einnahme von Geld durch Werbung bleibt für die Monetarisierung nur eine direkte Transaktion mit dem Leser. Aber wie? Für Blogbeiträge ist das auch im Jahr 2012 immer noch schwierig. Das hat weniger mit Technik zu tun, würde ich sagen, sondern eher mit mangelndem “Standard”. Paypal mögen viele nicht, bei Micropayment-Diensten wie Flattr will sich niemand so recht auch noch anmelden…

Und dann stellt sich auch noch die Frage, ob jemand für das Medium “HTML-Seite” etwas bezahlen möchte? Das fühlt sich nicht sehr wertig an, oder? Jedenfalls nicht, wenn man für einzelne Inhalte zahlen soll und für andere wieder nicht. Als Abo mag das irgendwie noch funktionieren und so können Zeitungen sich langsam hinter Paywalls zurückziehen. Für Autoren ist das jedoch keine Option.

amazon als Veröffentlichungsplattform

Aber es gibt ja amazon! Da kommt für Autoren dreierlei zusammen:

• Erstens haben wahrscheinlich 99% aller Leser schon einmal bei amazon gekauft. Es gibt also keine Anmeldehürde zu überwinden, um Geld fließen zu lassen.
• Zweitens hat amazon es Autoren vergleichsweise sehr leicht gemacht, Inhalte anzubieten.
• Und drittens ist das Kindle-eBook-Format derzeit nach meinem Empfinden das für den Leser einfachste [1].

Bis sich einfache (Micro)Payment-Lösungen per Smartphone durchgesetzt haben, scheint mir amazon für Autoren der einfachste Weg, zu einem direkten, ehrlich Austauschverhältnis mit dem Leser.

Für einen Beitrag wie diesen, ist Monetarisierung natürlich keine Option. Abhängig von Umfang und Inhalt wird es immer Inhalte geben, die Blogger/Autoren im Allgemeinen und ich im Speziellen kostenlos anbieten. Für Umfangreicheres jedoch glaube ich daran, dass der Trend zu einer Monetarisierung gehen wird. Das schmeckt dann nicht jedem Leser – aber das ist ok. Mit denen, die übrig bleiben und sich darauf einlassen, habe ich gern ein engeres Verhältnis, das mehr auf Gegenseitigkeit beruht.

Doch das ist derzeit noch weitgehend Theorie. Zuerst mal ausprobieren, wie das überhaupt technisch und vom Prozess her geht mit dem Selbstverlegen.

Vorgehen bei der Veröffentlichung

amazon macht das wirklich sehr simpel. Einfach bei Kindle Direct Publishing (KDP) anmelden und Manuskript hochladen.

Das Manuskript kann in Word geschrieben werden. Einfach ein paar simple Formatierungsregeln beachten [2]. Dann ist das kein Problem.

Allerdings aufpassen mit Bildern. Da mögen ein paar Experimente angezeigt sein, je nachdem um was für Abbildungen es sich handelt, Grafiken oder Fotos. Am Anfang habe ich dafür ein kleines Testdokument mit Bildern in verschiedenen Auflösungen zusammengestellt und bei KDP immer wieder nach Veränderungen hochgeladen.

Auf der KDP-Seite gibt es eine Vorschau, die verschiedene Kindle-Reader simuliert, und einen Download für das Manuskript als .mobi-Datei. Statt auf die Simulationen habe ich mich dann lieber auf mein iPad verlassen :-) Damit kann ich auch in Abbildungen reinzoomen, um die Qualität zu überprüfen.

Am Ende habe ich die meiste Zeit in Word für Mac OS X gearbeitet und die Grafiken nur mit 72dpi Auflösung eingebunden. Nur am Schluss habe ich Word für Windows angeworfen, um das Inhaltsverzeichnis einzusetzen – das macht WinWord nämlich besser mit Verweisen auf die Kapitel – und für den Export nach HTML – auch der scheint subtil besser zu sein als bei MacWord.

Beim Titelbild ist dann noch etwas Kreativität gefragt. Kann man selbst machen, wie ich es getan habe. Aber ein Profigrafiker würde dafür auch kein Vermögen in Rechnung stellen. Mit einem einfarbigen Titelbild sollte man sich in jedem Fall nicht zufrieden geben ;-)

Nach dem Hochladen des finalen Manuskripts hat es dann nochmal 2 Tage gedauert, bis das Buch im amazon Shop zu sehen war. Das mag daran gelegen haben, dass ich es an einem Sonntag abgeschickt hatte. Dazu kam dann allerdings auch noch eine Nachfrage von amazon, die Material im Buch entdeckt hatten, das frei im Web verfügbar ist. Ja, wie denn auch nicht. Es sind ja meine Blogartikel :-) Da musste ich nochmal bestätigen, dass ich der Copyright-Inhaber bin.

Preisfindung

Ein bisschen hat mich noch die Preisfrage umgetrieben. Wie viel “darf” so ein eBook kosten? 0,99 EUR oder 1,49 EUR oder 2,68 EUR oder 5,79 EUR oder 8,45 EUR? Ich habe mich für den niedrigsten Preis entschieden, der mir als Autor noch 70% vom Nettoverkaufspreis bringt. Das ist ein Experiment. Runtergehen kann ich eher mit dem Preis, als ihn rauf zu setzen.

Einen einzelnen Artikel kann man bei vielen Zeitschriften online als PDF für 0,99 EUR oder 1,50 EUR kaufen. Das sind dann vielleicht 4-5 Heftseiten, also ca. 8-9 A4 Seiten. Mein eBook enthält aber rund 30 A4 Seiten, also ca. 3-4 Mal so viel wie ein Artikel. Deshalb denke ich, dass 2,68 EUR Verkaufspreis angemessen sind.

Ein anderer Vergleichsmaßstab ist für mich – wie auch im Klappentext angedeutet – der Preis eines Stückes Kuchen oder ein Heißgetränk im Coffeeshop. Da geben wir alle ohne zu zucken 2,50 EUR oder auch weit mehr aus, um uns einen sehr flüchtigen Genuss zu verschaffen. Insbesondere wenn wir “to go” wählen, leistet der Coffeeshop nicht mehr, als einen Becher auszugeben. Wir nutzen keine weitere Infrastruktur. So schlappen wir durch die Gegend mit 2,50 – 4,90 EUR in der Hand, die in 15 Minuten im Magen verschwunden sind. Für eine ganze Stunde “Genuss” würden wir mithin 15,00 – 20,00 EUR ausgeben – das ist mehr als im Kino. Selbst “Rauchgenuss” ist viel billiger.

Ich gebe auch Geld aus für solche modernen Heißgetränke. Dabei sitze ich jedoch meist in meinem Lieblings-Coffeeshop. Ich bezahle deshalb eher für die “Aufenthaltsmöglichkeit” als das Getränk. Aber einerlei. Wenn ich bereit bin, für solch flüchtigen Genuss soviel Geld auszugeben, dann finde ich es nicht zu hoch gegriffen, für 45 – 60 Minuten Lesestoff 2,68 EUR anzusetzen. Vor allem, wenn der Lesestoff auch noch den Anspruch hat nachzuwirken; ich hoffe ja, beim Leser etwas mit dem eBook-Inhalt zu bewirken.

Aber, wie gesagt, das mit dem Preis ist ein Experiment. Für Musik haben sich inzwischen 0,99 EUR pro Titel eingebürgert. Dafür bekommt man 3 – 6 Minuten Ohrenschmaus. Bei eBooks müssen wir noch herausfinden, wo Käufer und Leser möglichst reibungsfrei zusammenfinden.

Nach dem Experiment…

…ist vor dem Experiment. Mein Kindle-Experiment habe ich erstmal abgeschlossen. Von der Idee bis zur Verfügbarkeit des eBooks im amazon Shop hat es 6 Tage gedauert – davon 2 bei amazon.

Aber das Selbstverlegen ist damit nicht zuende. So ist das Buch nur bei amazon erhältlich. Wie kriege ich es denn aber auch noch auf andere Plattformen oder auf Papier – für die, die das dringend wollen?

Es sind also noch einige weitere Experimente nötig. Mit CreateSpace bietet amazon einen Weg zum Papier. Alternativ könnte ich mich aber auch für lulu.com oder epubli.de entscheiden. Und was ist mit anderen eBook-Plattformen? Wer den lokalen Buchhandel unterstützen möchte, hätte es lieber, ein eBook über einen anderen Kanal zu kaufen, bei dem auch sein Buchhändler etwas davon hat. Vielleicht probiere ich mal bookrix.de als Vermittler aus.

Und natürlich werde ich beim Inhalt experimentieren. Zweitverwertung als eBook finde ich völlig in Ordnung. Doch ich will auch neue Inhalte für eBooks schreiben.

Endnoten

[1] Kindle-Reader gibt es als Gerät und Apps für jede Plattform. Die Übertragung des eBooks auf Gerät/App ist ein no brainer. Und der Lesefortschritt sowie die Notizen werden über Gerät/App hinweg synchronisiert. Diese Einfachheit bietet derzeit sonst kein Anbieter, nicht Thalia mit textunes und auch nicht libri mit seiner eBook Reader App. Und iTunes? Ist zwar für den Leser einfach, doch für den Autor schwierig. Ohne Vermittler, der mir das Administrative und auch die Abrechnung einfacher macht, würde ich da nichts einstellen.

[2] Es gibt einige Literatur im Web und bei amazon dazu, was es bei Kindle-Büchern zu beachten gibt, z.B.

• Publish on Amazon Kindle with KDP
• The Kindle Formatting Bible
• Kurzleitfaden zur Buchformatierung

Wenn Agilität abhebt

Ich bin ja ein großer Freund von agilem und schlankem Vorgehen in der Softwareentwicklung. Aber derzeit scheint mir die Agilität ein bisschen unbescheiden. Sie hebt immer mal wieder ab. So auch in diesem Artikel von Henrik Kniberg (meine Hervorhebung):

Was soll das denn? Vor 2000 wussten Softwareunternehmen nicht, wie man Software ausliefert? Ja, ist das so gewesen?

Und vor 2000 haben Unternehmen keine nützliche, funktionierende Software (“working software”) ausgeliefert, falls sie es denn überhaupt geschafft haben, welche aus der Tür zu bekommen? Ja, ist das so gewesen?

Ich hatte in den 1980ern und 1990ernn schon den Eindruck, mit “working software” zu arbeiten. Und ich habe mit meiner Branchensoftwarefirma 10 Jahre lang selbst “working software” ausgeliefert. Sonst hätten mein Partner und ich uns und unseren Angestellten kein Gehalt zahlen können. (Er liefert übrigens immer noch “working software” aus und lebt davon – obwohl er ganz unagil arbeitet.)

Dass etwas im Argen war mit der Art, wie wir in unserer Branchensoftwarebude Software entwickelt und ausgeliefert haben, ist unbenommen. Und es liegt auch heute noch viel im Argen bei dem, wie Software entwickelt wird. Natürlich bin ich dafür, dass mehr Teams, agil und/oder schlank werden.

Aber wir sollten doch bitteschön nicht verkennen, wie viel geleistet wird ganz ohne Agilität und Schlankheit. Die Softwareentwicklung hat nicht erst mit der Agilität angefangen. Und Agilität ist bei weitem nicht in alle Köpfe, Teams und Unternehmen bisher vorgedrungen. Sind deshalb die, die noch nicht agil oder schlank sind, Hinterwäldler und Dummköpfe? Kriegen die nichts gebacken?

Ein bisschen Bescheidenheit stünde der Agilitätsbewegung gut zu Gesicht, finde ich. Mit solchen Aussagen gewinnt man keine neuen Freunde. Eine abgehobene, arrogante Agilität nützt niemandem.

Und wie kann das Abheben vermieden werden? Ich glaube weiterhin, dass dafür eine glasklare Definition von Agilität nötig ist. Henrik Kniberg bleibt Sie trotz Link auf das agile Manifest schuldig. Und Martin Fowler weiß es nicht besser, sondern erkennt sie einfach, wenn er ihr mal begegnen sollte.

Ob Sie nun meiner persönlichen Definition von Agilität zustimmen oder ihre eigene haben… Wir sollten uns darüber unterhalten, was Agilität im Kern ausmacht. Dass mit ihr “working software” hergestellt werden kann, ist nichts Neues und nichts Besonderes. Ein bisschen mehr Butter bei die Fische darf schon sein.

Was ist also das klar umrissene Nutzenversprechen der Agilität, das sie vom Bisherigen abhebt? Wie kann Agilität einem gestandenen Geschäftsführer, der seit 20 Jahren nützliche und funktionierende Software an den Markt bringt und 20 Leute damit ernährt, in nicht arroganter Weise nahegebracht werden?

Und dann: Mit welchen Merkmalen, Hilfsmitteln, Methoden, Konzepten, Paradigmen versucht Agilität dieses Nutzenversprechen einzulösen? Warum sollen die funktionieren und nicht anderes?

Mein Empfinden ist, dass es bei all der Literatur zu Agilität noch Erklärungsbedarf gibt. Die Marketing-Arbeit der Agilisten ist nicht vorbei. Die Zeit für siegerhafte Arroganz ist noch nicht gekommen. Und sollte am besten auch nie kommen.

 

PS: Und dass das heutige Problem vor allem sei, das falsche Produkt zu bauen, halte ich auch noch nicht für ausgemacht. Sicherlich ist das ein nicht zu leugnendes Problem – nur hat das nicht speziell mit Softwareentwicklung zu tun. Für viel dringender halte ich das Problem mangelnder Evolvierbarkeit. Die Unwartbarkeit, das Brownfield, die Legacy Code Berge… sie drohen überall. Denn was will man denn machen, wenn man denn nun endlich weiß, welches Produkt man bauen will – und man kriegt es nicht hin? Dann ist das Händeringen umso größer. Deshalb: Ich bin dafür, zuerst die Bedingung für die Möglichkeit des richtigen Produktes anzugehen. Und das ist eine Codebasis, die sich in welche Richtung auch immer geschmeidig anpassen lässt.

Performance vom Schwanz her aufzäumen

Wer ist es eigentlich, der höhere Performance fordert? Der Kunde, ist doch klar. Den meine ich aber nicht. Mir geht es um etwas Grundlegenderes.

Wenn wir über Performance reden, dann haben wir ein Delta im Hinterkopf, eine Dauer zwischen zwei Ereignissen. Es geht um ein auslösendes Ereignis, an dem Input hängt, und ein abschließendes Ereignis, an dem Output hängt.

Das kann die Dauer zwischen der Eingabe einer URL und der Anzeige der Webseite sein; das kann die Dauer zwischen der Eingabe von Zahlen und der Anzeige einer Funktionskurve sein; das kann die Dauer zwischen dem Bewegen eines Mauszeigers und der Reaktion einer Figur auf dem Bildschirm sein.

Immer geht es um Delta = T_Ergebnis – T_Auslöser. Höhere Performance bedeutet, dass Delta kleiner wird.

Jetzt zurück zur Ausgangsfrage: Wer fordert denn aber, dass Delta kleiner wird?

Es sind zwei Rollen im Spiel: der Auslöser und der Empfänger. Der Auslöser startet die Verarbeitung, deren Performance in Frage steht. Er liefert den Input oder zumindest Teile davon; der Rest kann aus Zustand kommen, auf den die Verarbeitung Zugriff hat.

Der Empfänger andererseits ist derjenige, den das Ergebnis der vom Auslöser gestarteten Verarbeitung interessiert. Er betrachtet den Output und fällt daraufhin Entscheidungen. Output ist ein Unterschied, der für ihn einen Unterschied macht, d.h. Information.

Nun zum dritten Mal: Und wer interessiert sich nun für ein kleineres Delta? Immer nur der Empfänger.

Das ist mir heute aufgegangen. Es ist immer nur der Empfänger von Output, dem daran gelegen sein kann, den Abstand zum auslösenden Ereignis zu reduzieren, weil das irgendeinen Vorteil für ihn hat.

Es hat lange für mich gedauert, bis ich das begriffen habe. Bis heute. Jahr um Jahr hab ich geglaubt es sei der Auslöser, den Performance interessiert. Oder genauer: Ich habe Auslöser und Empfänger nicht einmal unterschieden. Sie sind oft dieselbe Person oder ich habe vor allem mit dem Auslöser als Kunde gesprochen.

Aber es gibt in Performancefragen immer beide Rollen und nur der Empfänger ist maßgeblich.

Das hat nun Auswirkungen auf die Performancediskussion, würde ich sagen. Denn eine Steigerung der Performance ist nur da relevant, wo ein Empfänger erstens eine Ahnung davon hat, wann das auslösende Ereignis vor dem Empfang stattgefunden hat. Oder es ist generell von Wert, dass das Delta zwischen Auslöser und Empfang klein ist, auch wenn unklar ist, wann das auslösende Ereignis stattgefunden hat. Beispiele:

• Sie sind Empfänger von Informationen über Bücher. Die Performance ist für Sie dabei vor allem wichtig, wenn Sie Auslöser der Beschaffung dieser Informationen sind. Sie stöbern bei amazon und wünschen sich natürlich möglichst zügig ein Abfrageergebnis. In dieser Doppelrolle ist Performance für Sie wichtig.
• Sie sind wieder Empfänger von Informationen über Bücher. Dieses Mal haben Sie jedoch keine Kontrolle über eine Auslösung. Das initiale Ereignis für eine Verarbeitung ist nicht eine Abfrage, sondern das Einpflegen von Titelinformationen. In diesem Fall interessiert Sie die Performance des online Shops nicht. Wenn überhaupt, machen Sie sich Gedanken über die Performance von amazon als Organisation mit ihren Prozessen.
• Jetzt sind Sie Empfänger von Adressinformationen in einer Faktura-Anwendung. Sie müssen Kunden mahnen. Was ist das für Sie auslösende Ereignis in Bezug auf Adressen? Das Einpflegen. Damit haben Sie nichts zu tun. Das macht eine andere Abteilung, z.B. der Verkauf, jedenfalls nicht die Buchhaltung. Wie lange das Softwaresystem also braucht, um eine Adresse “zu verarbeiten”, ist für Sie nicht wichtig.
• Auf der anderen Seite sitzt nun der Auslöser einer Adressveränderung. Ist der an der Performance einer Adressenspeicherung interessiert? Nein. Er ist ja nur Auslöser. Wenn er eine Datenänderung erfasst hat, will er nur schnell weiter zur nächsten Datenerfassung. Wie lange es dauert, bis eine Adressenänderung überall wirksam wird, ist ihm einerlei, da er kein Empfänger ist.
• Schließlich sind Sie Geschäftsführer einer Pizzakette. Sie sind Empfänger von Verkaufszahlen. Was ist Ihre Erwartung an die Performance der Unternehmenssoftware? Auf Ihre Abfrage wollen Sie schnell eine Antwort. Da sind sie sowohl Auslöser wie Empfänger. Aber der Auslöser einer Veränderung im Datenbestand sind Sie nicht. Sekunden- oder auch nur stundengenaue Auskunft müssen Sie nicht über die Zahlenentwicklung haben. Ihnen reichen die Zahlen des Vortages oder gar der Vorwoche.

Sie ahnen, worauf ich hinaus will. Ich möchte eine Lanze für mehr asynchrone Verarbeitung brechen. Und ich möchte dafür sensibilisieren, dass Performance im Auge des Empfängers liegt. Die Frage ist immer, was der für ein Verhältnis zu welchem auslösenden Ereignis hat.

Ist das auslösende Ereignis eine Query oder die Ankunft von Daten im System?

Mein Empfinden ist, dass das zu oft nicht unterschieden wird. Der Auslöser wird naiv gleichgesetzt mit dem Empfänger. Und beim Empfänger denkt man nicht an den Unterschied zwischen Datenankunft und Abfrageauslösung.

Solange hohe Performance billig herzustellen ist, macht die fehlende Unterscheidung auch nichts. Wenn Performance aber anfängt die Diskussion zu dominieren, wenn sie sich immer wieder in den Weg der Arbeit an anderen Aspekten wirft, dann sollten Sie genauer hinschauen.

Mir scheinen drei Begriffe dafür interessant: Änderungsfrequenz, Abtastfrequenz und Reaktionszeit.

Die Änderungsfrequenz gibt an, wie häufig sich Daten in relevanter Weise ändern. Mein Lieblingsautor schreibt jedes Jahr ein Buch. Der Benzinpreis ändert sich vielleicht 5 Mal am Tag bei meiner Tankstelle. Die Temperatur draußen ändert sich unter Umständen stündlich.

Wenn für mich diese Ereignisse grundsätzlich interessant sind, so ist nicht unbedingt jedes Ereignis auch relevant. Ich möchte zwar keine Neuerscheinung meines Lieblingsautors verpassen, interessiert mich der Benzinpreis nur alle paar Tage und die Temperatur auch nur gelegentlich während des Tages.

Während die Änderungsfrequenzen 1/Jahr, 5/Tag und 24/Tag sind, sind meine Abtastfrequenzen vielleicht 12/Jahr, 1/Woche und 2/Tag.

Wenn ich häufiger abtaste als das Ereignis eintritt, dann ist mir an möglichst kleinem Verzug gelegen. Besser als solches Polling wäre natürlich eine Benachrichtigung. Leider bietet amazon so etwas bisher nicht an, wenn ich es recht sehe. Beim Buch möchte ich im Mittel also nicht später als 2 Wochen nach Erscheinen (halbe Periode der Abtastfrequenz) darüber informiert sein. amazons Performance muss nur so gut sein, wie mein Anspruch an meine Reaktionszeit ist.

Wenn sich Daten jedoch häufiger ändern als ich abtaste… dann ist mir die Aktualität offensichtlich nicht so wichtig. Zwischen zwei Abtastungen kann sich ja viel ändern. Der Benzinpreis könnte um 50% schwanken, ohne dass ich es merke, auch ohne dass es für mich relevant wäre, weil mein Tank noch so voll ist, dass sich nachtanken nicht lohnte. Was bedeutet das für die Performance der Datenpflege? Ich denke, die Performance ist in diesem Fall nicht so wichtig. Denn ob ich den tatsächlich aktuellen Wert erfahre, wo mich doch zwischenzeitliche Werte nicht interessiert haben, oder einen etwas älteren, weil die Verarbeitung des aktuellen noch nicht abgeschlossen ist, das scheint mir einerlei.

Daraus ergibt sich für mich zusammenfassend:

In Performancefragen ist zuerst zu klären, wer Auslöser und Empfänger einer Datenveränderung sind.

Dass sowohl Auslöser wie Empfänger in Bezug auf ihre unmittelbare Interaktion mit der Software immer beides sind, ist trivial. Dadurch darf man sich nicht verwirren lassen. Wenn einer von beiden einen Befehl absetzt, dann will er schnellstmöglich danach weitermachen. Die Software soll nicht einfrieren. Das ist jedoch unabhängig von den dahinter stehenden Datenänderungen im System!

Wer Daten einpflegt, will nur sicher sein, dass die Daten der weiteren Verarbeitung verlässlich übergeben wurden. Das muss schnellstmöglich geschehen.

Und wer Daten abfragt, der will schnellstmöglich eine Antwort. Wie aktuell die Daten jedoch sind, die in die Antwort eingehen, das ist eine ganz andere Sache.

Zwischen Übergabe an die Verarbeitung und Abfrage kann eine lange Zeit liegen. Nur diese Zeit ist maßgeblich für die Verarbeitungsgeschwindigkeit. Ausschlaggebend ist die gewünschte Reaktionszeit. Denn danach wird sich ein Empfänger für seine Abtastfrequenz richten; die muss seinem Anspruch an Datenaktualität entsprechen.

Performanceoptimierung ist mithin eine Sache des Zugs: Wie oft zieht ein Interessent an den Daten? Wie ist seine Abtastfrequenz in Bezug auf die Änderungsfrequenz der Daten?

Zäumen Sie das Performance-Pferd von diesem Schwanz her auf. Nur wenn die Abtastfrequenz über der Änderungsfrequenz liegt, scheint mir Tuningaufwand gerechtfertigt. Und unterscheiden Sie deutlich zwischen dem, der Datenänderungen anstößt (Einpfleger) und dem, der sie empfängt (Abfrager). Meine Vermutung ist: Sie werden viele Möglichkeiten finden, die Datenverarbeitung asynchron zu machen. Und das ist eine sehr entspannende Aussicht, finde ich.

Softwareentwurf in der hohlen Hand

Gerade komme ich wieder von drei Trainingstagen zum Thema agiler Softwareentwurf. Ein inhouse Training für ehemalige C bzw. C++ Entwickler, die sich noch an .NET gewöhnen müssen. Aber es hat vielleicht gerade deshalb besonders Spaß gemacht, weil sie noch nicht so “objektorientiert verdorben” sind. Ihnen steckt vor allem die C-Praxis in den Knochen, die sie anscheinend offen für den Softwareentwurf mit Softwareuniversum und Flow-Design gemacht hat. Denn wenn die prozedurale Programmierung in einem Recht hatte, dann darin, dass es zuerst und vor allem um Funktionalität und nicht um Daten geht.

Aber von dem positiven Feedback, das Stefan Lieser und ich dort bekommen haben, wollte ich gar nicht sprechen. Die gute Stimmung bei den Trainingsteilnehmern hat vielmehr mich selbst nochmal unseren Ansatz frisch erleben lassen.

Abends saß ich nämlich im Hotel bei einem gemütlichen Kaminfeuerchen und habe an einer Anwendungsidee herumgebastelt. Eine Web-Anwendung, die helfen soll, eine Klippe des Kennenlernens über online Partnerbörsen zu umschiffen. Wie das gehen soll wird die dotnetpro demnächst berichten ;-) Technologisch mit von der Partie werden jedenfalls AppHarbor, Nancy und iron.io sein.

Da saß ich also und habe darüber nachgedacht, wie die Idee in Software funktionieren könnte. Welche Seiten sollte so ein Website haben? Wie sollten die Seitenübergänge sein? Was sollte dabei passieren? Welche Klassen/Komponenten sollte es geben? Wie würden Feature ineinander greifen?

Im Kopf kann ich so etwas bewegen – aber nur bis zu einer gewissen Grenze. Dann muss ich einen Dump machen. Irgendwie muss ich meine Gedanken und Ergebnisse manifestieren. Visual Studio hatte ich vor dem Kamin aber nicht zur Hand. Warum auch? Ich brauche keinen Code, um Software zu entwerfen.

So hat mir denn ein kleiner Notizblock des Hotels geholfen. Der war nur handtellergroß mit schmalen Blättern. Aber er hat mir gereicht wie diese Bilder zeigen:

Wenn Sie nicht wissen, was die Symbole bedeuten und meine Schrift nicht lesen können, macht das nichts. Ich will Ihnen ja nicht erklären, was die Anwendung tut und wie ich gedenke, das zu realisieren.

An dieser Stelle soll nur rüberkommen, dass ich mit zwei kleinen Zetteln die Software entwerfen konnte. Ich weiß nun, welche Klassen ist brauche. Ich weiß, welche Methoden die haben. Ich weiß, wie alles zusammenhängt und die Funktionalität herstellt. Ich weiß, welche Daten fließen. Ich weiß, wie ich APIs kapseln muss. Ich weiß sogar schon, wie ein guter Teil des Codes aussehen muss.

Den Entwurf der beiden Bilder kann ich “so runtercodieren”. Da ist alles drin, was ich brauche. Nur das Layout der Seiten fehlt. Aber das gehört ja auch nicht zum funktionalen Entwurf. Wichtig ist dafür nur, welche Interaktionen der Benutzer mit Dialogen hat. Und die stecken in dem Modell drin.

Durch das Training geöffnet habe ich frisch erlebt, wie effektiv Softwareentwurf mit Papier und Stift sein kann – wenn man eine geeignete Methode hat ;-) Ich muss nicht darauf warten, dass Softwarestrukturen durch Tests wachsen. Ich brauche keine IDE, um bei einer Anwendung voran zu kommen.

Klar, am Ende muss implementiert werden. Bubbles don´t crash. Ich weiß nicht, ob mein Entwurf 100% korrekt/ausreichend ist. Aber ich bin ein gutes Stück voran gekommen. Ich habe mit “systematischer Kritzelei” das Codieren solide vorbereitet. Wenn ich dann Details mit TDD austreiben will, weiß ich, wo ich ansetzen kann.

Und all das steckt in zwei Blättchen mit Flow-Designs. Das fand selbst ich, der ich täglich mit Flow-Design arbeite, irgendwie bemerkenswert cool.

Softwareentwurf als Video – Ein Experiment

Wie entwirft man Software? Wie kann man über Softwarestrukturen nachdenken und reden, ohne am Code zu kleben?

Dazu entwickeln Stefan Lieser und ich als die Clean Code Advisors seit Jahren einen Ansatz unter wechselndem Namen: alles begann mit Softwarezellen, dann kamen Feature Streams dazu, die haben Event-Based Components auf den Kopf gestellt und im Augenblick steht im Kern Flow-Design. Alles fließt – nicht nur in der Software, sondern auch bei unserer Methode. Wir voran gekommen, haben einen pragmatischen Weg gefunden – aber wir sind sicher noch nicht am Ende [1].

Wie dieser Weg beschritten werden kann, thematisieren wir in Zeitschriftenartikeln und Blogpostings. Und wir führen in Trainings darin ganz konkret ein, zum Beispiel in der Clean Code Developer Akademie oder auch inhouse. Immer wieder werden wir aber auch gefragt, ob es nicht etwas “zum Zuschauen” gäbe, bei dem man verfolgen kann, wie die Anwendung funktioniert.
Bisher musste wir verneinen. Außer einem Vortragsmitschnitt hier und da, in dem ich mal Modellierung präsentiert habe, gibt es keine “Bewegtbilder” zum Softwareentwurf, wie wir ihn verstehen.

Das könnte sich jetzt aber ändern. Stefan und ich haben nämlich ein Experiment gemacht. In Regensburg haben wir uns um ein SMART Board versammelt und mitgeschnitten, wie wir eine Anwendung entwerfen und beginnen zu implementieren.

Das Ergebnis sehen Sie hier:



Wie gesagt, es ist ein Experiment. Alles steht letztlich zur Disposition. Wir freuen uns über Feedback.

Das Video gliedert sich in mehrere Abschnitte:

• 00:18:18: Erklärung der Aufgabe
• 02:13:14: Überblick über den Lösungsansatz verschaffen
• 05:30:11: UI skizzieren
• 09:24:03: Interaktionen identifizieren
• Modellierung von…
  • 12:12:17: Inkrement #1
  • 15:58:21: Inkrement #2
  • 24:02:14: Inkrement #3
  • 28:24:05: Inkrement #4
• 39:25:03: Kontrakte definieren, um zu zweit komponentenorientiert entwickeln zu können
• 50:27:13: Review der Kontraktcodierung
• 51:42:09: Review der Implementation des ersten Inkrements
• Den Code können Sie im Github Repo einsehen. Dort liegen auch die Entwürfe als PDF.

Ob das zu viel oder zu wenig ist, werden Ihre Rückmeldungen ergeben. Aber wir haben uns auch schon eine Meinung gebildet ;-)

Doch nun: Vorhang auf!

Schauen Sie sich das Video an. Danach können Sie unsere Retrospektive zur Produktion lesen.

Retrospektive

Der Dreh hat Laune gemacht. Das war schon mal wichtig :-) Ganz grundsätzlich hat alles ziemlich gut geklappt. Abgesehen von kleinen technischen Problemen haben alle Werkzeuge geschnurrt. Auch der Videoschnitt verlief reibungslos – allerdings muss ich mal über eine Firewire Festplatte und/oder einen Rechner mit mehr Kernen nachdenken. Es wehte einige Stunden ein deftiger Lüfterwind in meiner Bude.

Ob wir das SMART Board allerdings weiter einsetzen, wissen wir noch nicht. Wie die Totale im Video zeigt, ist es mit dem Licht nicht so einfach. Die Projektionsfläche ist hell – aber Stefan und ich erscheinen als Schattenspieler davor. Die Raumhelligkeit hat für uns nicht ausgereicht. Das nehmen Kameras anders wahr als menschliche Beobachter im selben Raum. Das nächste Videoexperiment wird sicherlich ein anderes Darstellungsmittel ausprobieren.

Auch beim Ton müssen wir nochmal schauen, was wir tun können. Einerseits könnten wir etwas lauter sprechen. Andererseits darf die Akustik etwas besser werden. Das Nuscheln müssen wir uns aber in jedem Fall abgewöhnen ;-)

Mit mehreren Kameras aufzunehmen und zwischen ihnen zu schneiden, war in jedem Fall eine Leichtigkeit. Das behalten wir bei. Dadurch ergibt sich eine natürliche Lebendigkeit im Video ohne großen Aufwand. Wechsel zwischen Küche, Fahrrad, Auto, Schreibtisch usw. ohne inhaltlichen Bezug, wie bei anderen Videoproduktionen, können wir uns sparen ;-)

Nicht zufrieden sind wir jedoch mit der Präsentation des Inhalts. Da sind wir einen Kompromiss eingegangen, weil wir organisatorischen Aufwand befürchtet haben, der das Ergebnis suboptimal ausfallen lässt.

Der Kompromiss besteht darin, dass wir die Inkremente im Sinne eines agilen Vorgehens zuerst alle modellieren, um sie erst anschließend eines nach dem anderen zu implementieren. Das entspricht nicht unserem wahren Vorgehen, das ist nicht, was wir empfehlen. Doch wir dachten, so sei es einfacher aufzunehmen, um nicht immer wieder zwischen Modellierung und Implementierung umbauen zu müssen.

Wie sich dann aber herausgestellt hat, war es gar nicht nötig, für die Implementierung bzw. den Review von Code umzubauen. Wir haben einfach mit den drei Kameraperspektiven weitergemacht und am SMART Board über den Code gesprochen. Kein live coding, kein Screenrecording, wie zunächst gedacht.

Das werden wir beim nächsten Mal auf jeden Fall anders machen: design a little, code a little. So muss der Rhythmus sein. Sonst läuft man mit dem Modell bei allen Vorteilen eines expliziten Entwurfs in die Irre. Bubbles don´t crash behält seine Relevanz. Das zeigt das letzte Inkrement im Video. Die Diskussion darüber ist verhältnismäßig lang – und trotzdem kommt etwas heraus, das nicht voll funktionstüchtig ist. Wir haben schlicht nicht alle Eventualitäten durchdacht. Erst “Anwendertests” nach der Implementierung von Inkrement #4 haben gezeigt, dass es eine Lücke in der Funktionalität gab.

Das Problem ist beim letzten Inkrement aufgetreten, da war es dann nicht so schlimm. Aber es hätte uns auch früher passieren können; dann wären die Modelle weiterer Inkremente auf falschen Modellen aufgebaut worden. Dagegen schützt nur, Modellinkremente sofort zu implementieren.

Eine weitere Frage, die wir uns gestellt haben, ist die nach dem Single Responsibility Principle. Haben wir das mit dem Video eingehalten? Ist der Fokus eng genug? Oder haben wir auch hier schon zuviel auf einmal gewollt? Bewusst haben wir unseren Ansatz schon nicht erklärt, sondern ihn einfach unter uns angewandt. Aber ist es vielleicht zuviel, dann auch noch zu implementieren? Die Kontraktdefinition scheint uns in jedem Fall zu ausführlich geraten.

Ausblick

Soweit mal unser erstes Videoexperiment mit Reflexion. Nun kommen Sie. Was ist Ihr Feedback? Was gefällt Ihnen, was sollen wir anders machen? Haben Sie Interesse an weiteren Videodarstellung zum Thema Softwareentwurf? Wünschen Sie sich inhaltlich etwas? Worauf sollten wir näher eingehen? Was weglassen? Können wir den Entwurf in bestimmten Domänen oder von konkreten Szenarien demonstrieren?

Wir sind gespannt, was Sie uns schreiben.

Fußnoten

[1] Dass wir überhaupt an einem Ansatz arbeiten und nicht schlicht OOA/D und UML benutzen ist kurz gesagt: Wir sehen in der Praxis nicht, dass die existierenden Ansätze erstens überhaupt relevante Verbreitung gefunden hätten. Es regiert das Durchwursteln. Zweitens halten wir diese Ansätze im Sinne von Methode bzw. Standarddarstellung für unzureichend und allemal schwer erlernbar.
Unser Bemühen richtet sich daher auf eine pragmatischere, auch im Projektalltag handhabbare Methode ohne Firlefanz, die einen Großteil der Softwarerealität abdeckt.

Wie diese Methode aussieht, haben wir in unterschiedlichen Publikationen immer wieder in Facetten dargestellt. Eine umfassende Beschreibung fehlt allerdings. Auch dieses Video liefert sie nicht. Es bietet nur einen Ausschnitt. Aber vielleicht kommen wir ja noch dazu, ein Buch zu schreiben… ;-) Einstweilen entsteht die derzeit systematischste Beschreibung gerade in einer Artikelserie für die Zeitschrift web & mobile developer.

Objektorientierung an der Quelle

Was viele Entwickler so jeden Tag betreiben, soll ja Objektorientierung sein. Java, C#, C++ und einige Sprachen mehr firmieren als objektorientiert. Sogar F# sucht den Anschluss als hybride Sprache.

Und wenn es dann in diesen Sprachen Klassen gibt, aus denen zur Laufzeit Objekte gemacht werden, dann ist das doch auch richtig – oder?

Natürlich kann jeder unter Objektorientierung im Grunde verstehen, was er will. Oder Objektorientierung ist einfach der kleinste gemeinsame Nenner dessen, was irgendwie so genannt wird. Ja, so kann man die Kunst betreiben.

Aber man kann es auch anders tun und sich fragen, was diese Objektorientierung denn ursprünglich mal sollte, wie sie eigentlich gedacht war. Was da herauskommt, finde ich spannend.

Wer hat´s erfunden? Der Alan Kay. Und der sagt zu seiner Erfindung in einer Emailkonversation zum Beispiel das Folgende:

“I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages (so messaging came at the very beginning -- it took a while to see how to do messaging in a programming language efficiently enough to be useful).”

“So I decided to leave out inheritance as a built-in feature until I understood it better.”

“OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.”

An anderer Stelle ist von ihm dann auch noch zu hören gewesen:

“I invented the term Object-Oriented, and I can tell you I did not have C++ in mind.”

Das Internet: “Possibly the only real object-oriented system in working order.”

Nun frage ich mich, was der entscheidende Unterschied ist zwischen dem, was Alan Kay mal visionierte und dem, was wir heute haben? Denn ganz offensichtlich ist die heutige Objektorientierung nicht zu dem herangewachsen, was er gewollt hatte.

Mir scheint, der Hauptunterschied liegt im Begriff Message. Bestätigung finde ich dafür auch hier in der Bemerkung über Smalltalk-80, wo der Begriff Message irreführenderweise weiter verwendet wurde, obwohl es nur noch um synchrone bidirektionale Kommunikation zwischen Objekten ging.

Heutige objektorientierte Sprachen betreiben schlicht kein Messaging zwischen Objekten. Sie haben damit den Begriff aus dem Blick verloren, der am Anfang aller Objektorientierung stand (s.o. das erste Zitat).

Im folgenden Code wird also keine (!) Message vom Aufrufer an Objekt o gesendet:

var z = o.f(x, y);
…
o.p = “…”;

Das erste ist nur ein Unterprogrammaufruf, ein procedure call. Das zweite ist ein Zugriff auf Daten eines Objektes.

Keine Frage, so etwas ist nützlich. Ich denke nicht, dass Alan Kay das abschaffen wollte. Aber er hätte nicht mit der Objektorientierung begonnen, wenn er nicht darüber hätte hinausgehen wollen.

Messaging ist unidirektional. Und Objekte sind mindestens abgeschlossene, zustandsbehaftete Kapseln, die keine Struktur verraten, wenn nicht sogar autonom, d.h. auf eigenem Thread laufend.

Klassen, Vererbung, Polymorphie (über Basisklasse oder Interface)… das sehe ich daher ganz und gar nicht im Kern von Objektorientierung. Alan Kay hat eher an dynamische Programmierung gedacht, wenn er “extreme late-binding of all things” forderte.

Und was bedeutet das? Wenn wir Alan Kay ernst nehmen, dann sollten wir erstens bei dem, was wir so üblicherweise tun, den OO-Mund nicht so voll nehmen. Zweitens sollten wir endlich beginnen, mal richtig objektorientiert zu denken und zu codieren. Manche Sprachen machen das sicher leichter als andere. Und dann schauen wir mal, wohin wir kommen, wenn wir unsere Software intern mehr nach dem Internet modellieren, das Alan Kay für das einzige funktionstüchtige echt objektorientierte System hält.

In diesem Sinne: Merry encapsulation, and happy messaging!