Neal Ford auf der RheinJUG: Emergent Design & Evolutionary Architecture

3 Kommentare

Gerade frisch zurück von der RheinJUG und einem großartigem Vortrag von Neal Ford. Passend zu unserem kommenden Meet the Experts – Architecture war Neals Thema „Emergent Design & Evolutionary Architecture“. Die Folien finden sich auf Neals github, also fasse ich mich auch kurz und möchte nur meine persönlichen Eindrücke kurz schildern.

  1. Neal bestätigt unser Credo bei codecentric: Der Code ist das wichtigste. Code ist design, Code ist Architektur. Alles was kein Code ist (auch Kommentare) ist nicht so wichtig, weil es nicht Teil des vom Compiler zu unserem Produkt Übersetztem ist. Die gleiche Idee findet sich in ausführbaren Spezifikationen über die Thomas vor ein paar Tagen schrieb. Neal betonte auch die Wichtigkeit einen sauberen Code zu haben und Baustellen umgehend zu beseitigen. Code solle mit der Zeit besser werden, nicht schlechter.
  2. Neal verglich Architektur mit Design. So seien sie sich sehr ähnlich, aber Architektur sei beständiger während Design sich an den Geschäftsproblemen orientiert, welche sich häufig ändern.
  3. Er klassifiziert Komplexität in zwei Gruppen. Es gibt inherente Komplexität eines Problems, welches die Komplexität ist um die wir uns eigentlich kümmern müssten um ein Problem zu lösen. Oft führen wir aber selbst versehentliche Komplexität ein, indem wir zu generische Lösungen skizzieren. Man kann sie zwar bekämpfen indem man versucht Entscheidungen zu verzögern bis sie notwendig werden und man ausreichend Informationen erlangt hat. Außerdem sollte man die einfachen Lösungen bevorzugen, da man komplexer eigentlich immer werden kann, einfacher hingegen eher nicht.

Es gab noch viele weitere gute Ideen in seinem Vortrag. Da Neal einen hervorragenden Präsentationsstil hat hätte ich ihm noch den ganzen Abend zuhören können 🙂

Falls Ihr auch heute Abend auf der JUG wart: Was habt ihr mitgenommen?

PS: Pac Man wird nie wieder so sein wie vorher 😉

Fabian Lange ist Lead Agent Engineer bei Instana und bei der codecentric als Performance Geek bekannt. Er baut leidenschaftlich gerne schnelle Software und hilft anderen dabei, das Gleiche zu tun.
Er kennt die Java Virtual Machine bis in die letzte Ecke und beherrscht verschiedenste Tools, die JVM, den JIT oder den GC zu verstehen.
Er ist beliebter Vortragender auf zahlreichen Konferenzen und wurde unter anderem mit dem JavaOne Rockstar Award ausgezeichnet.

Share on FacebookGoogle+Share on LinkedInTweet about this on TwitterShare on RedditDigg thisShare on StumbleUpon

Kommentare

  • Andreas Ebbert-Karroum

    Ich würde neben der inherenten und der versehentlichen Komplexität (die ich übrigens von Ford ziemlich schlecht benannt finde — oder ich hab die noch nicht ganz verstanden) noch einen Begriff einführen wollen, der die Komplexität beschreibt, die aus Unwissenheit entsteht. Wenn ich Ford richtig verstehe beschreibt die versehentliche Komplexität das, was wir meinen tun zu müssen, um die einem Problem inherente Komplexität aufzulösen, und dabei über’s Ziel hinausschießen.

    Was ist mit der Komplexität aus Unwissenheit? Weil man es einfach so gewohnt ist zig Frameworks aneinander zu stöpseln, von denen aber immer nur maximal 5% der Funktionalität braucht, handelt man sich ja auch eine Menge Komplexität ein, die man eventuell nicht braucht. Man macht es aber, weil man es nicht besser weiß. Ist das für Ford auch in der versehentlichen Komplexität enthalten?

    P.S. Ist „versehentliche Komplexität“ eine feste deutsche Übersetzung von „accidential complexity“? Ich hätte das eher mit unbeabsichtigt übersetzt. Der unterschied ist zwar nur marginal, aber ich finde, das passt besser 😉

  • Fabian Lange

    ja es ist „accidental complexity“. Man könnte auch zufällige Komplexität sagen.
    Unwissenheit zählt auch zu „accidental“, denn das ist das Gegenteil von der inherenten Komplexität.
    Als Gegenmaßnahme verweist er darauf umfassende Entscheidungen zulange zu verzögern bis man die Probleme besser verstanden hat.

    Beispiel: Wir müssen einen Webservice aufrufen -> ESB einbauen.
    Am Ende stellt sich heraus es wir ein einziger Webservice im gesamten Projekt gebraucht, der auch so einfach ist, daß man ihn auch selber hätte ansprechen können.

  • Uwe Friedrichsen

    Das mit der Architektur hast Du m.E. nicht richtig wiedergegeben. Neal hat gesagt, dass das Ergebnis des Designs in der Software-Entwicklung Code ist, d.h. Design=Code. Dieser Aussage kann ich nach seiner Begründung auch weitestgehend zustimmen.

    Vergleichbares hat er über Architektur aber definitiv nicht gesagt (und würde m.E. auch keinen Sinn machen), d.h. die Aussage „Code ist/= Architektur“ gilt in der Form nicht. Natürlich sollte sich die Architektur im Code wiederfinden, aber der Code ist nicht die Architektur, sandern ein Design (um bei der Idee von Neal zu bleiben), das die Ideen der Architektur umgesetzt hat.

    Auch die zweite Aussage hat er m.E. nicht gemacht. Er sagte, dass Architektur die „wichtigen Dinge“ (gemäß Fowler) bzw. die Dinge, die sich später nicht mehr gut ändern lassen, adressieren muss, während Design im Normalfall auch später noch gut änderbar sein sollte. Das hatte er mit Hilfe des metaphorischen Bilds mit der Klötzchenpyramide dargestellt, wo er die unteren Klötzchen „Architektur“ und die oberen Klötzchen „Design“ genannt hat. (Okay, diese Definition von Architektur ist mir persönlich eigentlich ein wenig zu schwach, aber das ist ein anderes Thema, lassen wir sie also einfach mal so stehen … 😉 )

    Er hat aber nicht gesagt, dass sich Design an Geschäftsproblemen orientiert und Architektur nicht. Eine solche Aussage wäre m.E. fatal. Natürlich sollte man ein System so konzipieren und umsetzen, dass man in der Lage ist, auf sich tpyischerweise häufig ändernde Geschäftsanforderungen gut zu reagieren und als eine Konsequenz daraus sollte man z.B. nicht vorzeitige Entscheidungen treffen, usw., aber das betrifft *alle* Bereiche der Software-Entwicklung, nicht nur das Design … und insbesondere auch die Architektur. Eine Reduzierung der Umsetzung von Geschäftsanforderungen auf das Design hat Neal in der Form auch nicht gesagt.

    Verzeihe meine Kleinlichkeit, aber ich denke, dass diese Unterschiede in der Praxis essentiell sind und Missverständnisse da zu fatalen Folgen führen können. Da ich außerdem fand, dass Neal einen in Summe echt guten Vortrag gemacht hat (auch wenn er für meinen Geschmack gelegentlich nicht so recht in der Lage war, die reine Entwicklerbrille abzulegen und eine etwas übergeordnete Sichtweise einzunehmen, die alle Stakeholder eines IT-Systems angemessen betrachtet), wollte ich diese Punkte zur „Ehrenrettung“ von Neal doch nicht unkommentiert lassen … 😉

Kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.