One Man Think Tank Gedanken

TDD im Flow – Teil 3

2012-01-30T14:33:00.000+01:00

Was bisher geschah: TDD im Flow – Teil 1 TDD im Flow – Teil 2 Test #4: Blockierte Entnahme Nun geht es an den Kern meines Abstrakten Datentyps: die Sequentialisierung. Ich muss die Entnahme aus den Queues nach Round Robbin einschränken. Es darf nur entnommen werden, wenn eine Queue nicht gerade blockiert wird. Die Blockierung beginnt, wenn ein Worker aus einer unblockierten Queue entnimmt –

TDD im Flow – Teil 2

2012-01-27T14:29:00.000+01:00

Was bisher geschah: TDD im Flow – Teil 1 Test #2: Ein Worker entnimmt aus mehreren Queues Der dritte Test in meiner Planung bleibt sinnig. Er führt zu Änderungen am Produktionscode. Den Testcode zu zeigen, lohnt nicht. Er entspricht der Skizze im Bild. Aber hier der Produktionscode: internal class NotifyingMultiQueue{ List>> _queues = new List<

TDD im Flow – Teil 1

2012-01-26T14:26:00.001+01:00

Steht Flow-Design eigentlich im Gegensatz zu Test-Driven Design? Nein. Zwar bin ich überzeugt, dass TDD viel weniger wichtig ist, als viele Vertreter agiler Softwareentwicklung glauben, aber deshalb hat TDD doch seinen Platz. An einem Beispiel möchte ich das demonstrieren. Vor einiger Zeit habe ich Gedanken zu einer Flow Execution Engine geäußert. Die habe ich inzwischen angefangen zu bauen. Ihr

Schätzungen auf dem Prüfstand

2012-01-11T12:29:00.001+01:00

Kann man verlässlich schätzen, wie lange ein Team braucht, Anforderungen in einsetzbare Software zu übersetzen? Kann man das für einen Horizont von wenigen Wochen? Kann man das für Monate oder Jahre? Diese Frage führt immer wieder zu hitzigen Diskussionen. Eine der am besten besuchten Sessions auf der letztjährigen DevCon drehte sich auch um diese Frage. Das Interesse an einer Antwort, ja

Functions considered harmful

2012-01-09T11:12:00.001+01:00

Bisher habe ich die "traditionelle" konzeptionelle Objektorientierung als eine der Ursachen für die heutigen Probleme mit der Wartbarkeit von Software gesehen. Inzwischen regt sich jedoch in mir der Verdacht, dass das Wurzelproblem tiefer liegt. Womöglich ist die Objektorientierung sogar zu loben, weil sie das irgendwie verstanden hatte und versucht zu helfen. Leider ist das nicht so geglückt,

Bei häufigem Kontakt mit Gift refaktorisieren

2012-01-04T10:57:00.001+01:00

Graham Brooks bricht eine Lanze dafür, Code nicht mit der Gießkanne zu refaktorisieren, sondern den Aufwand dort zu treiben, wo es gerade besonders nutzt. Das hört sich sinnig an. Noch sinniger wird es, wenn Graham als Nützlichkeitsindikatoren Giftigkeit (Toxicity) und Unbeständigkeit (Volatility) angibt. Giftig (als Steigerung von schmutzig) ist der Code dort, wo bestimmte Metriken besonders

Get real, Kanban!

2011-11-02T09:20:00.001+01:00

Schöne Sache das Networked Kanban wie es Jurgen Appelo in seinem Blogbeitrag beschreibt - nur was ist denn daran wirklich neu? Jeder nicht triviale Produktionsprozess ist mehr als eine "Eimerkette". Und jeder Produktionsschritt arbeitet immer aus einer Warteschlange. Die ringelt sich auf dem Schreibtisch in Form einer Inbox, die besteht aus Post-It Notes am Monitor oder die zischelt in Excel oder

Komponentenorientierung fürs Unternehmen

2011-10-12T14:35:00.001+02:00

Kann Unternehmensorganisation von der Softwareentwicklung etwas lernen? Dass umgekehrt Softwareenwicklung von der Unternehmensorganisation lernen kann, zeigt ja in der letzten Zeit sehr schön Kanban. Das Vorgehensmodell überträgt erfolgreiche Organisationsmuster aus warenproduzierenden Unternehmen in die Programmierung Aber auch umgekehrt ist Lernen möglich. Die Komponentenorientierung ist ein

Skalierbare Softwarebausteine - Teil 2

2011-10-06T18:29:00.001+02:00

In meinem Traum sehen fundamentale Softwarebausteine ganz einfach aus, wie ich im ersten Teil dieser kleinen Artikelserie beschrieben habe: Es sind potenziell zustandsbehaftete und potenziell nebenläufige Funktionseinheiten auf beliebig vielen Abstraktionsebenen, die Input-Daten in Output-Daten transformieren. So einfach ist das :-) Dabei könnte ich nun stehenbleiben und hübsche Diagramme mit

Skalierbare Softwarebausteine - Teil 1

2011-10-05T17:08:00.001+02:00

Wie können wir Software mit evolvierbarer Struktur herstellen? Wie kann Software selbst so agil werden wie unsere Prozesse es schon geworden sind? Diese Frage treibt mich immer noch um. Die bisher angebotenen Lösungsansätze aus Richtung Clean Code finde ich noch nicht ausreichend. TDD und SOLID sind ganz gute Ansätze… nur fehlt ihnen aus meiner Sicht ein umfassender Blick auf Software. Das SRP in

Digitale Erleichterung für den Schulalltag – oder: Kinder sind keine Scherpas

2011-10-03T20:33:00.001+02:00

Wie wäre das, wenn Sie jeden Tag mit 25% Ihres Körpergewichts auf dem Rücken zur Arbeit gehen müssten? Für mich wären das ca. 17 kg, aber ich bin nicht groß. Für viele unter Ihnen wären das bestimmt 20 kg oder gar 25 kg. Ein Gewicht, dass Sie natürlich in einem Rucksack tragen können - nur wäre das jenseits dessen, was sie als bequem ansehen würden. Auf einen Sonntagswanderausflug würden Sie

Ungesunde Zahlungshemmung

2011-10-01T10:35:00.001+02:00

Zahlen für Fortbildung? Gerade habe ich eine Folge von Uncle Bobs Videos gekauft. Dabei habe ich ein Zucken gespürt. "12 USD für ein Video? Lohnt sich das?" Trotz meiner Zweifel habe ich gezahlt... ...und als bei Paypal dann stand "8,96 EUR", habe ich gedacht: "Wie blöd bin ich eigentlich? Ich denke darüber nach, 8,96 EUR für meine Fortbildung auszugeben - aber ich zucke nicht, wenn ich für den

Spinning – Vorschlag für den Kern jedes Vorgehensmodells

2011-09-13T11:15:00.001+02:00

Über eine Iterationslänge von 1 Tag habe ich ja schon öfter geschrieben. Dazu stehe ich weiterhin. Allerdings ist mir aufgefallen, dass sie nicht an erster Stelle stehen sollte. Deshalb versuche ich mal eine andere Formulierung: Im Kern von Scrum steht der Sprint von mehreren Wochen, d.h. ein fixes Auslieferungsdatum mit fixem Scope. Scrum ist damit fundamental zeitorientiert. Pro Sprint werden

Softwareevolution in Vielfalt

2011-09-06T23:22:00.001+02:00

In einem früheren Posting habe ich über Rahmenbedingungen für die Evolution von Software nachgedacht. Den dort genannten möchte ich nun noch eine hinzufügen: die Vielfalt. Ich glaube, dass Evolution eines Ganzen schwieriger ist, als die Evolution von Vielem, das eine Summe hat. Das Leben auf der Erde ist nicht ein Organismus (auch wenn es die Gaia-Hypothese gibt), sondern es besteht aus

Bausteine für die Softwareevolution

2011-09-06T09:40:00.001+02:00

Wenn wir Software naturnah entwickeln wollen, also als evolvierbares System, wie sollte sie denn dann aufgebaut sein? In meinem vorherigen Artikel habe ich mir Gedanken über eher organisatorische Voraussetzungen für naturnahe Entwicklung gemacht. Diesmal will ich die technische Seite angehen. Oder besser: wieder angehen, denn vor Jahren schon hatte ich in diese Richtung spekuliert [1]. Damals

Voraussetzungen für sich entwickelnde Softwarestrukturen

2011-09-04T12:56:00.001+02:00

Liegt die Zukunft der Softwarearchitektur in Emergent Architecture und Growing Software? Diese Frage wurde in zwei Open Space Gruppen auf der SoCraTes Konferenz 2011 behandelt. Das hat mir gefallen, da ich ja mit meinen Softwarezellen auch schon einmal eine naturnahe Metapher gewählt hatte. In den Diskussionen wurde ich das Gefühl jedoch nicht los, dass wir bei allem Appeal der Metaphern noch zu

Jenseits von SOLID

2011-08-25T18:36:00.001+02:00

In einem hübschen Artikel hat Mark Nijhof ein Refactoring nach SOLID beschrieben. Dem ist nichts hinzuzufügen – wenn man denn bei SOLID stehen bleiben will. Ich sehe SOLID aber nicht als sakrosankt an; für mich darf Code gern noch “cleaner” werden. Hier zunächst die Code-Ausgangslage: Eine Klasse mit eine Menge Verantwortungen. Mark löst sie im Sinne des Single Responsibility Principle (SRP) wie

Mit dem Teppichmesser gegen Verlagsträgheit

2011-08-17T11:35:00.001+02:00

Buchhandel und Verlage sind nicht die Schnellsten, was neue Technologien angeht. Ideen aus meiner Sicht als Leser, was der stationäre Buchhandel tun kann, um nachzuziehen und sich zu erhalten, um für mich attraktiv zu bleiben, habe ich schon geäußert. Für die Verlage gibt es natürlich auch Ideen. Hier nur eine, wie ein cooles Buch 2.0 aussehen könnte. Das scheint mir Lesen auf der Höhe der Zeit

Ideen für den Buchhandel

2011-08-03T23:53:00.001+02:00

Wie könnte sich denn nun der Buchhandel auf eine neue Art von Leserschaft einstellen? Mit meinem vorherigen Blogartikel habe ich erstmal nur ein wenig aufrütteln wollen. Mir liegt etwas am Buchhandel oder besser: an Buchgalerien, in denen ich in pBooks stöbern kann und von deren Auswahl und Präsentation an Büchern ich mich inspieren lassen möchte. Deshalb wollte ich dem Buchhandel einmal

Nachricht an den Buchhandel

2011-07-26T17:44:00.001+02:00

Wir werden immer mehr. Ich meine die Leser wie ich, die Bücher elektronisch konsumieren wollen. Vor einem Jahr war das für mich noch kein so großes Thema. Ja, da habe ich auch schon ab und an eBooks gelesen; doch seitdem ich iPad und iPhone habe, hat sich das Verhältnis umgekehrt. Heute lese ich 90% elektronisch und nur 10% auf Papier. Ein Papierbuch kommt mir nur noch in dein Einkaufskorb, wenn

Design zur Diskussion gestellt

2011-07-18T17:58:00.001+02:00

In der Software Craftsmanship Diskussionsgruppe geht es in einem Thread um die Frage, was denn Software Design sei oder Software Architecture. Die Antworten der Software Craftsmen sind für mich sehr überraschend. Hier ein Beispiel: George Dinwiddie hat auf meine Frage also geantwortet, für ihn sei alles Design, was mit Entscheidungen zu tun hat während der Softwareentwicklung. Außerdem sei

Begrenzte Qualität – aber zackig!

2011-07-10T18:57:00.001+02:00

Uncle Bob hat “crap code” den Kampf angesagt: “Craftsmanship over Crap” – zünftige Handwerksleistung soll für mehr Qualität in der Softwareentwicklung sorgen. Dagegen hat Nicolai Josuttis vor einigen Jahren den Gedanken geäußert, wir sollten endlich lernen, uns mit “crap code” abzufinden; er sei nicht zu vermeiden: “So, when I say "Welcome Crappy Code", my point is not to force crappy code. My

Architekturvision braucht Visualisierung

2011-07-09T19:02:00.001+02:00

Über den Begriff Architekturvision bin ich in letzter Zeit ein paar Mal gestolpert. Zuletzt in der “Hauszeitschrift” Ausgabe August/2011 von it-agile. Es freut mich natürlich, dass das Thema Softwarearchitektur an Sichtbarkeit gewinnt. Doch irgendwie will mir nicht ganz schmecken, was da jetzt unter “Agile Softwarearchitektur” in Umlauf gebracht wird. In dem Topf wird schnell alles verrührt, was

Test-Driven Unterstanding

2011-07-08T19:54:00.001+02:00

Was ist es im Kern, das TDD ausmacht? Darüber habe ich anlässlich einer längeren Konversation mit Ron Jeffries in der Software Craftsmanship Google Group jetzt noch einmal nachgegrübelt. TDD hatte bescheiden angefangen als Test-Driven Development. Da ging es darum, Code in einer bestimmten Weise zu schreiben, um ihn von vornherein korrekt zu hinzukriegen. Doch dann wurde TDD befördert von einer

Tägliche Codeproduktionsquote

2011-06-26T22:27:00.001+02:00

Wieviel Code produzieren Sie eigentlich? Wieviele LOC pro Tag, wieviele LOC davon Produktionscode? Schätzen Sie mal. Sind das 100, 500, 1000 Zeilen (ohne Kommentare, automatisch generierte using-Anweisungen und ohne Tests)? Habe gerade die Code-Review-Fibel von SmartBear gelesen. Darin ging es auch um LOC. Empfohlen wird nämlich, pro Peer Code Review nicht mehr als 200+ LOC durchzusehen. Da frage

Porno statt Erotik in der Programmierung

2011-06-25T18:13:00.001+02:00

Die brand eins titelt gerade mit “Das Erotische setzt das Geheimnis voraus. Wo es ganz verschwindet, beginnt die Pornografie.” (Byung-Chul Han, Ausgabe 7/2011) Das bezieht sich im Heft auf das gesellschaftliche Top-Thema Transparenz. Aber mich hat der Ausspruch zum Nachdenken über Softwareentwicklung angeregt. Die kommt mir in der Praxis vieler Projekte nämlich wie die Kunst der Verhüllung vor:

Why UML got it wrong - Abstraktion vs Modell

2011-06-23T14:23:00.001+02:00

Jetzt hab ich es endlich, was mich an der UML stört. Es ist nicht mal ihre Aufgeblasenheit, sondern ihr falsches Versprechen. Die UML verspricht eine Vereinheitlichung von Modellierungsansätzen. Doch leider ist viel weniger Modellierung drin als suggeriert, wo Modellierung so fett gedruckt drauf steht.1 Dazu muss ich aber erklären, wie ich Modellierung verstehe – und was die UML stattdessen

Flow-Design Motivation - Ein XING-Auszug

2011-06-23T11:29:00.001+02:00

Warum ist Flow-Design eigentlich so gegen den üblichen Programmierstrich gebürstet? Dazu habe ich anlässlich einer Diskussion im CCD XING-Forum etwas geschrieben, das ich auch hier für mitteilenswert halte. Anlass war ein Diskussionsbeitrag von Michael van Fondern: Ich habe allerdings doch noch eine Frage, die du mir sicher beantworten kannst. Ich bin bisher bei der AppKata im Wesentlichen so

Lernen mit Format

2011-06-22T21:54:00.001+02:00

Das Dojo ist wieder im Gespräch. Ilker hat einen (selbst)kritischen Artikel dazu in seinem Blog geschrieben. Seiner Zurückweisung der Sicht, “dass ein Coding Dojo doch nur ein ‘nettes Rahmenprogramm’ sei” stimme ich zu. Es ist ein “lockeres Mittel zum Training und Erfahrungsaustausch” – auch wenn es mal im Rahmenprogramm einer anderen Veranstaltung auftauchen mag. Gemeinsam lernen: darum geht es

Flüssiges SOLID

2011-06-16T09:59:00.001+02:00

Es gibt unerwartete Hilfe für das Flow-Design von den objektorientierten Freunden des Clean Code. Innerhalb zweier Tage bin ich über sehr ähnliche, aber unzusammenhängende Aussagen gestolpert. Da schreibt einerseits der Chefredakteur des ehrwürdigen Dr. Dobb´s Journal, Andrew Binstock, in einem Editorial, wie wichtig er es fände, Klassen klein zu halten: “Small classes are much easier to

Drei Zwecke fürs Refactoring

2011-05-23T10:30:00.001+02:00

Refactoring ist zu einer festen Vokabel in der Branche geworden, würde ich sagen. Ohne Refactoring geht es in älteren größeren Projekten einfach nicht. Deshalb hat Refactoring, so scheint mir, ein sehr pauschal gutes Image. Refactoring sollte man können und tun. Bei TDD ist es sogar in der Definition: red-green-refactor. Mir scheint jedoch, dass wir gut daran täten, zu differenzieren. Ist

AppKata – Enter the next level

2011-05-22T22:18:00.001+02:00

Wer schon alle CodeKata Übungen durch hat – Kata Potter, Bowling, LOC, Poker, Fizz Buzz und wie sie alle heißen –, der kann jetzt eine neue Herausforderung annehmen: eine AppKata. AppKatas – kurz für Application Kata – sind Übungsaufgaben wie CodeKatas, nur umfangreicher. CodeKatas stellen vor allem überschaubare algorithmische Probleme. Da ist typischerweise ein kleiner API zu entwickeln (wenn

Der Objekte Kern

2011-04-28T19:04:00.001+02:00

Was ist eigentlich Objektorientierung? Eigentlich sollte das doch klar sein – und doch erhitzen sich die Gemüter immer wieder darüber. Wenn ich Flow-Design vorstelle, höre ich z.B. den Einwand, das sei doch gar nicht mehr objektorientiert. Das ist dann nicht nur Feststellung, sondern auch Kritik. Aber ist das wirklich so? Und ist das kritikwürdig, wenn es denn so wäre? Ich denke, wir müssen uns

Mehr als ein Job in der Softwareproduktion

2011-04-24T18:21:00.001+02:00

Gibt es in der Softwareentwicklung nur Architekten? Jens Schauder meint es so, wenn er in seinem Blog schreibt: “I currently work on a team of 8. 8 architects. […] There is no human construction worker involved. That is the part of the metaphor that falls apart. All the building happens by software and each developer is an architect.” [Meine Hervorhebung] Hört sich irgendwie nett an. Klar, wer

Lernkartei III – Vom Stapel lernen

2011-04-23T00:03:00.001+02:00

Die Lernkartei “zuckt schon”, wie der vorherige Artikel beschrieben hat. Als Anwender kann ich im Lernmodus Karteikarten “durchblättern”, also schon beurteilen, ob mir Darstellung und Interaktionen gefallen. Lernen, im Sinne einer Wiedervorlage von nicht gewussten Antworten, kann ich mit dem Programm allerdings noch nicht. Das soll in der zweiten Iteration hier nun nachgerüstet werden. Arbeiten

Lernkartei II – Erste Lerninteraktion

2011-04-15T20:11:00.001+02:00

Wie ist eigentlich das Vorgehen beim Flow-Design und der Umsetzung mit Event-Based Components? Das – so hatte ich in einem früheren Posting angekündigt – möchte ich mal anhand einer Beispielanwendung zeigen. Das Szenario ist einfach zu verstehen, aber nicht trivial: ein Lernkarteiprogramm. Ich würde sogar sagen, nach oben gibt es da nicht so bald eine Grenze. Das könnte ich sogar mit der Cloud

Skalierbarkeit als Gläserne Decke in der Agilität

2011-04-01T13:42:00.001+02:00

Agile Softwareentwicklung fokussiert sich auf verlässliche Lieferung von Nutzen. Je schneller sie den liefert, desto besser. Meistens. Die Frage ist nur, wie die Geschwindigkeit erhöht werden kann. Wie skaliert Softwareproduktion? Skalieren ganz allgemein Skalieren oder skalierbar sein heißt, auf mehr Bedarf so reagieren zu können, das er gedeckt wird. Wenn ein Website normalerweise 10

Gläserne Decke für die Agilität – Abhängigkeiten

2011-03-31T11:55:00.001+02:00

Agile Softwareentwicklung weist den richtigen Weg zu besserer Software. Die Softwareentwicklung muss alles tun, um so dicht wie möglich an den diffusen und wechselnden Bedürfnissen der Kunden zu sein. Also mehr Dialog als fixierte Kontrakte. Mehr den Menschen im Blick als starre Tools. Mehr Offenheit für Veränderungen als Plantreue. Dazu muss natürlich das Vorgehen einer Entwicklergruppe passen.

Lernkartei I – Das Szenario

2011-03-29T16:36:00.001+02:00

Flow-Design verspricht evolvierbare Software. Wenn ich ein Flow-Design Diagramm zeichne, ist das allerdings noch nicht nachzuvollziehen. So ein Diagramm mag verständlicher sein als andere Diagramme, doch warum sollte Software deshalb evolvierbarer sein? Um die Evolvierbarkeit von Flow-Designs zu zeigen, ist mehr als ein Diagramm nötig. Nur eine Reihe von Diagramme, die zeigt, wie sich eine

Flow im Unternehmen – Teil 3 – Engpass Programmierung

2011-03-29T13:10:00.001+02:00

Wenn die Softwareproduktion insgesamt besser werden soll, dann muss am Engpass angegriffen werden. Das ist die Programmierung, die Anforderungen in Release Candidates transformiert. Ober genauer formuliert: Auf einer bestimmten Detaillierungsstufe ist die Programmierung der Engpass. Tritt man weiter zurück, dann ist es die gesamte Softwareentwicklung bestehend aus Programmierung und

Flow im Unternehmen – Teil 2 – Qualität

2011-03-24T15:07:00.001+01:00

Wenn die Softwareentwicklung besser werden soll, dann ist nicht jede Veränderung von gleichem Wert. Das liegt auf der Hand. Doch welche Veränderungen sind anderen vorzuziehen? Sollte ein weiterer Entwickler eingestellt werden? Oder besser auf TFS umstellen? Oder zur WCF-Schulung gehen? Solche Fragen sollten nicht aus dem Bauch heraus entschieden werden. Es braucht vielmehr ein Rahmenwerk, in dem

Flow-Orientation für´s Unternehmen - Teil 1, Theory of Constraints

2011-03-20T14:10:00.001+01:00

Bei der Softwareentwicklung geht es immer um Geld. Das mag unschön klingen, ist aber nicht zu ändern. Jeder, der sein Geld mit der Entwicklung von Software verdient, muss mit seiner Software dazu beitragen, dass dieses Geld auch reinkommt. Alles, was wir in der Softwareentwicklung tun, muss sich deshalb die Frage gefallen lassen, ob es dem Ziel des Geldverdienens nützt. Oberstes Ziel eines

Fit für FitNesse

2011-03-17T11:11:00.001+01:00

FitNesse ist ein hübsches Framework für Akzeptanztests. Ist zwar Java-basiert mit seinem eigenen Web-Server, aber der Einsatz ist auch für .NET möglich. Gojko Adzic hat dazu schon vor längerer Zeit ein Buch geschrieben – Test Driven Development with FitNesse -, dass auch kostenlos als eBook verfügbar ist. Leider hat sich der Einstieg dann aber doch nicht so flüssig gestaltet, wie ich es gern

It is all design – really?

2011-03-13T20:35:00.001+01:00

Uncle Bob hat unlängst getwittert: “It is all design.” Und dafür hat er auch großes Lob aus Deutschland bekommen. Ich frage mich hingegen: Wenn denn alles Design ist, warum sollte ich dann dieses Design in textuellem Quellcode durchführen? Ja, ja, ich weiß, dass Jack W. Reeves schon in den 1990ern “bewiesen” hat, dass Programmierung nicht Herstellung, sondern Design ist. Dem stimme ich im

Beziehungsratgeber für Softwareentwickler

2011-02-27T18:07:00.001+01:00

Komplexität vergällt uns das Programmieren. Unwartbarkeit ist ein Komplexitätsproblem. Aber was macht die Komplexität in Software aus? Für mich ist etwas komplex, wenn ich es durch Nachdenken nicht verstehen kann. Solange etwas kompliziert ist, hilft Nachdenken. Beispiel: Der Boyer-Moore Algorithmus zur Zeichenkettensuche ist kompliziert (zumindest für mich). Ich verstehe ihn nicht sogleich, aber

Traktor für die Softwareentwicklung

2011-02-16T09:40:00.001+01:00

Wer ist eigentlich am wichtigsten in einem Softwareentwicklungsprojekt? Sind es die Entwickler, ohne die es zu keiner Software kommt? Oder ist es der Requirements Engineer, ohne den die Entwickler nicht wüssten, was sie tun sollen? Oder ist es der Verkäufer, ohne den es gar kein Projekt gäbe, für das Anforderungen erhoben werden müssen? Oder ist es der Kunde, der schließlich das Geld gibt? Oder

Spielend programmieren

2011-02-06T13:27:00.001+01:00

Besser wird es nicht durch Klagen. Besser wird es nur, wenn man sich überhaupt vorstellen kann, wie es besser sein könnte. Dafür muss man sich manchmal frei machen von dem, was ist. Einfach alle Begrenzungen hinter sich lassen. Mal frei fabulieren, wie die Welt aussehen sollte, und beherzt eine Antwort finden auf die Frage: “Ja, wie hätte ich es denn gern, wenn ich mir etwas wünschen dürfte von

Mehr vom Selben hilft nicht mehr

2011-02-01T00:37:00.001+01:00

Martin Fowlers Vortrag hat mich leider enttäuscht. Heute abend hätte er über “Software Design in the 21st Century” sprechen sollen. Gesprochen hat er aber stattdessen in drei “Minivorträgen” über DSLs – anlässlich seines gerade erschienenen Buches zum Thema –, REST und die Agilitätsbewegung am Ende der ersten 10 Jahre. Das war alles wenig inspirierend und wenig inspiriert, fand ich. Nun frage ich

Abhängige Flüsse

2011-01-29T14:35:00.001+01:00

Abhängigkeiten sind ein zentrales Problem in der Softwareentwicklung. Deshalb haben Flow Designs den Anspruch, mit ihnen konsequent aufzuräumen. Wie sich nun herausstellt, ist das zwar möglich – aber manchmal umständlich. Abhängigkeiten auch in Flow Designs integrieren zu können, erscheint deshalb sinnvoll. Hier mein Vorschlag, wie das geschehen könnte. Problem #1: Akteure und Request/

Verantwortlichkeiten abstecken

2011-01-13T13:38:00.001+01:00

Zwei der wichtigsten Clean Code Developer (CCD) Prinzipien sind Single Responsibility Principle (SRP) und Separation of Concerns (SoC), die beide Spezialfälle des noch grundlegenderen Don´t Repeat Yourself (DRY) sind. So wichtig diese Prinzipien aber auch sind, ich glaube, wir nehmen sie noch nicht wichtig genug. Oder anders: Wir durchdringen sie noch nicht genug. Wir schauen bei der

Software-Prüfstände: Das fehlende Glied in der agilen Softwareentwicklung

2011-01-03T19:56:00.001+01:00

Software soll in dünnen Längsschnitten jeden Tag geliefert werden. Dass das mit Software geht, weil sie nicht aus Materie besteht, habe ich hier beschrieben. Und warum das sinnvoll im Sinne eines schnellen Lern- und Klärungsprozesses für den Kunden ist, habe ich hier erklärt. Schließlich habe ich noch hier ein Beispiele dafür gebracht, wie das konkret aussehen könnte. Dieses Denken macht für mich

Kein Verständnis ohne Überprüfung – Warum Wasserfallentwicklung nicht funktionieren kann

2011-01-01T21:51:00.001+01:00

Gerade lese ich das Manuskript eines Buches, das demnächst im dpunkt.verlag erscheinen wird. Man hat mich nach meiner Meinung danach gefragt und ich finde es spannend. Die Autoren schauen durch die Brille der Psychologie unter fragen kritisch, inwiefern liebgewonnene oder gehypte Praktiken eigentlich auf einem wissenschaftlichen Fundament ruhen. Das finde ich gleichermaßen wichtig wie erhellend.

Ein Paradigma, viele Implementierungen

2010-12-28T13:04:00.001+01:00

Event-Based Components (EBC) werden vor allem mit C#-Events in Zusammenhang gebracht. Nicht zu unrecht natürlich. Darum ging es ja auch am Anfang: Funktionseinheiten über Events verbinden. So können sie “im Außen” zusammengesteckt werden; “im Innen” haben sie keine Abhängigkeiten mehr. Inzwischen hat sich die Welt aber gedreht. Aus den EBC sind die Komponenten verschwunden. Und nun verschwinden

Ein Team das hat zwei Modi, zwei Modi hat ein Team

2010-12-27T10:44:00.001+01:00

Schade, dass in diesem Beitrag von Bernd Oesterreich das Team so einseitig gezeichnet ist. Es ist fast ausschließlich im operativen Modus beschrieben. Ein Fußballteam während des Spiels. Ungleich und nicht gleichberechtig: so sollen Teammitglieder vor allem sein? Wussten wir das aber nicht immer schon und haben der sozialromantischen Version demokratischer Kuschelteams misstraut? Nun wissen wir

In Abhängigkeit refaktorisieren

2010-12-25T12:23:00.001+01:00

Refaktorisieren ist überbewertet – zu der Überzeugung gelange ich immer mehr. Refaktorisieren ist eine Symptomkur, die das System, das Paradigma, das zu dem Zustand geführt hat, den sie auflösen soll, nicht verlässt. Vielleicht ist das auch der Refaktorisierung selbst nicht anzukreiden. Das mag sein. Refaktorisierung bedeutet dann nicht nur eine funktionserhaltende Umstrukturierung, sondern

Quotenlose Entwicklung

2010-12-22T13:31:00.001+01:00

Was ist an diesen Bildern falsch? Zeigen Sie vielleicht keine echten Softwareentwickler? Doch. Zumindest auf dem linken Bild erkenne ich eine Person, von der ich weiß, dass sie Informatiker ist – weil ich mit ihr zusammen studiert habe. Ist das Diagramm am Whiteboard des zweiten Bildes unrealistisch? Nein. Es folgt zwar keinem UML-Standard, würd ich sagen – aber das ist ja nichts Besonderes in

Bei Anforderung vorgehen – Teil 2

2010-12-21T15:17:00.001+01:00

Neulich hab ich ein Szenario vorgestellt und ermuntert mal zu überlegen, wie die Anforderugen umgesetzt werden könnten. “Wann sieht der Kunde welche Funktionalität?” war für mich die Kernfrage, denn daran scheiden sich die Geister, wenn es um Auslieferung in kleinen Inkrementen geht. Die zu sehen, scheint notorisch schwierig für Softwareentwickler. Heute stelle ich zu dieser Frage nun meine

Vom Wert des Schätzens im Angesicht real möglicher Unproduktivität

2010-12-18T21:40:00.001+01:00

Ob Softwareentwickler Aufwand schätzen können oder nicht… Das lasse ich zur Abwechslung heute mal dahingestellt. Stattdessen frage ich mal: Was sagen Schätzungen denn eigentlich aus? Szenario 1: Ein Manager fragt seine Frau, wie lang sie für den Weihnachtsbraten wohl braucht. Sie schätzt, dass es wohl 3 Stunden sein werden. Szenario 2: Ein Manager fragt den Klempner seines Vertrauens, wie lang er

Bei Anforderung vorgehen – Teil 1

2010-12-18T10:11:00.001+01:00

Neulich ging es ja hoch her in den Kommentaren zu meinem Schätz-Beitrag. Deshalb hier eine Aufgabe, anhand der ich ein wenig Licht auf mein Vorgehen beim Umgang mit Anforderungen werfen möchte. Die Aufgabe stammt von einem Entwickler aus einer Email-Kommunikation rund um das Schätzen: Der Kunde stellt Kaffeemaschinen her, deren Komponenten der Besteller individuell zusammenstellen kann. Auf

Maschinen bauen, aber Software verschärfen

2010-12-11T17:37:00.001+01:00

Softwareentwicklung kann man nicht schätzen? Die Frage und meine verneinende Antwort haben einige Diskussion ausgelöst. Das verstehe ich gut. Nicht anders hatte ich es erwartet. Glaubenssätze, auch wenn sie wieder und wieder zu Schmerzen führen, werden ungern aufgegeben. Davon weiß die Psychotherapie ein Lied zu singen. Und um einen Glaubenssatz handelt es sich, denn die ganze Branche ist seit 50

Gesunde Anämie

2010-12-10T19:09:00.001+01:00

Immer wieder gibt es Uneinigkeit darüber, wie zustandsbehaftete Domänenklassen mit Funktionalität ausgestattet werden sollen. Ist es eine Tugend, ein Kundenobjekt nach seiner Bonität befragen zu können? Die vorherrschende Meinung sieht das wohl so. Und wo sie zustandsbehaftete Domänenklassen auf die Datenhaltung reduziert sieht, spricht sie von einem anämischen Domänenmodell. Gestern bei einem

Widerspruch gegen das Schätzen

2010-12-08T20:58:00.001+01:00

Mir wird das Schätzen immer suspekter. Warum tun selbst agile Entwickler das? Mal ehrlich? Auf der einen Seite wissen wir – und ich meine wirklich “wissen” –, dass es unmöglich ist, den Aufwand von Softwareentwicklung zu schätzen. Denn da wo etwas Neu ist, seien es Tools, Techniken, Teammitglieder, Aufgaben, Kunden… da kann man einfach nicht sagen, wie lang es dauert, Anforderungen umzusetzen.

Ein Traum von Softwareentwicklung

2010-12-07T12:17:00.001+01:00

Lassen Sie für einen Moment mal alle eingefahrenen Vorstellungen von Objektorientierung und Agilität und Schichtenmodellen hinter sich. Folgen Sie mir einfach auf einer Traumreise in ein anderes Land der Softwareentwicklung… Alles beginnt mit einem Unternehen. Das möchte eine Software in Auftrag geben. Es stellt sich den weltbesten online Shop vor, der es im Nu auf Augenhöhe mit Amazon, eBay und

Was ist Softwarearchitektur – Teil 2

2010-12-06T12:48:00.001+01:00

Softwarearchitektur ist eine der beiden Entwurfsdisziplinen der Softwareentwicklung. Ihr Ergebnis ist die fundamentale Struktur einer Software im Hinblick auf die nicht-funktionalen Anforderungen. Das ist für mich schon eine recht präzise Definition – allerdings eine allgemeine. Sie beantwortet noch nicht alle Fragen in der Praxis. Gehört die Entscheidung für IIS und gegen NT Service eine

Was ist Softwarearchitektur? – Teil 1

2010-12-06T09:11:00.001+01:00

Was ist eigentlich Softwarearchitektur? Dazu kann man natürlich eine Menge lesen. Aber bisher hatte ich deshalb noch kein so richtiges Gefühl dafür. Wissen (im Kopf) und “Gefühlsgewissheit” sind eben nicht dasselbe. Nun hat sich das aber geändert. Jetzt fühle ich, was ich bisher vielleicht schon wusste. Oder ich habe das Gewusste nun so verändert, mir gemäß angepasst, dass ich auch wirklich

Vom Nutzen der Code Kata für das Entwicklerleben

2010-11-22T10:13:00.001+01:00

Grad gibt es ja mal wieder Diskussion um eine Code Kata, die Kata Tennis. Siehe u.a. die Kommentare hier und hier. Anlass war ein online Coding Dojo der Online .NET User Group. Da gehen die Meinungen darüber, wie man am besten zu einer Lösung der Aufgabe kommt, nun auseinander. Das ist gut so. So kommen wir alle weiter, das macht grundsätzlich Spaß. Allerdings hat die Diskussion für mich auch

Wider die Patternmania

2010-11-20T17:08:00.001+01:00

Heute morgen habe ich hier im Blog meinen Ansatz für die Kata Tennis beschrieben. Den kommentierte Björn Rochel mit “Warum so abstrakt? Warum so viel Zeremonie? Eine Alternative wäre bsp. das State-Pattern. Finde ich persönlich deutlich einfacher und lesbarer.” Nach meinem Antwortkommentar bin ich daraufhin aber nicht recht zur Ruhe gekommen. Sein Einwand hat an mir genagt; ich fand meine

Spiel, Satz, Sieg fürs Nachdenken

2010-11-20T12:44:00.001+01:00

Gerade hat die .NET Online User Group die Kata Tennis beim online Coding Dojo bearbeitet. Leider konnte ich nicht teilnehmen. Da in Twitter dazu aber noch anschließend diskutiert wurde, habe ich mir gedacht: Warum nicht die Aufgabe nachträglich angehen? Meine Lösung liegt hier in meinem Mercurial Google Repository. Anders als im Coding Dojo bin ich jedoch nicht streng nach TDD vorgegangen.

Lesenswerte Widerlegung

2010-10-30T10:55:00.001+02:00

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

Private Methoden einfach testen

2010-10-26T20:39:00.001+02:00

In einer Session auf der ADC fragte Stefan Lieser mich heute, ob nicht die dynamischen Features von C# helfen könnten, private Methoden von Objekten zu testen. Erst war ich skeptisch – doch dann half Google. Es geht tatsächlich. Wer das also dringend tun will, der kann es so wie folgt beschrieben tun. Besonders mag das in Brownfield-Projekten helfen. Denn ansonsten ziehe ich es vor, Privates

Wider die Softwarearchaeologie

2010-10-22T18:32:00.001+02:00

Auf der prio.conference habe ich mal die Event-Based Components Dru Sellers vorgestellt, einem der Entwickler des MassTransit Busses. Das war ein sehr interessantes Gespräch in vielerlei Hinsicht. Zu einem Aspekt daraus bin ich dann auch gleich heute zurückgekehrt: der Archaeologie der Software. Frage: Was ist der Unterschied zwischen dem Steinkreis von Stonehenge und einem Klassendiagramm?

Rein in die Matrix!

2010-09-17T17:07:00.001+02:00

Sind Event-Based Components (EBC) ne super Sache oder “krank” (wie gerade in einem Diskussionsforum behauptet wurde)? Tja… ich glaube natürlich, dass sie ziemlich cool sind und was bringen. Der Entwurf von Software wird damit einfacher, die Wartbarkeit, äh, Evolvierbarkeit steigt, die Verständlichkeit ebenfalls und automatisierte Tests brauchen keine Mock-Frameworks mehr. Es gibt auch eine

Die Power von Rx für Event-Based Components

2010-09-07T18:09:00.001+02:00

Ob Event-Based Components (EBC) auch mit den Reactive Extensions, dem Rx Framework von Microsoft implementiert werden könnten, stand als Frage schon länger im Raum. Jetzt hab ich mich mal daran versucht.Als Beispiel habe ich die FizzBuzz Kata gewählt. Der EBC-Entwurf ist denkbar simpel: Bisher wurde dann eine EBC-Aktion wie Zahl transformieren so übersetzt: 1: class Zahl_transformieren_früher

Abhängigkeiten bewusster wahrnehmen

2010-09-07T11:11:00.002+02:00

Abhängigkeiten sind eine der größten Geißeln der Softwareentwicklung. Wenn es ein allgemein anerkanntes Prinzip gibt, dann ist es, Abhängigkeiten zu minimieren. Jede Hilfe ist da willkommen. Was können Sie also tun, um Abhängigkeiten im Code los zu werden?Für die Suche nach einer Lösung und die Beurteilung von Hilfsangeboten ist es nützlich, Abhängigkeiten zu kategorisieren. Nicht alle

Lesen heute für Softwareentwickler

2010-09-05T00:43:00.001+02:00

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

Die Weite des Merkmalhorizonts

2010-08-27T10:37:00.001+02:00

Golo will die räumliche Nähe für Teammitglieder nicht weiter überschätzen, Ilker will sie nicht unterschätzen. Mit seinem “Gemeinsam für die gemeinsame Sache” drückt er sogar aus, dass bei räumlicher Distanz keine Gemeinsamkeit mehr ent-/bestehen könne. Ja, was denn nun? Golos Fahne folgen in das bisher weniger erforschte Land verteilter Teams oder eher in der bisherigen Reisegruppe der

Präzisierung eines Rahmens für TDD

2010-08-26T09:29:00.001+02:00

TDD ist nur ein Tool. Deshalb kann man TDD nicht nur besser oder schlechter bedienen, sondern auch angemessen oder unangemessen benutzen. Gestern beim 4. Coding Dojo in Hamburg gab es für beides Beispiele. Das war schön, denn so konnten wir etwas lernen. Über die “Bedienung” des TDD-Werkzeugs ist anderswo schon einiges geschrieben worden. Dazu gehört die Einhaltung des Red-Green[-Refactor]-

Das Domänobjektmodell anders gedacht [OOP 2010]

2010-08-23T20:22:00.001+02:00

Mit der vorherrschenden Sichtweise, was ein Domänenobjektmodell sein soll, bin ich nicht einverstanden. Meine Kritik habe ich in diesem Posting geäußert. Wie soll es denn aber sonst gehen? Um meine Vorstellung von einem Domänenobjektmodell zu beschreiben, versuche ich am besten, Jimmy Nissons Beispiel auf meine Weise umzusetzen. In “Applying Domain-Driven Design and Patterns: With Examples in C#

Nähe oder Distanz, das ist hier die Frage

2010-08-22T01:49:00.001+02:00

Sollen Softwareteams in einem Raum arbeiten? Diese Frage haben die Agilisten ganz klar mit Ja beantwortet. Wohin man schaut die Empfehlung, Entwickler möglichst nah zusammen zu setzen. Vor kurzem hat Martin Fowler sich daher bemüßigt gesehen, Empfehlungen für die Gestaltungsfreiräume des Team Room zu geben. Damit könnte doch das Thema ein für alle Mal zur Ruhe gebettet werden, oder? Setzt die

Leiden am Domänenobjektmodell [OOP 2010]

2010-08-10T09:51:00.001+02:00

Ist die Objektorientierung wirklich auf dem richtigen Weg? Grad habe ich wieder so eine Phase, wo ich mich das frage – und immer auf die Antwort komme: Es ist etwas grundsätzlich falsch mit der Objektorientierung. Halt! Stopp! Ich meine nicht, dass wir keine Klassen mehr haben sollten. Auch die Vererbung muss nicht abgeschafft werden. Ebensowenig Polymorphie oder Interfaces. Alles wunderbar.

Was treibt uns an?

2010-08-03T13:35:00.000+02:00

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

Quando, quando, quando? Vom Zeitpunkt für automatisierte Tests

2010-07-18T15:44:00.001+02:00

Grad lese ich Thomas Bandts öffentliche Gedanken zur Frage, ob und wann TDD denn sinnvoll sei. Die treibt ja viele um. Immer wieder. Und so glaube ich, dass irgendwas an ihr noch nicht stimmt. Irgendwie ist die Perspektive falsch. Wenn es in einer Partnerschaft krieselt und sie klagt “Immer bringst du den Müll nicht runter!” worauf er fragt, “Wann soll ich den Müll denn runterbringen? Wenn die

Die Rückkehr der Täter – EBC-Prozesse übersetzen

2010-07-18T13:35:00.001+02:00

Einen Moment das objektorientierte Denken auszusetzen, darum hatte ich Sie in ???meinem Blogartikel über die nächste Entwicklungsstufe von EBCs gebeten. Ich weiß, das ist eine große Bitte gewesen. Deshalb möchte ich Ihr Wohlwollen auch nicht länger strapazieren. Kommen Sie zurück in die Welt der Objekte bzw. Klassen und der Komponenten. In diesem Artikel möchte ich Ihnen zeigen, wo Klassen ihren

Prozesse klammern

2010-07-16T12:08:00.001+02:00

Prozesse, Tätigkeitsfolgen, Herstellungsschritte stehen für mich derzeit am Anfang des Softwareentwurfs, wie ich hier beschrieben habe. Aus Anforderungen lassen sich nur schwer Klassen als Verantwortliche einer Lösung ableiten. Viel einfacher ist es, die Tätigkeiten zu ermitteln, die in Summe den Wunsch eines Anwenders erfüllen. Wenn Sie ins Restaurant gehen, dann wollen Sie ein leckeres Essen.

Code als Fabrik – Event-Based Components weitergedacht

2010-07-15T23:08:00.001+02:00

Ein Gedanke, der mich gerade nicht loslassen will ist, dass Code eigentlich eine Fabrik ist. Seit EVA wissen wir es eigentlich: “Eingaben verarbeiten zu Ausgaben” ist die Aufgabe von Code. Im Laufe der Objektorientierung scheint mir das jedoch in Vergessenheit geraten zu sein. Statt um einen Fluss von Datenquelle zu Datensenke geht es der OOP um Zustand. Kochtopf statt Durchlauferhitzer. Und das

Testnähe aus der Distanz betrachtet

2010-07-13T13:39:00.001+02:00

Die Diskussion um den besten Platz für Tests reißt nicht ab. Nach meiner Gegenüberstellung zweier Testplatzierungsstile hat Stefan nachgelegt und nun Ilker gekontert. Die WM ist vorbei, der Testball aber noch im Spiel… :-) Was für ein Spiel ist das aber? Ist es ein Nullsummenspiel? Und worum dreht es sich? Die erste Frage ist, was “nah am zu testenden Code” bedeutet. die zweite Frage, ob Nähe das

Mit vielen Gehirnen entwirft man besser [OOP 2010]

2010-07-11T19:50:00.001+02:00

Was macht einen erfahrenen Entwickler aus? Dazu habe ich grad hier etwas gelesen und bin beim “Mid-Level Developer” (beim “Mittelmäßigen” möcht ich da mal nich rauslesen ;-) auf diesen Satz gestoßen: “Can work from user stories” Was bedeutet das? Ich habe herausgelesen: “Der mid-level Developer kann das, was er am Quellcode zu tun hat, selbstständig aus User Stories ableiten.” Stimmen Sie mit

Zeig mir deinen Code und ich nenn dir deinen Dojo-Stil

2010-06-29T11:05:00.001+02:00

Die Coding-Dojo-Welt hat sich geteilt. Es gibt nun den münchener Latifa-Stil von Ilker. Und es gibt den Schwarm-Stil von Stefan Lieser und mir. Bei der Teilung hat es ein wenig gerumpelt in der Community – aber nun sollten wir in friedlicher Koexistenz coden können. Die Welt ist halt bunt. Den einen wahren, kanonischen Coding-Dojo-Stil gibt es nicht. Es gab und gibt nur Interpretationen dessen,

Kollektiv intelligent codieren

2010-06-26T20:50:00.001+02:00

Wenn ein einzelner Entwickler etwas codiert, dann hat das Ergebnis eine gewisse Qualität. Und wenn mehrere Entwickler zusammen etwas codieren, dann sollte das eine höhere Qualität haben. Oder? Wie die sprießenden Coding Dojos zeigen, ist das nicht der Fall. Da mag der Spaß noch so groß sein, da mag die Motivation hoch fliegen – die Ergebnisse sind meist schlechter, als wenn ein einzelner

Zwischenmahlzeit: Kurzvorträge zum Mittag in Karlsruhe, freier Eintritt

2010-06-08T11:17:00.001+02:00

Wer mag sich zwischendurch inspirieren lassen? Das ist nämlich am Donnerstag 10. Juni 2010 in Karlsruhe möglich. Leicht verdaubare Happen für den Entwicklergeist statt Suppenkoma bieten nämlich acht Abschlussvorträge eines Rhetoriktrainings. Von 13:00 Uhr bis ca. 14:30/15:00 Uhr halten die Absolventen des Trainings 10-15 minütige Kurzvorträge in der Albert-Nestler-Str. 10 im Raum Paris des

Intensiv, im Team, kostenlos – Das Clean Code Developer Praktikum

2010-06-04T12:24:00.001+02:00

Clean Code Developer (CCD) werden, hat weniger mit Technologien zu tun, als vielmehr mit Gewohnheiten und Konzepten. CCD-Tugenden zu vermitteln stellt daher besondere Anforderungen an Trainer. Wie stellen die dann sicher, dass sie sie erfüllen? Stefan Lieser und ich haben in den letzten 14 Monaten einige CCD-Trainings durchgeführt und fühlen uns durchaus wohl mit den Ergebnissen. Aber wir

Wenn das Ziel der Weg ist – Über typische Verwechslungen [OOP 2010]

2010-06-03T20:47:00.001+02:00

Erfolgreiche Typen haben immer klare Ziele. Ohne Ziele geht nix. “10% mehr Umsatz im nächsten Jahr!” oder “Maximal 1 Bug Report pro Monat im Support” oder “Feature X bis zum 30.6.2010 realisieren” – das sind Ziele für echte Männer (und gern auch Frauen, wenn sie sich angesprochen fühlen). Die sind auch total SMART – ist zumindest in Bezug auf A=Attainable und R=Relevant zu hoffen. Soweit der

Remote Communication mit Event-Based Components und Application Space

2010-06-03T15:33:00.001+02:00

Wie Asynchronizität über “Zwischenstücke” in eine EBC-Architektur eingebaut werden kann, habe ich in einem früheren Blogposting beschrieben. Jetzt ist in der myCsharp.de Community die Frage aufgetaucht, wie denn eine verteilte Architektur mit EBCs realisiert werden könnte. Die einfache Antwort: genauso ;-) Damit meine ich, dass das, was zum Aspekt remote communication gehört, in eine EBC

Die Ubiquitous Language konsequent codieren [OOP 2010]

2010-06-01T17:12:00.001+02:00

Das war mir doch ein Experiment wert: Wie würden es Entwickler aufnehmen, wenn quasi alle Parameter von Methoden (zumindest in den Kontrakten von Komponenten) nicht primitiv sein sollen? Auf dem Coding Dojo in München habe ich es ausprobiert. Das Beispielszenario dort war eine Rechtschreibprüfungsanwendung. In der gibt es dann irgendwo eine Funktion WortKorrekt() o.ä. Deren Signatur würde

Gezieltes Coding Dojo

2010-05-31T19:50:00.001+02:00

Dass das Coding Dojo am 26.5.2010 kein Coding Dojo war, darüber sind Ilker und ich uns durchaus einig. Der Rahmen war zwar der des üblichen Münchner Dojos – der Inhalt wich dann jedoch stark davon ab. Ilker hat diese Abweichung jetzt nochmal begründet und ich habe auch schon innerhalb dieser bezweckten Abweichung reflektiert. Was bleibt da noch zu sagen? Messlatte #1: Die offizielle

Für mehr Qualität im Netz durch Identität [OOP 2010]

2010-05-31T10:15:00.001+02:00

Auch mal anonym sein dürfen, ist ne schöne Sache. Keine Frage. Deshalb lieben wir das Bargeld immer noch. Ihm haftet nichts von uns an; damit können wir genauso Geschenke wie “Schmuddelkram” kaufen, ohne dass eine Spur auf dem Bankkonto entstünde, die uns verraten könnte. Und auch sonst finden wir es entspannend, nicht überall und immer erkannt zu werden. Die Berühmten beneiden wir ja eher nur,

Coding Dojo Muc Retrospektive

2010-05-30T19:25:00.001+02:00

Softwareentwicklung mit Energie – die war wieder mal zu sehen beim Coding Dojo in München. Knapp 30 Entwickler waren zusammengekommen, um sich in geselliger Runde in der .NET Programmierung anhand einer Aufgabe zu üben. Das Coding Dojo Muc hat sein Format und seinen Rhythmus. Im Fokus steht gewöhnlich die testgetriebene Entwicklung (TDD) einer Funktionalität, die sich mit einer Funktion als API

Überraschende Relevanzwellen [OOP 2010]

2010-05-24T16:13:00.001+02:00

Schon interessant, was zu Wellen im Twitter-Teich führt. Da stolpere ich während der Lektüre von “Projektmanagement” von Thorsten Reichert beim “Zusammenfassungsservice” getAbstract über den Satz „Viele Unternehmen haben nie Zeit, Dinge richtig zu tun, aber stets Zeit, Dinge mehrmals zu tun.” Den twittere ich – und erzeuge unerwartet weitreichende Reaktionen. Wow! Nicht, dass mich die

Biosphere 2 - Sind Wissensinseln “böse”? [OOP 2010]

2010-05-21T01:15:00.001+02:00

Grad kommt alles zusammen. Ich lese einen Thriller über die Evolution, die auf einer abgeschiedenen Insel zu sehr bösen Kreaturen geführt hat (“Biosphere” von Warren Kaye). Dann höre ich Jens Coldewey auf der SET in Zürich, der darüber spricht, wie böse es für Projekte ausgehen kann, wenn sie sich nicht gegen Inseln wehren, gegen Wissensinseln. Und dann spreche ich am selben Tag mit Ivan Engler

Kaffeehauskonsultation in München

2010-05-10T10:57:00.001+02:00

Am Donnerstag 27.5.2010 ist es wieder so weit: kostenlose Beratung in Sachen .NET Softwareentwicklung in München. Von 10h bis 17h können Sie mich in meiner “Praxis” konsultieren. Die öffne ich im Café Mozart und bin gespannt, worüber wir uns unterhalten. Sie finden mich dort “im Hinterzimmer” für die Kaffeehauskonsultation. Bringen Sie Ihren Laptop mit, dann können wir uns auch Ihren Code