Follow my new blog

Montag, 18. Juli 2011

Design zur Diskussion gestellt

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:

image

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 Architektur eine Sache, die habe nichts mit Softwareentwicklung zu tun, sondern mit Gebäuden.

Und Keith Brown, den wir für seine Bücher zu COM+ und Windows Security mögen, stimmt ihm zu.

Kann das sein? Ich zumindest kann kaum glauben, dass erwachsene Softwareentwickler so über ihre Zunft (es sind ja Software Craftsmen) denken.

Oder hier noch ein Beispiel:

image

Die Formulierung, auf Design und Implementation müsse man ständig gleichzeitig achten, hat er auch in anderen Postings der Gruppe benutzt. Allerdings ist er auf Nachfragen wiederholt eine Definition von Design schuldig geblieben. Auch mochte er noch nicht einmal Design gegenüber Implementation abgrenzen. Immer nur das Mantra, man müsse beides (und noch viel mehr) ständig im Blick halten.

Kann das sein? Immerhin ist das Ron Jeffries, einer der Gründerväter der Agilitätsbewegung. Und der mag als quasi schon fundamentalistischer Vertreter von TDD = Test-Driven Design (!) nicht definieren, was denn Design sei? Merkwürdig.

Gelinde gesagt bin ich verwundert. Was ist los in unserer Branche? Oder ist das nicht unsere Branche, sondern eben nur eine gewisse zeitgeistige Strömung? Hm… immerhin äußern sich hier prominente Vertreter unserer Kunst.

Oder verstehe ich da fundamental etwas falsch? Ich dachte immer, wenn man Begriffe benutzt, dann sollte man auch ziemlich genau wissen, was sie bedeuten. Wer also “Design” im Munde führt, der sollte eine Definition davon in Bezug auf unser Metier geben können. Dasselbe gilt für Architektur. Oder wer keine knappe Definition hinkriegt, der sollte zumindest typische Fragen benennen können, die zu Design oder Architektur gehören – und andere, die eben nicht dazu gehören. Aber auch das bleibt in dem Thread aus.

Ich bin also verwirrt. Aber vielleicht können Sie bzw. vielleicht kann mir die Leserschaft meines Blogs helfen?

1. Sind Software Design und Software Architecture nützliche Begriffe für unsere Branche?
2. Wenn ja, wovon sind sie abzugrenzen?
3. Wenn ja, was sind typische Fragen, die ein Software Design beantwortet?
4. Wenn ja, was sind typische Fragen, die eine Software Architecture beantwortet?
5. Wenn ja, was sind vielleicht Fragen, die beide eben nicht beantworten?
6. Wenn nein, warum nicht?

Ich bin gespannt, ob wir hier mehr Substanz für die Frage nach Relevanz und Definition dieser Begriffe zusammen bekommen.

PS: Jetzt ist noch dieser Beitrag zur Diskussion hinzugekommen:

image

Ron Jeffries spricht also für alle Craftsmen, wenn er sagt, sie glaubten an Design, haben jeder für sich eine persönliche Meinung dazu, was das wohl sei (“internal meaning of it”) und seien einfach zuversichtlich, dass diese vielen Meinungen ziemlich eng beieinander lägen (“close enough to the same thing”).

Leider lässt mich auch diese Äußerung wieder sprachlos zurück. Sehr öffentliche Figuren der Branche sind sich also nicht zu schade, ihre Arbeit auf unsausgesprochene Bedeutungen zentraler Begriffe zu gründen? Es reicht ihnen die Hoffnung, dass man in Diskussionen schon dasselbe meine? Und weil es nun schon ein halbes Jahrhundert so unscharf zugegangen sei, müsse man sich nun doch auch nicht mit expliziterer Definition quälen?

Nein, sorry, da komme ich nicht mehr mit. Hier verliert sich ein Zweig der Softwareentwicklung für mich in “Pseudowissenschaft”. Denn die beginnt, wo Behauptungen nicht falsifizierbar sind. Und Falsifizierbarkeit basiert auf klaren Definitionen.

41 Kommentare:

Thomy hat gesagt…

Beides Begriffe sind ja bereits ausserhalb der SW-Branche mit Semantik belegt gewesen - und sind es noch. Moeglicherweise sind sie aber im deutschen und englischen Sprachraum anders belegt.

Vielleicht liegt da schon einer der Gruende fuer die Verwunderung...

Mike Bild hat gesagt…

1. Sind Software Design und Software Architecture nützliche Begriffe für unsere Branche?

IMHO - ja, denn sie beschreiben den Prozess der Reflektion, Analyse, Strukturierung und der Organisation. Damit wird der Entstehungsprozess spürbar und methodisch.

2. Wenn ja, wovon sind sie abzugrenzen?

Vor allem von Try and Error, Spikes und Prototyping. Anforderung mangelnd vorhanden und möglicherweise unzureichend verstanden, basteln und drauf los hacken bis es irgendwie läuft.

3. Wenn ja, was sind typische Fragen, die ein Software Design beantwortet?

Wie wird Code strukturiert?
Wo, wie und warum gibt es Konventionen?
Ist der Code testbar?
Ist der Code zielführend, lesbar und verständlich?
Entsteht beim lesen ein reproduzierbares mentales Konzept des Autors/der Autoren?

Wenn ja, was sind typische Fragen, die eine Software Architecture beantwortet?

Plattform, Technologien, Produkte, Kommunikation, Protokolle, Prozesse, Hosting, Build, Deployment.

5. Wenn ja, was sind vielleicht Fragen, die beide eben nicht beantworten?

Arbeitsorganisation, Teamorganisation,
Anforderungserfassung und Done-Criterias, Usability und UI Design, naja und sicher auch noch mehr ;-)

6. Wenn nein, warum nicht? Ich bin gespannt, ob wir hier mehr Substanz für die Frage nach Relevanz und Definition dieser Begriffe zusammen bekommen.

Nützlich sind sie nur außerhalb einer Personalunion. Sollte ich alle (oder min. 2) Rollen inne haben, ist eine Definition im Sinne der Fragestellung eher hinfällig. Die Abgrenzung verschwimmt und wird mit genügend Erfahrung auch mehr und mehr unnötig. Meiner Meinung nach spielt eine Abgrenzung erst bei min. 3 Teammitgliedern seine wahren Stärken aus.

m2c - Ciao, Mike

NX hat gesagt…

Design ist vielleicht sehr allgemein erstmal ein kreativer Vorgang, bei dem die richtigen Wege für zuvor bestimmte Ziele gesucht und reflektiert werden, während man diese Wege beim Implementieren dann schließlich auch geht. Design ist das Herstellen von 'Eignung'.

Vielleicht kommt man aber auch mit Begriffen wie Ästhetik o.ä. weiter. Carlo Pescio hat einen interessanten Blog, der wohl in diese Richtung führt. Er redet dort von Symmetrien, Kräften, einer Physik der Software. Er meint: "For a designer, Software is a material to be shaped"

PMM hat gesagt…

Ich habe vor allem Probleme mit dem Begriff "Software Architecture".
Das ist schon in sich ein Widerspruch: Hier Architektur, die letztendlich darauf zielt sehr harte Gebäude zu erstellen - dort die Software die schon das "weiche" im Namen führt.
Es mag eine gewisse Zeit lang wichtig gewesen sein die Software Community mit der Nase darauf zu stoßen, was andere Ingenieur-Disziplinen so hervorgebracht haben um das Problem der Komplexität (denn darum geht es im Kern) in den Griff zu bekommen, aber er verstellt leider den Blick auf das, was Software auszeichnet: Es gibt am Ende kein Produkt im herkömmlichen Sinne, der Plan ist schon das Produkt, der Plan ist, vordergründig sehr leicht, jederzeit änderbar, es gibt nicht so was wie einen "Störabstand" oder "Überlastfaktor" mit dem man das Problem der "Robustheit" angehen könnte, alles ist hochgradig nicht linear (in dem Sinne, das große Änderungen nahezu kein Auswirkungen, kleine Änderungen aber durchaus gewaltige Auswirkungen haben können).
Ich denke, es ist Zeit diese besondere Natur der Software in den Vordergrund zu stellen, ohne das über Bord zu werfen, was man aus den traditionellen Ingenieurwissenschaften lernen kann. Software-Entwicklung zielt auf Programme / Programmsysteme - Architektur auf Gebäude / Gebäudekomplexe. Es gibt Schnittmengen ja, interessant - und kompliziert - wird es außerhalb derselben...

Anonym hat gesagt…

Mir kam ähnliches in den Sinn wie es bereits Thomy beschrieben hat.

Robert Mischke hat gesagt…

Ich finde in Ordnung in verschiedenen Zusammenhängen Begriffe unterschiedlich zu belegen, weswegen mit Entwurf (Design) in der Softwarebranche verschiedene Dinge gemeint sein können.

Passiert der Entwurf in Testgetriebener Manier dann ist natürlich ein Teil der Implementierung gleich dem Entwurf. Werden Kreise und/oder Kästchen gemalt, dann sind Entwurf und Implementierung verschiedene Ebenen. Passiert ein Entwurf nur in Gedanken – nun ja – ist das auch immer noch Entwurf.

Gemeinsamer Nenner ist der schöpferische, planende Teil.

((Was Kent Beck als eine gute Entwurfsvorgehen versteht, hat er ja lang und breit probiert in seinen TDD Buch darzulegen u. hat damit seine Definitionsschuldigkeit auch ein bisschen abgeleistet.))

(Ich glaube Ron Jeffries Antwort wollte sich nicht wirklich auf die Design Diskussion einlassen – weil für in der Begriff geklärt ist.)

Ralf Westphal - One Man Think Tank hat gesagt…

@PMM: Wenn du mal hier (http://de.wikipedia.org/wiki/Architektur) liest, was es für Definitionen von Architektur gibt, dann wirst du finden, dass das nicht immer mit Mörtel, Holz, Stein usw. zu tun hat. Beispiel:

"Harmonie und Einklang aller Teile, die so erreicht wird, dass nichts weggenommen, zugefügt oder verändert werden könnte, ohne das Ganze zu zerstören."

Mir geht es ja nicht um eine bestimmte Begriffsdefinition, deren Anerkennung ist durchsetzen will, sondern überhaupt eine.

@Robert: Denn nur wenn es eine klare Definition gibt, dann kann ich auch prüfen, ob jemand in dieser Hinsicht hohe Qualität liefert.

Die Definition mag ja auch verschiedene Aspekte haben und sagen, "Für den Bereich XYZ ist Entwurf wie folgt definiert..., für den Bereich ABC ist Entwurf wie folgt definiert... Allen Entwurfsbegriffen ist gemein, dass..."

Aber man schreibe es doch bitte einmal auf. Was ist "Entwerfen" (Verb), wie sieht das Ergebnis dieser Tätigkeit aus, der Entwurf (Substantiv)?

Wer von Entwerfen spricht, sollte davon eine Vorstellung haben. Die Freunde des TDD sprechen andauernd davon (Testgetriebener Entwurf) - aber die Äußerung ihrer Vorstellung bleiben sie schuldig. Wenn für Ron Jeffries der Begriff so klar ist, dann vergibt er sich ja nichts, diese Klarheit in 2-3 Sätzen einfach einmal auszudrücken; und sei es auch unter Augenrollen und Unverständnis dafür, dass jmd anderem der Begriff noch nicht so klar ist wie ihm ;-) Das tut er aber nicht.

Nochmal: Mir ist es egal, ob es für "Design" oder irgendeinen anderen begriff eine Definition gibt, solange der Begriff nicht in allgemeinem Gebrauch ist.

Sobald jedoch alle Welt einen Begriff im Munde führt, erwarte ich, dass alle Welt sich auch Mühe gibt, ihn möglichst schwarf zu formulieren. Das mag dann nicht auf anhieb funktionieren, doch über die Zeit sollten die Definitionsversuche konvergieren. Ist das nicht der Fall, gibt es wohl ein dahinter liegendes Problem, um das man sich mal kümmern sollte.

Kommt am Ende etwas Perfekts raus? Ne. Immer nur eine good enough Definition. Nur die ist eben auch explizit. Wäre sie es nicht, wäre sie keine. Wo es sie nicht gibt, gibt es sie nicht und sie ist nicht mal good enough.

Zu Kent Beck: Der mag mit seinem TDD Buch etwas zum Thema Design geleistet haben - nur hat er auch darin gesagt, was Design ist? Oder gab es nur Handwedeln mit einem Hinweis wie "Irgendwie ist das, was am Ende von TDD herauskommt, auch ein Entwurf."? (Und wenn ja, wovon ein Entwurf? Von Quellcode oder von Maschinencode?)

Robert Mischke hat gesagt…

@Ralf, für TDD ist der Entwurf die Implementierung. In anderen Vorgehen besteht der Entwurf aus Diagrammen, wieder in anderen ist der Entwurf nur gedanklich.

Die Tätigkeit entwerfen entspricht zielgerichtetem denken(?). Sie kann mit Papier und Bleistift oder in der Dusche ausgeführt werden.

Mit EBC bringst Du auch neue Strategien für Entwurf und entwerfen ein.

Ein klares Verständnis von Entwurf und entwerfen zu haben, scheint mir auch sehr sinnvoll. Der Blogpost das aktive Kommentarschreiben hat mich da sehr weiter gebracht :-)

Anonym hat gesagt…

Bedeutung des Wortes Entwurf oder Design ist zu abstrakt um „Software Entwurf“ zu erklären. Und die Bedeutung des Begriffs „Software Entwurf“ ist zu abstrakt um das mit paar Sätzen zu erklären. Wie schon meine Vorredner gemacht haben wird die Abstraktions Level verkleinert, z.B. definiere Design in TTD usw. Das würde schon ausführlich gemacht. Man bekommt also keine benutzbare Erklärung was ist „Software Entwurf“ genauso wenig wie was ist „Mode Entwurf“ bis man den Kontext definiert. Kontext definiert man nicht weil dann’s für Allgemeinheit nicht verwendbar wird. Die Gurus sind halt schlau …

Ralf Westphal - One Man Think Tank hat gesagt…

@Anonym: Ich habe keinen Anspruch an eine möglichst kurze Definition irgendwelcher Begriffe. Sie sollen angemessen sein. So kurz wie möglich, so lang wie nötig.

Und wenn du meinst, ein Kontext sei nötig (also eine Form von Eingrenzung), um "Software Design" oder "Software Architecture" zu definieren, dann ist das doch völlig ok.

Dass eine Begriffsdefinition jedoch nicht möglich sei... Bitte, das kannst du nicht ernst meinen. Denn wenn das so wäre, dann sollten wir besser aufhören, den Begriff zu benutzen. Nicht definierte oder gar undefinierbare Begriffe gehören nicht in eine Fachsprache. Sie sind das genaue Gegenteil.

Wenn nicht alle Begriffe immer sofort bei erstem Gebrauch klar definiert sind, dann mag das angehen. Ist womöglich sogar natürlich, weil sich Definitionen erst im Verlauf eines sich ausdehnenden Gebrauchs herausbilden/stabilisieren.

Nach 50 Jahren Softwareentwicklung halte ich das nun aber für erwartbar. Wir wissen genau, was ein Compiler ist oder was Skalierbarkeit bedeutet. Architektur und Design jedoch, sind nachwievor für weite Teile der Enrwicklergemeinde schwammig. Das kann nicht sein.

Wenn wir hier über Gedichte oder Trance reden würden, ja, dann wäre Unbestimmtheit womöglich eine Tugend. Für Poesie und andere Bewusstseinszustände ist es hilfreich, wenn sich jeder so seine eigenen Gedanken und Gefühle machen kann.

Aber Softwareentwicklung ist mit vielem verglichen worden, nur nicht mit Dichtung. Deshalb sollten wir uns eher auf die Tugenden von Wissenschaft und Technik beziehen, würde ich sagen.

Das größte Problem in Teams sind Uneinheitlichkeiten. Dazu gehören Uneinheitlichkeiten im Verständnis zentraler Begriffe. Wir sollten also alles dafür tun, um Uneinheitlichkeiten aus dem Weg zu räumen. Wie Ron Jeffries darauf zu vertrauen, dass da schon in den vielen Köpfen genügend ähnliche Vorstellungen von solchen Begriffen existieren mögen, halte ich deshalb für naiv bis fahrlässig. Ron hat eine Menge geleistet für die Branche. Bravo! Deshalb muss ich ihm aber nicht ständig an den Lippen hängen; und hier ist für mich ein solcher Fall, wo er für mich keinen Guru-Status verdient.

Unknown hat gesagt…

Für mich sind die Begriffe "Design" und "Architektur" in der Software-Welt gleichwertig. Das heißt, sie beschreiben das Selbe.

Was ist das Design/die Architektur einer Software?
Das sind für mich Dinge, die nicht an konkrete Implementationsdetails oder Technologien gebunden sind.

Was sind Implementationsdetails?
Das sind die Dinge, die zeigen, wie das Design/die Architektur umgesetzt wurde.


Das Design/Die Architektur der Software könnte man z.B. einem Laie erklären. So, wie man das auch bei dem Google Chrome Browser in Form eines Comics getan hat: KLICK
Genau das würde ich als Software-Design/Software-Architektur bezeichnen.
Implementationsdetails findet man in dem Comic nicht. Die findet man nur im Quellcode.

Wie gesagt, Design/Architektur meint in der Software-Welt das Gleiche. (Würde ich sagen. Zumindest sehe ich da keinen Unterschied.)

mfg

Christian

Matthias Hlawatsch hat gesagt…

Für mich ist Software-Design:

- ein Zustand, ein Ergebnis: eine über das Zufällige hinausgehende Qualität einer Software hinsichtlich nicht-funktionaler Eigenschaften.
Die Software erfüllt ihren (Daseins-)Zweck nicht nur irgendwie, sondern auch mit geringem Speicherbedarf, in einer leicht verständlichen Weise, gut testbar; sie hat ein in vielen Szenarien verwendbares API, bürdet mir beim Einsatz keine unnötigen oder problematischen Abhängigkeiten auf, ist flexibel anpass- und erweiterbar und überlebt 10 Technologie-Generationen; sie ist "schön" in dem Sinne, dass sie einem klaren Gedanken in seiner Essenz Gestalt gibt (Mike Bilds Formulierung "mentales Konzept des Autors" gefällt mir auch gut).
So wie ein schönes Messer nicht nur gut schneidet, sondern auch angenehm in der Hand liegt, ein Legostein nahezu beliebig mit anderen kombinierbar und außerdem beinah unkaputtbar ist oder ein Thonet-Stuhl Ästhetik mit geringstem Fertigungsaufwand verbindet.
- die Formulierung eines Ziels: ein Ausbalancieren der nichtfunktionalen Eigenschaften möglichst passend zu den (möglicherweise dazu zu erfragenden und zu hinterfragenden) Anforderungen. Langlebigkeit ist für eine Wegwerfwindel keine sinnvolle Eigenschaft, die Möglichkeit zur umweltfreundlichen Entsorgung hingegen sehr.
- und schließlich der schöpferische Vorgang, mit dem das Ziel erreicht oder zumindest angestrebt wird.

Mir ist klar, dass diese Definition das Problem zu einem Teil nur verschiebt, nämlich auf die Frage nach anzustrebenden nichtfunktionalen Eigenschaften einer Software. Aber ich glaube, dass sich über Testbarkeit, Wiederverwendbarkeit, Skalierbarkeit, Eleganz usw. und die Wege, diese Eigenschaften zu erzielen und gegeneinander abzuwägen, viel konkreter reden läßt als über Software-Design. Und meiner Ansicht nach ist Software-Design eben gerade die Beschäftigung mit solchen Eigenschaften.

Software-Architektur ist für mich zum einen Software-Design "im Großen". Von Design würde ich eher in Bezug auf Klassen, Module, Schichten (layers) bis hoch zu einer einzelnen Anwendung (= ein Prozess) reden, von Architektur angefangen von der Grobstruktur einer einzelnen Anwendung (insofern gibt es eine Überlappung mit Design) bis hinauf zu Anwendungsystemen und ganzen Anwendungslandschaften. "Architektur" betont m.E. das Statische, die Struktur. Ich sehe wie Mike Bild hier auch die Themen wie Einsatz von Technologien und Produkten und die Definition der Laufzeitumgebung mit enthalten. Letztlich geht es aber auch bei der Software-Architektur um das Erzielen nichtfunktionaler Eigenschaften, nur auf einer grob-granulareren Ebene.

Damit zu Deinen Fragen:

1. Ja, die Begriffe sind nützlich, denn sie lenken die Aufmerksamkeit darauf, dass von einer Software mehr verlangt werden sollte, als nur irgendwie zu funktionieren.

2. Sie sind der Gegenentwurf zum blinden Drauflos-Hacken. Sie betrachten nicht den Enstehungsprozess der Software. Sie haben zwar große Überschneidungen und Wechselwirkungen mit der Implementierung, aber zur Implementierung gehören auch funktionale Fragen (Muss die Sortierung stabil sein? Welche Aktionen sind als Transaktion auszuführen?), mit denen sich Design und Architektur nicht befassen.

3. Welches UI-Pattern setze ich am Client ein? Wie modelliere ich die Fach-Domäne in Entitäten, Services usw.? Wie kann ich die geforderte Funktionalität so implementieren, dass sie sich automatisiert testen läßt?

4. Setze ich einen O/R-Mapper ein, und wenn ja welchen? WPF oder WinForms? Wieviele Schichten (tiers), mit welchen Zuständigkeiten? SOAP oder JSON?

5. Fragen zum Entwicklungsprozess, zur Anforderungsanalyse, und eben Fragen zur eigentlichen Fachlichkeit der Software (welcher Wertebereich ist für das Geburtsdatum des Kunden zulässig?)

(Fortsetzung folgt)

Matthias Hlawatsch hat gesagt…

(hier der Schluss - wenn einem erst nach Fertigstellung des Textes angezeigt wird, dass es eine Längenbeschränkung gibt, ist das schlicht nervig...)

Abschließend: Design wie Architektur sind Begriffe, die aus der Welt der Gegenstände kommen. Im Gegensatz zu PMM sehe ich aber auch gerade die damit implizierte Analogie als hilfreich an. In Abwandlung eines Spruchs, den ich gerade heute erst irgendwo beim Surfen gelesen habe: alle Vergleiche hinken, aber manche sind nützlich.

Matthias

P.S. Danke, dass Du das Thema aufgeworfen hast. Du verrätst uns aber schon auch noch Deine Antworten auf die gestellten Fragen, oder?

ToniG hat gesagt…

Für mich beschreibt "Design" den "Vorgang des Entwerfens", abgeleitet vom Verb "to design".

"Architektur" "beschreibt ein Ergebnis", egal ob Gebäude, HW oder SW. Keiner kann "architektieren".

Damit sind SW-Design und SW-Architektur klar unterscheidbar.

Allerdings wird "Design" auch zur "Beschreibung eines Zustands nach einem (gelungenen) Entwurfsvorgang" verwendet, der die funktionalen und die nichtfunktionalen Anforderungen in einer (ansprechenden) "Architektur" zusammengefasst hat. Damit sind in dieser Form die Begriffe austauschbar.

Es wird schwierig bleiben.

Toni

Unknown hat gesagt…

Mir ist gerade noch etwas klar geworden (inspiriert durch die Kommentare und der originalen Diskussion bei den Craftmanships).

Software-Design kann man deshalb nicht scharf definieren, weil es schlicht ein Oberbegriff ist.
Ich denke, unter dem Begriff "Design" versteht jeder erstmal das Selbe. Man weiß, dass es irgendwie mit dem Erscheinungsbild einer Sache zu tun hat. Und, was dies für eine Wirkung auf mich hat.

Autos können ein kantiges Design haben. Sie können aber auch ein rundes, weiches Design haben.
So unterschiedlich diese Designs sein können, können sie doch alle schön sein. Es liegt ganz im Auge des Betrachters.

Wie ist das bei der Software?
Ich kann mir verschiedene Aspekte herausgreifen, welche alle mit dem Design zu tun haben.

Beginnend beim äußeren Erscheinungsbild (dem GUI-Design) bis hin zur Code-Ebene (dem Code-Design) steckt man alles in die Design-Kiste.
Chip-Hersteller sprechen ja sogar vom Chip-Design. Also steckt selbst da eine gewisse Ästhetik drin.

Ein schönes Code-Design löst in mir z.B. einen mentalen Orgasmus aus. Wenn ich solchen Code sehe, denke ich einfach nur "Geil!". Ich bin mir sehr sicher, dass es euch allen genauso geht, sonst wärt ihr keine Software-Entwickler. ^_^
Letztlich geht es immer um Design.
CodeKatas und AppKatas sind doch letztlich für uns Entwickler Dinge, wo wir uns mental selbstbefriedigen. Wir würden das nicht tun, wenn es uns nicht gefallen würde. Im Gegenteil! Wir lösen immer wieder gerne die selben trivialen Probleme, weil wir uns dort voll und ganz dem Design hingeben können. Es geht nicht mehr ums Problem, sondern um die Schönheit der Lösung. Das befriedigt uns.

Die Arbeitswelt verlangt kein schönes Code-Design. Sie will fristgerecht eine Lösung haben. Da bleibt keine Zeit, um ein schönes Code-Design zu entwerfen.
Also befriedigen wir uns in der Freizeit mit trivialen Problemen, um mal wieder hübschen Code vor Augen zu haben. :-)

Das schönste Software-Design hat doch immer noch das "Hallo Welt!" Programm! :-D

mfg

Christian

Ralf Westphal - One Man Think Tank hat gesagt…

@Chinafan: "Ich denke, unter dem Begriff "Design" versteht jeder erstmal das Selbe. Man weiß, dass es irgendwie mit dem Erscheinungsbild einer Sache zu tun hat."

Da haben wir es leider wieder: die Annahme, dass viele dasselbe unter einem Begriff verstehen. Woher kommt die nur. Ron Jeffries glaubt auch daran.

Wenn schon Ehen daran scheitern, dass solche Annahmen grundfalsch sind (nähmlich, dass die Eheleute dasselbe unter "Ehe" verstehen und deshalb auch dasselbe wollen), dann müssen sie bei etwas, das mehr Leute involviert und auch noch viel präziser laufen muss, noch mehr daneben liegen. Und das ist auch meine Erfahrung in sämtlichen Teamstatuserhebungen. Missverständnisse ohne Ende, weil eben nichts außer dem Trivialen selbstverständlich und gleichverstanden ist.

Dass Design etwas mit Aussehen zu tun haben "muss"... das ist doch eine Vorstellung von Laien. "Das Auto hat ein tolles Design." Nett - aber streift doch nur die Bedeutungsvielfalt, s. http://de.wikipedia.org/wiki/Design. Das ist so ähnlich wie mit Wein "leckerer Alkohol" zu assoziieren. Stimmt auch irgendwie - nur reicht das nun wirklich nicht zur Charakterisierung und stimmt auch nicht für alle Menschen.

Und was ist "schönes Code-Design"? Subjektivität wohin das Auge schaut. Genau darum geht es mir aber: So kommen wir in der Branche nicht weiter.

Wenn irgendeiner aufsteht und sagt, "Meine Methode verbessert das XYZ-Design.", dann muss sonnenklar sein, was die Kriterien für XYZ-Designqualität sind. Und dazu muss man erstmal wissen, was XYZ-Design überhaupt ist.

Und wenn es immer um Design geht... dann ist der Begriff nahezu nutzlos. Es geht ja auch immer um Programmierung, oder? Und es geht immer ums Geld, oder? Darüber müssen wir dann irgendwie gar nicht reden.

Wir tun es aber. Wir sprechen manchmal von Design und manchmal eben nicht. Das passiert - aber warum, in welchen Fällen. Weil wir so daherreden?

Ein Maurer hat kein Problem damit, wenn man ihn als Handwerker und nicht als Architekt bezeichnet. Da gibt es bei aller Unschärfe des Begriffs "Bauarchitektur" eine klare Trennung. Jeder kann sofort sagen, "Das ist ein Bauarchikturthema und dieses nicht."

Bei der SWentwicklung aber darf man nicht mal diese Trennlinie ziehen? Immer alles schön holistisch im Blick behalten und ja nicht "Sphären" trennen und Terminologie präzisieren, Begriffe scheiden?

Tut mir leid, das halte ich für mittelalterliche Denke, die uns nicht weiter als bis zu mittelalterlichen Erfolgen führen wird. Die sind in der Baukunst gewiss großartig - aber am Ende hat es zu einem Burj Dubai nicht gereicht. Der ist das Ergebnis von Wissenschaft und Ingenieurskunst, wobei alle Beteiligten genau wissen, was zu ihrem Gebiet gehört und was nicht.

Schon der Gedanke daran, an Präzisierung, Unterscheidung soll nun aber für Software ein no-go sein, nur weil sich unsere Anforderungen jeden Tag ändern? Ne, sorry, da komm ich nicht mit. Für mich darf es gern etwas mehr Systematik und Methode und Reflexion sein. (Was ja nicht heißt, dass am Ende Erfahrungswissen überflüssig würde. Im Gegenteil.)

Unknown hat gesagt…

@Ralf:
Bei der SWentwicklung aber darf man nicht mal diese Trennlinie ziehen? Immer alles schön holistisch im Blick behalten und ja nicht "Sphären" trennen und Terminologie präzisieren, Begriffe scheiden?

Weil man das in der SW-Entwicklung kaum trennen kann.

Verglichen mit dem Hausbau ist der Softwareentwickler der Architekt, der das Haus designt. Der "Maurer" ist der Compiler. Er baut eben das zusammen, was wir ihm vorgeben.
Wenn der "Maurer" nicht versteht, was wir von ihm wollen, macht er dies als Syntaxfehler kenntlich.
Alle anderen Fehler fallen auf uns, den Architekten, zurück. Der Maurer hat nur getan, was wir ihm aufgetragen haben.

Ich, persönlich, komme z.B. mit Begriffen wie "Code-Monkey" nicht klar. Also Leute, die ohne zu denken Code eintippen. Daher kann ich nicht unterscheiden, zwischen stupiden Programmierer und Software-Architekt. Ersteren gibt es IMHO gar nicht.

Ein einzelner SW-Entwickler wird sicher keine Software erstellen können, die verhältnismäßig Ausmaße wie das "Burj Al Arab" besitzt. (Das liegt aber nicht daran, dass er allein zu dumm oder unfähig dafür wäre, sondern weil er nur eine begrenzte Lebenszeit hat. Theoretisch könnte er es, aber praktisch ist es utopisch.)
Aber ein SW-Entwickler-Team, wo jeder ein Teil des Ganzen designt, kann sowas leisten.

Ich glaube, du suchst in der ganzen Thematik ein Problem, wo es gar keins gibt. :-)
Das ist mir auch in der Diskussion bei den SW-Craftmanships aufgefallen.

Keiner stört sich daran, dass man SW-Design/SW-Architektur/Implementationsdestails nicht trennen bzw. genau spezifizieren kann.

IMHO gibt es doch auch schon Kriterien, mit welchen man ein schönes Code-Design bekommt: Clean-Code.

Ist das denn nicht spezifisch genug? :-)

Wie gesagt:
Du kannst die SW-Entwicklung nicht mit dem Hausbau oder generell mit dem Handwerk vergleichen. Das hat man damals schon versucht, als man groß mit UML und "erst fertig planen und designen, dann coden" angekommen ist.
Aber ich dachte, soweit sind wir uns bereits einig.

Also um was geht es dir nun konkret? Um das strikte Ziehen von Grenzen? Oder darum, wie man SW-Projekte in der Größenordnung eines "Burj Al Arab" stemmen kann?

mfg

Christian

Ralf Westphal - One Man Think Tank hat gesagt…

@ChinaFan: Eine Branche, die soviel Wert auf Trennung legt - lose Kopplung, SoC, SRP, SLA, LoD, Kapselung, information hiding etc. -, die redet sich also ein, dass man nun gerade ihr Tun nicht trennen kann?

Das scheint mir mindestens widersinnig und naiv; es hört sich nach Rationalisierung an.

Auch die ewige Betonung, "software is design" (gemeint ist Quellcode), führt aus meiner Sicht zu nichts. Dass wir kein Vervielfältigungsproblem haben, ist mir auch klar. Aber was bringt diese Erkenntnis?

Das, was so einfach vervielfältigt werden kann, muss immer noch produziert werden. Wenn Compiler und Internet-Download es trivial machen, Software auf jeden Rechner zu kriegen, dann ist das erleichternd.

Darauf sollten wir uns aber nicht ausruhen. Die Softwareproduktion ist damit nicht vom Engpass befreit, sondern der verschiebt sich nur.

Umso mehr sollten wir uns überlegen, wie wir das, was so leicht vervielfältigt werden kann, sauber herstellen. Denn hergestellt muss es werden. Dass diese Herstellung kreativer ist als die Herstellung eines Hauses aus Steinen, macht die Sache eben nicht einfacher, sondern schwieriger. Und weil es schwieriger ist, liegt es nahe, es noch differenzierter zu betrachten.

Wer da einen gegenteiligen Reflex zeigt und behauptet, weil Sourcecodeproduktion so kreativ ist und sovielen Änderungen unterliegt, sehe man sie besser als einen Klumpen an... nein, den verstehe ich nicht.

Im historischen Zusammenhang kann ich vielleicht nachempfinden, wie man auf diese Vorstellung kommt. Ok. Deshalb muss die Schlussfolgerung aber nicht richtig sein.

Aus großer Entfernung gesehen wird alles von einem "Team" hergestellt, auch der Burj Al Arab. Diese Sichtweise ist aber trivial; sie bringt einfach nichts. Wäre das Bauprojekt so angegangen worden ("Wir sind alle ein großes Team und alle machen prinzipiell dasselbe und alle müssen immer auf alles achten."), dann stünde da heute nicht das höchste Gebäude der Welt.

Das war schon bei den Pyramiden und Kathedralen nicht so, auch wenn dort das Handwerk das Sagen hatte.

Wer sich also aufs Handwerk beruft und behauptet, deshalb müssten alle immer alles tun und an alles denken, der hat das Handwerk nicht begriffen. Handwerk ist per definitionem arbeitsteilig. Die Zünfte sind Ausdruck von Arbeitsteilung, von Trennung.

Dass ich ein Problem suche, dass es nicht gibt, glaub ich nicht. Vielleicht suche ich nach einer Lösung an der falschen Stelle. Das mag sein. Aber dass es ein Problem gibt, ist unzweifelhaft. Das beweise ich dir auch mit deinem (!) Team innerhalb von zwei Stunden; da bin ich mir sehr sicher. Lade mich einfach zu einer Teamstatuserhebung ein.

Natürlich gibt es Unterschiede zw. Hausbau und "Softwarebau". Das ist insofern keine triviale Erkenntnis, als dass wir 40 Jahre gebraucht haben, um zu erkennen, wo die liegen: in der Volatilität. Alles ist ständig im Fluss: Technologien, Teams, vor allem aber Anforderungen.

Bei soviel Volatilität kann man natürlich nicht alles so machen wie Hausbauer oder Flugzeugbauer.

Die Frage ist nur: Was kann man nicht so machen - und was sollte man trotzdem so machen?

Und ich behaupte erstmal nur eines: Ein Trend zur Entdifferenzierung der Branche, ist die falsche Reaktion.

Matthias Hlawatsch hat gesagt…

@Ralf Ich wollte gerade eben eine längere Antwort zu Christians Kommentaren posten. Die Webseite hat mich nach dem Klick auf "Vorschau" zur Anmeldung umgeleitet, danach kam:

Wir konnten Ihre Anforderung leider nicht bearbeiten.
Folgende Fehler wurden gefunden:
Input error: Cookie value is null for FormRestoration

Der Text ist nun weg (meist kopiere ich vorher, diesmal hab ich das leider vergessen). Ich hab keine Lust, ihn nochmal zu tippen. Und ich hab ehrlich gesagt auch keine Lust, diese Plattform hier weiter zu verwenden. Es sei denn, es gibt mal einen Thread zu schlechter Usability von Webanwendungen vs. der Hype von "in der Zukunft gibt es nur noch Webanwendungen".

Frustierte Grüße und trotzdem ein schönes Wochenende!
Matthias

Ralf Westphal - One Man Think Tank hat gesagt…

@Matthias: Tut mir leid, dass dich blogger.com frustriert hat. Dabei hätte ein "Zurück" mit erneutem Posting-Versuch dir Erfolg beschert. Mir ist nämlich dasselbe bei meinem Kommentar passiert. (Davon abgesehen nehme ich alle Kommentare zu Blogpostings immer vor Abschicken ins Clipboard. Bei allen Blog-Engines.)

Vielleicht siehst du es ja auch als Chance, deinen Standpunkt jetzt noch knackiger zu formulieren ;-)

Unknown hat gesagt…

@Matthias: Ich fände es schön, wenn du eventuell dennoch versuchst, die Antwort erneut zu posten. (Du kannst es ja diesmal vorher in Wordpad oder so eintippen.)

@Ralf:
Nun, eine Teamstatuserhebung wäre bei mir sinnlos. (Wenn du da z.B. nur die SW-Entwickler-Ecke betrachtest. Da gibt es im Grunde nur mich. Der andere SW-Entwickler bearbeitet andere Projekte. Ich bekomme auch nur von meinem Vorgesetzten gesagt, was für eine Software benötigt wird.) :-)

Du suchst also im Grunde nach einer besseren Aufgaben-Teilung in der SW-Entwicklung, richtig?
In der Spieleentwicklung gibt es ja schon seit jeher diese Aufgaben-Trennung, weil man hier auch gut trennen kann.
Da gibt es die Engine-Programmierer, Grafikdesigner, Sounddesigner, Leveldesigner, Sprecher, Storyboarder (nennt man den so?! *g*) und sicher noch mehr Beteiligte, die spezielle Aufgaben haben.
Am Ende steht da auch ein komplexes Stück Software, wo insgesammt zig Mannjahre an Entwicklung reingeflossen sind.

Suchst du nun ähnliche abgesteckte Gebiete in der normalen SW-Entwicklung?
Da kenne ich z.B. das klassische Schema: Programmierer für die Business-Logik und die (G)UI-Designer.

Wenn ich mir z.B. den Open-Source-Bereich ansehe, wird weniger nach freiwilligen Programmierern gesucht, als vielmehr nach Leuten, welche die Webseite schön und aktuell halten; welche die Dokumentation auf einen aktuellen Stand bringen; welche zur Übersetzung in andere Sprachen beitragen; welche das GUI userfreundlicher machen.

Wie ich es verstanden habe, suchst du nun nach einer Möglichkeit, wie der reine SW-Entwickler-Aspekt aufgeteilt werden kann?!

Da frage ich mal: Wie würdest du ihn denn gerne aufteilen wollen?
Für mich ist das ja im Grunde schon eine atomare Größe.
Es ist dann nur noch im Team eine formale Sache, wie man die Aufgaben verteilt.
Kennt sich ein SW-Entwickler gut mit Mathe aus, schreibt er den mathematisch intensiven Teil der Software. (etwa bei der Spiele-Engine)
Andere programmieren die Speicherverwaltung, usw.

Das sind so meine Vorstellungen der Trennung von Aufgaben innerhalb der SW-Entwickler.

mfg

Christian

Ralf Westphal - One Man Think Tank hat gesagt…

@ChinaFan: Es geht mir nicht per se um Aufteilung. Es geht mir um Differenzierung. Das ist was anderes. Erstmal eine differenzierte und präzise Sicht/Sprache "ohne Zorn und Eifer". Wenn man die hat, dann kann man alles machen, was geeignet ist.

Und in dem einen Projekt mit 3 Leuten mag geeignet sein, dass alle immer alles machen. Bingo. In dem anderen Projekt mit 5 Leuten ist aber vielleicht einer fürs GUI zuständig und einer fürs Deployment. Die sind die Team-Gurus dafür, alle anderen können das dann nur rudimentär. Vielleicht.

Die Software Craftsmen sind mir zu eifernd. Agil und besonders XP ist da eine Ideologie. Sie sind an einem Punkt angekommen, wo sie keine Fragen mehr stellen (über bestimmte Dinge). Das mag ja ok sein, wenn man denn die Antworten schon weiß und auch kommunizieren kann.

Nur das klappt aus meiner Sicht eben nicht. Sie haben Antworten, beglückwünschen sich gegenseitig dazu, sind aber quasi auf dem Niveau des typischen Supporters: "it works for my project".

Das ist auch nett, wenn es für sie funktioniert. Nur braucht unsere Branche mehr, wenn es breit besser werden soll. Dann muss anschlussfähig und mit Argumenten kommuniziert werden und nicht nur wie im japanischen Bushi-Do Gleichnis durch Vorleben des Meisters.

Wie schonmal gesagt: Ich mag die falschen Fragen stellen - aber dann muss man mir sagen, warum das die falschen Fragen sind. Man muss mit Argumenten darauf eingehen und nicht mit "Mach es nur einfach so wie wir." Ich habe argumentative Einwände gebracht - aber keine argumentativen Widerlegungen gehört.

"Dies oder jenes tut man einfach nicht in der Softwareentwicklung" ist mit zuwenig. Ja, auch von den inzwischen alteingesessenen Agilisten. Jeder steht in Gefahr, zum Establishment zu werden. Und das macht träge. Ron Jeffries scheint mir dort angekommen. Auch Martin Fowler ein Stück. Kent Beck finde ich da noch viel lebendiger. Dies ist ein rundum frischer Vortrag von ihm, wie ich finde: http://www.youtube.com/watch?v=KIkUWG5ACFY Da ringt einer um Verständlichkeit.

Bottom line: Technologisch passiert immer ne Menge. Auch schön.

Konzeptionell sind wir derzeit aber wieder in einer Krise. Agilität hat vor 10 Jahren ne Menge aufgerüttelt. Gut so. Scrum muss sich jetzt auf Konsolidierung konzentrieren. Kanban bringt eine frische Brise ins Vorgehen. Letztlich sind das aber alles "nur" Anpassungsreaktionen auf die Erkenntnis, dass unser Prozess anders aussehen muss als beim Hausbau.

Was ist aber mit dem Produkt? SOLID und ein bisschen DI Container machen schon gleich "Agile Architecture" aus? So einfach ist das? Ne, ne, ne. Bei der Strukturierung von Software hinken wir noch hinterher. Und deshalb müssen wir über Begriffe sprechen, die mit Strukturen zu tun haben. Das sind Architektur und Design - was immer die bedeuten mögen ;-)

Unknown hat gesagt…

@Ralf:
Jetzt verstehe ich deinen "Hilferuf" und kann ihn sogar nachempfinden!

Es ist in etwa so:
Man fragt 10 SW-Gurus, wie sie ein gegebenes Problem lösen würden und man bekommt 20 verschiedene Lösungsvorschläge, weil es kein Regelwerk gibt, womit man rational zu einer Kernlösung kommt.

Jeder programmiert eben, wie es ihm gefällt.
Mal macht man ein bisschen OOP, dann reicht auch mal wieder rein prozedural. Dort nimmt man funktionale Konstrukte, usw.

Am Ende hat man einen Klumpen Software, der irgendwie alles beinhaltet, weil doch alles irgendwie in der Software drin sein muss.

Aber frage bitte nicht danach, warum man sich für den Misch-Masch entschieden hat.

Am Ende ist es eher eine "Hype-Orientierte-Programmierung", kurz HOP.

Es begegnen einem auch immer Extreme im Internet. "Vermeide um jeden Preis dieses ...!"; "Anti-Pattern so und so"; "Dies und jenes ist Evil!"; ...

Ich will mich da nicht rausreden. Ich selber bin von Hype zu Hype gesprungen, weil Martin Fowler gesagt hat ...; weil Michael Feathers gesagt hat ...

Also versuchte man um jeden Preis deren Ideen in seine Software zu pressen. Aber ohne wirklich rationale Gründe dafür zu haben.

Es hat mich auch schon immer gestört, wenn eine Programmiersprache zu viele Features hatte. Es war nicht, wegen der vielen Features selber, sondern weil es kein Regelwerk gab, welches rational sagen konnte, wann man welches Feature einzusetzen hat.
Es wurde immer nur gesagt: "Kommt drauf an." oder "Das muss man selber wissen ... es kommt auf's Problem an."

Der Softwareentwicklung fehlen Regelwerke ... ähnlich wie Kochbücher beim Kochen oder Formelsammlungen in der Mathematik und Physik.

E=mc^2 ist ja auch nicht aus einer Laune heraus entstanden, sondern man kann die Formel bis auf's Kleinste rational begründen.

Sowas braucht die Softwareentwicklung auch.

Matthias Hlawatsch hat gesagt…

Nun denn, ich versuch es nochmal. Die Diskussion hat mich das ganze Wochenende über nicht ganz losgelassen. Schade nur, dass sich nicht mehr daran beteiligen...

@ChinaFan: "Die Arbeitswelt verlangt kein schönes Code-Design. Sie will fristgerecht eine Lösung haben. Da bleibt keine Zeit, um ein schönes Code-Design zu entwerfen.
Also befriedigen wir uns in der Freizeit mit trivialen Problemen, um mal wieder hübschen Code vor Augen zu haben. :-)"

Solch blanker Zynismus entsetzt mich. Aber es freut mich, dass Deine folgenden Kommentare nicht von dieser Haltung geprägt waren.

@Ralf, oder eigentlich alle:
Ich denke inzwischen, dass Gegenstand des Software-Designs die Struktur einer Software ist: aus welchen Funktionseinheiten besteht sie, welche Schnittstelle hat sie nach außen, welche Schnittstellen haben und welche Unterstruktur haben die Funktionseinheiten, wie interagieren diese miteinander? Ja, das ist sehr allgemein formuliert, aber schon damit ist Implementierung nicht mehr gleich Design - ich kann es abgrenzen von algorithmischen Überlegungen ("sortiere ich hier mit bubble sort oder quick sort?"), Implementieren fachlicher Funktionen ("neuer saldo = alter saldo minus abzuhebender Betrag, aber nicht kleiner 0, sonst Fehler") und Bedienen der Schnittstellen fremder APIs ("so, und jetzt den XmlSerializer aufrufen - was ist nochmal ein AttributeOverride?"). Und damit zerfällt die "holistische Sichtweise", von der Du ja weg willst, in einzelne Teile.

Designen kann ich somit auch ohne zu implementieren, aber in der Praxis wird ein "reines" Design niemals alle Design-Entscheidungen vorwegnehmen können, und damit ist Implementieren immer AUCH Designen. Das finde ich aber richtig. Es kommt nicht von ungefähr, dass die Design Patterns von Gamma & Co. Pflichtlektüre für angehende Entwickler sind. Möglicherweise liegt in diesem "nicht implementieren können, ohne zu designen" auch ein Grund, warum sich die Software Craftsmen u.a. so schwer damit tun, die Begriffe zu trennen (ein anderer mag die Überzeugung sein, dass Design auf dem Papier ohne Feedback aus der Übertragung in Code nicht gut funktioniert). Warum es trotzdem gut ist zu differenzieren, dafür hast Du selbst schon gute Argumente geliefert, da kann ich nur noch zustimmen.

Können wir noch konkreter werden? Ich denke nein. Dafür gibt es zu viele Möglichkeiten, einer Software eine innere Struktur, ein Design zu geben. Object Oriented Design beschäftigt sich ganz allgemein damit, wie eine zu implementierende Gesamtfunktionalität auf Objekte verteilt werden kann, was dabei erfolgreiche Wege sind und was die Sackgassen. Jeder, der in einer OO-Sprache programmiert, betreibt damit auch unweigerlich OOD, bewußt oder eben unbewußt (dann aber meist schlecht). Domain Driven Design spezialisiert und verfeinert diese Disziplin auf die Modellierung einer Fachdomäne. Flow Design stellt die Daten und den Fluss ihrer Veränderungen in den Mittelpunkt der Überlegungen und setzt bewusst auf reduzierte, "uniforme" Schnittstellen, so dass (so jedenfalls mein Eindruck) selbst bei Implementierung mit einer OO-Sprache der OO-Charakter der Lösung in den Hintergrund rückt. Manche Design-Ansätze sind auf einen bestimmten Bereich spezialisiert wie die Familie der MVC-Muster. Außerdem läßt sich Software-Design auf allen Granularitätsebenen betreiben - ich kann eine Klasse designen (in manchen Sprachen, Object Pascal z.B., kann lassen sich sogar Methoden nochmal in Sub-Methoden zerlegen), einen Namespace, eine Assembly, eine Anwendung... Der größte gemeinsame Teiler, den ich dabei finde, ist, dass es immer darum geht, Strukturen zu bilden, bestimmte Teile der Gesamtlösung mit anderen zusammenzufassen, von anderen abzugrenzen und die so geformten Teile zueinander in Beziehung zu setzen.

...

Matthias Hlawatsch hat gesagt…

...

Ist der Begriff damit wertlos, weil zu unspezifisch? Ich finde nicht. Das in diesem Sinne verstandene Design einer Software hat bestimmenden Einfluß auf einige ihrer wichtigen Eigenschaften. Wenn ich frage, ob ein Software-Design von guter Qualität ist, dann frage ich letztlich, ob und wie das Design - also die Struktur - die Testbarkeit, Verständlichkeit, Evolvierbarkeit, Wiederverwendbarkeit, Benutzbarkeit (hier denke ich weniger an das UI als an solche Katastrophen wie java.util.Date), oft auch die Performance der Software befördert. Oder welchen Einfluss sie auf den Herstellungsprozess hat (weil sie zum Beispiel paralleles Arbeiten ermöglicht oder komplizierte und know-how-intensive Bereiche einkapselt und damit verhindert, dass sie die Erstellung anderer Teile der Software behindern). Bezogen auf die konkrete Lösung und das konkrete Kriterium läßt sich das sehr gut diskutieren. Klar sollte auch sein, dass zu einer Bewertung einer Design-Qualität dann auch eine Gewichtung der Kriterien gehört.

Software-Strukturen sind geprägt von einer großen Selbstähnlichkeit: ein Haus ist kein Ziegelstein, ich kann auch nicht ohne weiteres zwei Häuser zu einem Super-Haus zusammensetzen, aber eine große Anwendung und eine einzelne Methode sind letztlich beides Einheiten, die Eingabedaten in Ausgabedaten verwandeln - Du führst uns ja mit den EBC gerade vor, wie sich Bausteine zu Platinen zusammensetzen lassen, und diese wieder, usw. Diese Selbstähnlichkeit und die Losgelöstheit von physischen Grenzen sind meiner Meinung nach der Grund, warum wir in der Software-Entwicklung nicht eine ähnlich starke Differenzierung erreichen können wie am Bau zwischen Maurer und Architekt. Trotzdem kann es Spezialisten für das UI geben und für die Datenbank und auch für das Strukturieren, Modellieren, eben Designen. Und selbst dort, wo Generalisten ein Team bilden oder das Team nur eine Person groß ist, ist es immer noch gut und hilfreich, sich darüber klar zu sein, dass es unterschiedliche Aspekte der Aufgabe gibt, dass einer davon das Finden eines guten Designs ist, und dass diese verschiedenen Aspekte bestimmte Eigenschaften des Ergebnisses beeinflussen. Welche das im Falle des Software-Designs sind, habe ich (nicht unbedingt vollständig) im vorigen Absatz versucht zu benennen. Es sind nicht-funktionale Eigenschaften, weshalb ich in meinem ersten Kommentar auch versucht habe, den Begriff aus dieser Richtung zu erklären. Und schließlich, egal ob Team oder Einzelkämpfer: es ist auch gut und wichtig, den einzelnen Aspekten der Aufgabe, und damit auch dem Design, einzeln und explizit Aufmerksamkeit zu widmen. Separation of Concerns hilft dem Hirn auch beim Denken.

Irgendwie werde ich das Gefühl nicht los, dass ich Dir, Ralf, damit eigentlich nichts neues erzählen kann. Suchst Du nach einer Bestätigung von außen? Siehst Du den Begriff Software-Design anders? Enger? Weiter? Hast Du ein Unbehagen mit Deiner eigenen bisherigen Auffassung? Ich kann gut verstehen, dass die Weigerung der Software Craftsmen, den Begriff genauer zu definieren und abzugrenzen, Deinen Widerspruch hervorruft (übrigens: ist es wirklich verwunderlich, wenn craftsmen - Handwerker - Zunftdenken entwickeln und sich einer Differenzierung von Tätigkeiten widersetzen?). Aber warum forderst Du nur, den Begriff zu definieren, aber stellst nicht selbst eine Hypothese auf und zur Diskussion? Ich kann mir nicht vorstellen, dass Du keine Meinung dazu hast, was Software-Design ist und was nicht.

...

Matthias Hlawatsch hat gesagt…

...

Was ich jetzt bewußt außen vor gelassen habe, ist Software-Architektur. Darüber brüte ich noch. Auch da geht es um Strukturen, also Software-Design, soweit bin ich mir sicher. Aber nur auf den "oberen" Stufen der Granularität, was auch immer das genau heißen mag. Man spricht von Drei-Schichten-Architektur, aber "Beobachter" wird nicht als Architekturmuster bezeichnet. Aber ob es gut ist, Software-Architektur einfach als eine Spezialisierung von Software-Design zu sehen oder ob Sachen wie Technologie- und Produktentscheidungen besser mit hineinzunehmen sind, da bin ich mir noch nicht sicher. Wahrscheinlich schon. Aber aus dem Begriff Software-Design mag ich sie heraushalten. Ob ich SortedList oder SortedDictionary verwende, ist für mich ein Implementierungsdetail. WPF vs. Windows Forms eine Architekturentscheidung. Beides aber keine Design-Entscheidung. Mit dieser Abgrenzung fühle ich mich wohl, weil dann klar bleibt, dass es bei Software-Design um das Bilden von Strukturen geht. Und das Thema ist schon groß genug.

Ralf Westphal - One Man Think Tank hat gesagt…

@Matthias: Danke, dass du dir nochmal die Mühe gemacht hast, deine Gedanken aufzuschreiben. Ich finde sie sehr konstruktiv.

Besonders hat mich angesprungen deine Vermutung, dass Softwareentwicklung so wenig differenziert ist aufgrund der Selbstähnlichkeit von Software.

Da ist wohl etwas dran: In der physischen Welt verlaufen die Grenzen der Arbeitsteilung oft und ganz natürlich entlang von Materialgrenzen. Um mit Steinen richtig umgehen zu lernen, braucht man lange Lehrjahre; dasselbe gilt für Holz, Leder, Tierkörper usw.

Die berufliche Trennung und damit die gewerkliche Trennung ist insofern primär eine Sache Lerneffizienz und nicht der Produktionseffizienz.

Bedeutet das im Umkehrschluss, dass der Flugzeugbau oder der Hausbau anders organisiert wäre, wenn diese Dinge aus nur einem Material hergestellt werden könnten?

Ja, ich denke, das wäre wohl so. Zumindest anfänglich. Und es war und ist immer wieder auch so, selbst wenn es um mehrere Materialien geht.

Wenn die Produkte keine höchste Qualität haben müssen/können und die Gemeinschaft zu ihrer Herstellung klein ist, dann gibt es keine berufliche Trennung, dann tun und können alle so ziemlich alles. Nicht, weil sie es wollen, nicht weil es am besten so ist, sondern weil es nicht anders geht.

In Europa kennen wir solche Gemeinschaften eher schon lange nicht mehr. Das sind nämlich Siedler und Nomaden oder allgemein kleine, mobile Gemeinschaften.

Die Software Craftsmen haben mithin die falsche Analogie gewählt. Sie hätten sich Software Nomads oder Software Settlers oder vielleicht noch passender Software Pilgrim Fathers nennen müssen :-) Denn was aus ihren Standpunkten spricht, ist weniger der europäische Handwerks(zunft)gedanke, als vielmehr die neu-weltliche Siedlermentalität.

"How the software crisis should be solved is how the west was won.", das scheint mir ganz fundamental das Gefühl der Software Craftsmen zu sein. Und wenn ich das so schreibe, dann finde ich das auch total verständlich. Das muss sich gerade für Amerikaner wie "coming home" anfühlen. (Von weiteren Spekulationen über die Gefühlsgemengelage will ich einmal absehen. Die Amerikaner als Angstnation sind schon beschrieben, http://www.amazon.de/Culture-Fear-Americans-Minorities-Microbes/dp/0465003362. Aber vielleicht gibt es auch noch andere amerikanische "Stimmungen", die sich Bahn brechen könnten in Form von "Ideologien"? Ist es vielleicht ein kultureller Unterschied, der in Deutschland zu einer CCD-Bewegung geführt hat und in den USA zu den Software Craftsmen (obwohl von dort Clean Code kommt)?)

Also: beruflich geringe Differenzierung ist zu finden, wo entweder keine nötig scheint (Homogenität im Material) oder - und das finde ich jetzt wichtig - wo es schlicht nicht anders möglich ist.

Bei der Software kommt nun eines zum anderen, glaube ich. Da ist zunächst die Selbstähnlichkeit, d.h. Homogenität des Materials vom GUI bis zum Betriebssystem. Alles ist aus dem selben Stoff: Maschinencode.

Und dieser Stoff ist auch noch trivial zu verarbeiten: Notepad auf, Quellcode eintippen, speichern, Compiler anwerfen, fertig.

Dazu kommt, dass die Gemeinschaften, die damit umgehen müssen, meist klein sind und unter ständigem Mangel leiden: Personalmangel, Zeitmangel, Geldmangel...

Lange waren sie auch ziemlich isoliert. Allenfalls fand eine recht einseitige Kommunikation über Fachblätter statt. Also ist eine Kultur der Selbsterhaltung, der Undifferenzierung entstanden. Aus purer Not.

...

Ralf Westphal - One Man Think Tank hat gesagt…

...

Das zu betonen ist mir wichtig: Softwareentwicklung in Trapper- und Siedler-Mentalität ist in Bezug auf das Produkt keine Tugend, sie hat sich nicht als das Beste herausgestellt, sondern ist aus der Not geboren. Sie ist ein Symptom des Mangels, insbesondere des Mangels an Reife (der Branche) im Verein mit lange mangelden Kommunikationsmöglichkeiten.

Unterm Strich bedeutet das für mich: Die Softwareentwicklung ist nicht auf der Höhe der Zeit. Sie lässt sich verwirren durch die Selbstähnlichkeit ihrer Produkte. Sie glaubt, weil alles aus dem selben Stoff ist, brauche man keine Differenzierung.

Das stimmt jedoch nur, wenn man Software aus großer Flughöhe betrachtet. Dann sieht alles gleich aus. Ist doch nur Maschinencode.

Aus großer Flughöhe betrachtet ist aber auch der menschliche Körper homogen: sind doch alles nur Zellen.

Dennoch hat sich im Verlauf von mehreren Tausend Jahren eine große und nützliche Differenzierung entwickelt im Gesundheitswesen (und geht noch weiter). Wer möchte für seine Allergie oder seinen Husten oder seinen Blinddarm oder seinen Zahnschmerz nicht zum Spezialisten gehen? Die Zeiten der Bader sind glücklicherweise vorbei.

Die Offenheit für dieselbe Entwicklung brauchen wir auch für die Softwareentwicklung. De facto passiert das auch. Nur sehr unbewusst und damit langsam.

Unser Material ist nämlich nicht einfach so Quellcode. Das halte ich für die letztlich falsche Parallele. Das wäre so, als würde man sagen, das Material von Maurer und Tischler ist auch dasselbe: Atome.

Nein, unsere Materialien sind (inzwischen) APIs. Die sind nämlich ganz verschieden.

SL ist ganz anders als WinForms. Das ist anders als ASP.NET. Und das ist anders als ADO.NET. Und das ist anders als EF. Und das ist anders als .NET Security. Und das ist anders als NServiceBus. Und das ist anders als WCF. Usw. usf.

Und nicht nur sind Materialien anders, auch "Gesetzmäßigkeiten" sind anders. Aus Holz eine Brücke zu bauen ist etwas anderes als aus Holz einen Schrank zu bauen. Trotz desselben Materials machen das nicht dieselben Leute.

Software, die async läuft, muss anders aussehen, als Software, die sync läuft. Lokal ist was anders als verteilt. Verteilt mit 200 Anwendern ist etwas anderes als verteilt mit 10.000.000 Anwendern. Usw. usf.

Die Softwarewelt ist nur oberflächlich homogen und selbstähnlich. Auf atomarer Ebene betrachtet, ist "die Welt" auf selbstähnlich: überall nur Atome.

Aber wir gehen mit ihr nicht auf Raster-Tunnel-Mikroskop-Ebene um. Wir manipulieren nicht einzelne Atome. Wir arbeiten mit größeren Ganzen, die unterschiedliche "Qualität" haben.

Dasselbe werden wir als nützlich und nötig ansehen, glaube ich, wenn wir weg kommen vom Statement-Fokus in der Softwareentwicklung. Dann treten die größeren Zusammenhänge in den Blick. Dann fällt uns eine natürliche Differenzierung auf, die sich entwickelt hat. (Ich behaupte ja nicht, dass es sie schon immer gab.)

Wir sind aus der Ursuppe raus. Die Entropie ist geringer geworden. Es haben sich Strukturen [sic!] gebildet.

Womit ich bei deinem anderen Begriff angekommen bin: Struktur. Und damit bei Design.

In einer Welt, die selbst schon strukturiert ist, die selbst Strukturen herstellt (die dann auch noch hohe Qualität haben müssen), in so einer Welt undifferenziert sein zu wollen, mit Gefühlen zu Begriffen leben zu wollen... das halte ich für komplett neben der Spur.

Wie gesagt: im historischen Kontext verständlich, womöglich sogar - wie hier angedeutet - auch im kulturellen Kontext verständlich. Deshalb aber nicht gut im Sinne systematisch hoher Produktqualität.

Soviel mal für jetzt. Ein andermal vielleicht dann noch zu meinen Vorstellungen zu den Begriffen Design und Architektur ;-)

Matthias Hlawatsch hat gesagt…

@Ralf Danke für die anregende Lektüre heute morgen. Gut gefallen hat mir der Bezug zum Materialbegriff und dabei vor allem der Gedanke, dass APIs das Material sind, mit dem Softwareentwickler arbeiten. Damit bekommt die Entscheidung für oder gegen eine bestimmte Technologie, ein Framework, eine API, und der gekonnte Einsatz desselben, dann womöglich doch einen Platz im Begriff des Software-Designs. Entgegen meinem Bestreben von gestern abend zwar, aber die Parallele zum Design im "herkömmlichen" Sinne finde ich überzeugend - dort spielt der Umgang mit dem Material ja eine große Rolle. Auf der anderen Seite sollten wir auch wachsam bleiben beim Analogisieren, damit wir es nicht übertreiben. Als Softwareentwickler benutzen wir nicht nur APIs, wir schaffen auch welche. Und oft genug schaffen wir APIs, um sie gleich selbst einzusetzen. Nur wenige Designer in anderen Disziplinen, schätze ich, schaffen sich selbst das Material, mit dem sie arbeiten. Und noch weniger designen es! Und selbst da, wo das doch mal der Fall ist (vielleicht bei einem Schneider, der sich seinen Stoff selbst webt und dafür wiederum Garn und Webtechnik auswählt oder sogar ersinnt), wird kaum so eine große Symmetrie der Komplexität herrschen zwischen dem ausgeklügelten, von einer wohl überlegten inneren Struktur geprägten Entwurf des Materials und dem nicht weniger überlegten Einsatz desselben zum Schaffen anderer Strukturen. Da wären sie mal wieder, die Konsequenzen der Selbstähnlichkeit. Von dieser Warte habe ich das Entwerfen von Frameworks noch nie gesehen, aber ich finde, es hat was.

Noch ein anderer Gedanke: mir scheint, der Design-Begriff tritt in der Geschichte erst in dem Moment auf, als die industrielle Herstellung komplexerer Gegenstände beginnt. Der Thonet-Stuhl steht im Design-Museum, und vieles, was danach kam - aber niemand würde auf die Idee kommen, beim Anblick einer Biedermeier-Kommode oder eines alten und reichverzierten Bauernschrankes das schöne Design zu loben. Erst in dem Moment, als die stark arbeitsteilige industrielle Fertigung ins Laufen kam, wurde es notwendig, das bewußte Gestalten der Produkte als eigene Disziplin abzugrenzen. Das war der Moment, als die Dinge nicht mehr von einzelnen oder wenigen Handwerkern - Menschen mit Namen und Gesicht - hergestellt wurden, sondern anonym, z.T. von Maschinen, in großer Stückzahl. Siehst Du da Parallelen zu unserer Diskussion? ;-)

Ralf Westphal - One Man Think Tank hat gesagt…

@Matthias: Dass Design nicht am Anfang steht, ist ein interessanter Gedanke.

Handwerk kannte noch kein Design; Industrieproduktion kennt Design. Beim Handwerker war alles in einer Hand, auch die Gestaltung in puncto Ästhetik und Usability. So wurde das Produkt als Ganzes wahrgenommen. Bei der Industrieproduktion sind Herstellung und Entwicklung getrennt. Deshalb kam es auch zu einer Separierung von Design. Das scheint mir ein natürliches Resultat der Arbeitsteilung.

Bei der Software geht es sicherlich nicht um Ästhetik, wenn wir von Design reden. (Oder nur am Rande, in bestimmten Kontexten.) Eher ist damit "irgendwas" in Bezug auf die Struktur von Software gemeint.

Warum wird das nun "plötzlich" interessant? (Interessant ist das in Wirklichkeit schon lange; aber die breite Entwicklergemeinde hat das nicht genauso wahrgenommen wir die akademische Welt.)

Es wird plötzlich interessant, weil unsere Systeme größer und langlebiger und "bunter" werden. (bunt=mehr Technologien kommen zum Einsatz)

"Plötzlich" merkt auch der letzte Entwickler, dass es mit "drauf los programmieren" irgendwie nicht mehr geht.

Nicht Arbeitsteilung ist also der Treiber für Designbewusstsein, sondern "Umfang" (Codemenge, Zeitmenge, Technologiemenge).

Ist jetzt nur noch die Frage, ob diesem Bewusstsein auch noch eine Form von Arbeitsteilung folgen sollte. (Damit meine ich aber nicht unbedingt verschiedene Personen, sondern durchaus dieselben Personen in unterschiedlichen Modi.)

Rainer hat gesagt…

Software Architektur beschäftigt sich mit der Lösung der Problemdomäne auf einem sehr abstrakten Niveau. Bausteine, Muster und andere bekannte Lösungsstrategien auf einem Höheren Niveau werden verwendet um Probleme in der Domöne konkret für die Lösungen vorzuschlagen.

z.B. Enterprise Service Bus, Separation of Concerns, Client/Server Architektur .... ja da ist der Begriff schon mit drinnen. Es ist also die Verknüpfung von bestehenden oder zu schaffenden Komponenten auf einem Hohen Niveau zu einer Gesamtlösung in der Problemdomäne. (abstrakt)

Das Design hingegen beschreibt die Konkretisierung des Architekturvorschlages, also die Detailierte Beschreibung dessen, was zu tun ist um die Architektur umzusetzen, die Relation in dem System und zwischen den Komponenten. Beispiel UML, etwas abstraktes, Verständnis schaffendes für die Gesamtheit.

Ein Modedesigner entwirft z.B. ein Kleid. Das Design ist die BESCHREIBUNG der konkreten Umsetzung der Techniken (Muster, Komponenten, Lösungswege). Ein Form Designer in der Software ist die Beschreibung wie die Oberfläche aussieht, also etwas explizites, etwas deklaratives.

Eine Architektur wird Designed. Aber ein Design kann nicht archit... ja wie auch immer das heißen sollte (gibt es nicht).

Das ist für mich die Erklärung! Und die Abgrenzung habe ich wohl auch gezeigt.

Schaut euch Zertifizierungsprozesse der ISO an. Da sprechen wir von Organisationen die Weltweit agieren und Jährlich Audits und Prüfungen machen. Da gibt es so etwas wie Design Development Plans. Da gibt es Begriffe wie System Desing Specification, welche die Umsetzung des Architekturschaubilds genau Beschreiben.

Also: Architektur = Hohe Kunst. Design ist die Konkretisierung der Hohen Kunst (Noch immer im Entwurfsmodus). Schlussendlich ist da die Implementierung ... ;)

In der Software wieder das Äquivalent. Mit dem Formdesigner gestalte ich die Oberfläche. Tragisch, das dieses Tool auch gleichzeit den Code erzeugt. Oder ist das nicht von RAD so gewollt? Naja, aber es ist nach wie vor die Entwursphase. Und konretisiert wird der Entwurf dann im Code, wenn er mit Leben gefüllt wird. Also, wenn er implementiert wird.

Habe ich hier irgendwo wiedersprüche?

Grüße und gute Nacht.

Rainbird hat gesagt…

Softwarearchitektur bzw. Software-Design sind schwammige Begriffe. Sie sind so weit gefasst, dass nicht genau abgegrenzt werden kann, was alles dazugehört und was nicht.

Ich würde auch sagen, dass Architektur nur in Verbindung mit Implementierung gesehen werden kann. Die verfügbaren artitektonischen Mittel (z.B. Entwurfsmuster) sind von den eingesetzten Plattformen, Sprachen und Frameworks abhängig. Ein klassisches MVC-Entwurfsmuster macht z.B. in einer Windows.Forms-Anwendung keinen Sinn, da die Steuerelemete selbständig auf Benutzereingaben reagieren, was laut MVC eigentlich ein Controler machen sollte.

Architekturentscheidungen ergeben sich durch Wahl der Sprachen, Frameworks und Bibliotheken automatisch. Entscheidet man sich z.B. für WCF als Kommunikationsframework, muss man explizite Dienst- und Datenkontrakte festlegen. Auch wenn das oft suboptimal ist, da jegliche Dynamik damit flöten geht.

Ein weiterer Faktor, der den "Architekten" weiter in seiner Handlungsfreiheit beschneidet sind "Mode-Trends" denen in der Branche immer mehr Bedeutung zugemessen wird. Man nimmt oft nicht mehr das Framework oder die Technologie, welches eigentlich am Besten zur Umsetzung der Anforderungen geeignet ist, sondern man verwendet, was gerade hip und cool ist. Aus meiner Sicht eine gefährliche Entwicklung.

Hat man seinen Technologie- und Framework-Mix zusammengestellt, muss man das "Fertig-Softwarehaus" eigentlich nur noch montieren. Viel zu designen gibt es da meist nicht mehr. Natürlich kann man sich noch um Spitzfindigkeiten streiten, aber im Großen und Ganzen ist die Architektur damit implizit festgelegt.

Was sollte eine einheitliche Definition von Softwarearchitektur/Software-Design da bringen? Okay, ein schönes Kapitel fürs Lehrbuch. Ich persönlich hatte noch nie den Eindruck, dass ein anderer Entwickler, mit dem ich mich über Softwarearchitektur unterhalten habe, darunter etwas anderes verstanden hätte. Also scheint es tatsächlich so zu sein, dass alle vom Gleichen reden. Nicht jeder setzt die selben Prioritäten. Mancher lässt vielleicht bestimmte Aspekte ganz außen vor. Aber daran würde eine genau abgegrenzte Definition auch nichts ändern.

Kann es sein, dass wir bei dem Versuch Softwarearchitektur genau definieren zu wollen nach einem Kontrast suchen, den es in der Realität so gar nicht gibt?

Ralf Westphal - One Man Think Tank hat gesagt…

@Rainbird: Ich glaube an eine "Wahrheit der real existierenden Begriffe" ;-) D.h. wenn es einen Begriff gibt - allemal über längere Zeit -, dann gibt es den nicht umsonst. Der hat Zweck, der erfüllt ein Bedürfnis. Er bezeichnet dann, wie immer krude und unausgegoren das auch sein mag, etwas, das viele Menschen für bezeichnungswürdig halten.

Wenn wir also schon lange die Begriffe Architektur und Design in der Softwareentwicklung kennen, dann ist da etwas, das Bezeichnung verdient. Also sollten wir uns anstrengen, präzise zu sein.

Rainbird hat gesagt…

Die Definition von Helmut Balzert für den Begriff Softwaretechnik (engl. Software Engineering) passt auch für den Begriff Software-Entwurf (engl. Software-Design).

Zielorientierte Bereitstellung und systematische Verwendung von Prinzipien, Methoden und Werkzeugen für die arbeitsteilige, ingenieurmäßige Entwicklung und Anwendung von umfangreichen Softwaresystemen.

Für Software-Architektur hat er auch einen treffenden Merksatz fürs Lehrbuch:

eine strukturierte oder hierarchische Anordnung der Systemkomponenten sowie Beschreibung ihrer Beziehungen

Damit hätten die real existierenden Begriffe eine klare Definition. Die ist ja auch nicht neu, genau wie die Begriffe. Sie umschreibt aber damals, wie heute, was unter den zwei Begriffen zu verstehen ist.

Das ist Dir vermutlich nicht präzise genug. Präziser wird es allerdings kaum gehen. Man kann zu diesen zwei Merksätzen natürlich ganze Abhandlungen und Aufzählungen schreiben, welche Methoden, Prinzipien und Werkzeuge nun genau unter den jeweiligem Überbegriff zusammengefasst werden. So lässt sich TDD z.B. als Methode zur Qualitätssichung aufführen. Einem, der seine Anwendungen mit VBA unter Microsoft Access entwickelt, wird das aber nichts bringen, da es für Access keine Werkzeuge zur TDD-Entwicklung gibt. Wie genau Software tatsächlich entworfen wird, wird vom Allem durch die eingesetzten Technologieen und Bibliotheken (man könnte auch sachen: Werkzeuge) bestimmt.

Das ist bei Handwerkern in der realen Welt nicht anders. Die zu verfügung stehenden Werkzeuge und das Verständnis sie richtig zu gebrauchen, entscheiden darüber, wie beim Entwurf eines Bootes, Hauses, oder einen einfachen Holzstuhls vorgegangen wird. Habe ich nur ein Steinbeil, werde ich keinen Ozenriesen bauen können, aber wohl einen Einbaum. Die Fingerfertigkeit des Geigenbauers entscheidet darüber - vorrausgesetzt er hat das nötige Werkzeug - ob die Geige am Ende einen schönen Klang hat oder nicht. So ist es auch beim Software-Entwurf. Passende Werkzeuge auswählen allein reicht nicht. Man muss die Werkzeuge beherrschen. Wenn mehrere Handwerker oder auch Software-Entwickler an einem "Werkstück" arbeiten, kommt noch der Aspekt Teamwork hinzu. Ich bin versucht zu sagen: "Das gehört auch zum Software-Entwurf bzw. zur Softwaretechnik". Aber wenn z.B. jemand schon immer Software als Einzelkämpfer entwickelt hat, wird er das vielleicht nicht so sehen.

Es zeigt sich immer wieder, dass die Begriffe zu schwammig sind, um sie präziser zu definieren. Trotzdem haben sie als Überbegriffe klare Bedeutungen. Jeder weiss was insgesamt darunter zu verstehen ist. Trotzdem haben die Begriffe für jeden Einzelnen eine ganz bestimmte Bedeutung. Auch der Access-Entwickler wird zustimmen, dass TDD zum Überbegriff Software-Entwurf gehört, auch wenn es für ihn keine Rolle spielt und er es selber diese Methode noch nie angewendet hat. Es verstehen sich deshalb tatsächlich Alle, ohne dass man die Definition präziser machen muss.

Ralf Westphal - One Man Think Tank hat gesagt…

@Rainbird: Leider kann ich wirklich dem Balzert nicht soviel abgewinnen ;-)

Aber viel wichtiger finde ich deine Behauptung, die ich auch schon bei der Software Craftsmen gehört habe: "Trotzdem haben sie als Überbegriffe klare Bedeutungen. Jeder weiss was insgesamt darunter zu verstehen ist."

Mit Verlaub, das ist mindestens irreal, wie du feststellen wirst, wenn du mal auf einer Konferenz wie der BASTA! 10 Leute nach ihrer Definition von "Softwarearchitektur" befragst. Du wirst 6 Definitionen erhalten, die alle verschieden sind - und 4 Anworten gar nichts, weil sie keine Worte dafür haben. Probier es mal aus.

Wir lügen uns etwas in die Tasche, wenn wir glauben, es herrsche große Einmütigkeit in der Branche.

Wenn du 5 C#-Entwickler nimmst, die noch nie zusammengearbeitet haben und ihnen eine AppKata vorlegst, dann kommt nach 2 Std nichts (!) heraus. (Und das nicht nur, wenn die sich nicht kennen. Ich hab das oft genug als Teamstatuserhebung in existierenden Teams gemacht. Java, C#... die Plattform macht keinen Unterschied.)

(Es gibt nur eine Abweichung: Wenn bei den 5 einer sehr dominant ist und die anderen "einteilt", dann kann was herauskommen. Nicht viel, aber etwas.)

Nun geh mal in ein Krankenhaus und stecke 5 Leute für eine Operation zusammen, die noch nie zusammengearbeitet haben. Das flutscht. (Auch da kann man noch was verbessern, aber haben nach zwei Stunden einen hochprozentigen Erfolg.)

Davon sind wir meilenweit (!) entfernt. Eben weil es keine (unausgesprochene) Übereinstimmung in Begriffen und Vorgehen gibt.

Rainbird hat gesagt…

Es macht einen Unterschied, ob man sich nur über ein Thema austauscht, oder ob man zusammen ein Projekt stemmen muss.

Die Leute im Krankenhaus haben es auch etwas einfacher. Ein Tupfer ist immer ein Tupfer, eine Klammer immer einer Klammer und die Konchensäge ist auch unmissverständlich. Um bei medizinischen Details nichts zu verwirren, werden einheitliche lateinische Bezeichnungen verwendet.

In der Software-Welt haben wir einen solchen Komfort leider nicht. Für einen C#-Entwickler sind Events und Delegaten eine ganz natürliche Sache. Der Java-Kollege kann damit zunächst erstmal nichts anfangen. Wo wir wieder bei den Werkzeugen wären.

Ich bin mir sicher, dass Entwickler, welche die selbe Palette an Werkzeugen beherrschen genauso gut zusammenarbeiten können, wie im Krankenhaus. Dass die 5 Entwickler aus dem Beispiel alle C# programmieren reicht als Gemeinsamkeit nicht aus, um flüssig zusammenzuarbeiten.

Angenommen für ein Projekt ist die Architekturentscheidung - zunächst - auf folgende Werkzeuge gefallen:

- Plattform: .NET Framework 4.0 (C#)
- Datenbanksystem: SQL Server 2008
- GUI-Framework: Windows.Forms
- Daten-Framework: ADO.NET + Typisierte DataSets
- Kommunikations-Framework: .NET Remoting (TcpChannel)
- Transaktions-Framework: System.Transactions
- Quellcodeverwaltung: TFS

Damit es flutscht wie im Krankenhaus muss das Projektteam noch vereinbaren, wie diese Werkzeuge einzusetzen sind. Das könnte z.B. so aussehen:

- Datenbindung über Windows.Forms-Designer
- Laden über Merge
- Local Validate -> Save -> Remote Validate -> Merge
- ColumnErrors und RowErrors sowie ErrorProvider verwenden
- DataGridViews als bevorzugte Listen-Steuerelemente
- FamFamFam Iconen-Satz 16x16 Pixel für Menüs, Toolbars, Listen
- Statusloses Serverkomponenten (vorzugsweise SingleCall)
- Kopplung der Geschäftlogik über Erweiterungsmethoden an DataSet-Elemente
- Paketierung: Client -> Shared <- Server

So vorbereitet werden die 5 die tolltesten Anwendungen zusammen entwickeln. Natürlich werden im Lauf des Projekts immer neue Architekturentscheidungen dazukommen, aber fürs KickOff-Meeting reicht das erstmal.

Was hat das Team aber nun genau bis hierhin festgelegt?

1. Die zu verwendenden Werkzeuge
2. Wie die Werkzeuge einzusetzen sind

Nun kann das Team mit dem eigentlichen Software-Entwurf beginnen. Also entwerfen der Grundstruktur, Definition der Datenstrukturen, Entwerfen von Oberflächen-Prototypen, Konzepte für die Umsetzung spezieller Anforderungen erarbeiten.

Die Arbeit wird ihnen leicht fallen, da sie mit dem selben Satz an Werkzeugen arbeiten und die selben Begriffe verwenden. Also wie im Krankenhaus.

Rainbird hat gesagt…

Vortsetzung des vorherigen Posts ...

Warum ist mein Szenario aber trotzdem meistens keine gelebte Realität?

Weil es oft nicht so ist, dass alle im Team die benötigten Werkzeuge beherrschen. Entwickler Egon hat z.B. die letzten drei Projekte nur ASP.NET gemacht. Dann kommt noch hinzu, dass es nicht immer so klar auf Hand liegt, welche Werkzeuge zu verwenden sind.

Im OP entscheidet der operierende Arzt, ob er gerade den Tupfer oder doch gleich die Knochensäge haben will. Die Schwester wird nicht fragen: "Welchen Tupfer denn?". Aber das Entwicklerteam könnte sich z.B. eventuell in Grundsatzdiskussionen verlieren, welche Datenzugriffstechnologie für dieses Projekt die geeignetste ist.
Entwicklerin Anna hat vielleicht mit Datenbindung über den Forms-Designer mal schlechte Erfahrungen gemacht, weil sie dieses Werkzeug in einem Projekt verwenden musste, es aber noch nicht richtig beherrscht hatte. Empört schimpft sie "Der Designer macht doch eh nur Mist.".

Natürlich kann es auch sein, dass eine unsinnige Vorgabe von Oben bzw. vom Kunden kommt. Feature X muss zwingend mit Technologie Y umgesetzt werden, ohne dass das sinnvoll begründet wird.

Aber der ganze Schlamassel hat nichts damit zu tun, dass die 5 Entwickler unter den Begriffen Softwarearchitektur/Softwareentwurf verschiedene Dinge verstehen. Es sind einfach die zu verwendenden Werkzeuge und wie man sie richtig einsetzt nicht klar. Aus welchen Gründen auch immer.

Wenn die Werkzeuge aber klar sind und die 5 Entwickler sie auch alle beherrschen, dann ist der Rest einfach gutes Teamwork. Dran bleiben und sicherstellen, dass jederzeit alle im Team über jegliche Architekturentscheidungen Bescheid wissen.

Ein eingespieltes Team wird in kürzerer Zeit qualitativ hochwertigere Ergebisse liefern. Das ist auch im Krankenhaus so. Auch wenn Menschen manchmal als Human Resource gesehen werden, die man einem Projekt einfach mal zubuchen kann, wenn sie verfügbar sind, ist es nicht gleichgültig, ob Egon mit Fritz oder am Ende mit Basti zusammenarbeiten soll.

Ralf Westphal - One Man Think Tank hat gesagt…

@Rainbird: I beg to disagree. Natürlich ist es im Krankenhaus genauso wichtig, dass alle dieselben Werkzeuge beherrschen. Wenn da ein Chirurg mit einem Endoskop für einen minimalinvasiven Eingriff in der Tür steht und niemand außer ihm hat so ein Ding vorher gesehen, dann geht das auch nicht.

Ich meine es also ganz ernst, wenn ich sage: Es liegt nicht an den Tools. Sonst wären ja nicht funktionierende Teams, also Entwickler, die schon lange zusammenarbeiten, kein Problem. Die haben sich natürlich alle schon lange auf ihre Tools und Technologien geeinigt.

Tools und Technologien sind nachrangig.

Wenn ich Leute habe, die dieselben Vorstellungen davon haben, wie Software prinzipiell entwickelt wird, die eine gemeinsame Vorstellung von systematischem Vorgehen haben, dann können die auch alle mit unterschiedlichen Tools an den Start kommen - und schaffen es am Ende doch. Natürlich müssen die sich dann erst mit Toolauswahl und so herumschlagen. Doch das ist für sie kein Problem, weil sie dafür die nötigen Meta-Skills haben: soft skills.

Andersherum geht es aber nicht: Da stehen 5 Leute zusammen, die alle top mit einer Toolpalette sind. Und dann? Die kommen nicht vom Fleck. Sie wissen nicht, wie sie mit einander umgehen sollen. Sie wissen nicht, wie sie ein Problem angehen sollen.

Fehlende Tools: unkritisch. Fehlende Methode: kritisch.

In der Praxis findet man natürlich immer eine Mischung. Tendenziell ist es aber so - und ich sehe viele ganz verschiedene Teams jedes Jahr -, dass es an Methoden (und damit an Gemeinsamkeiten in vielerlei Hinsicht) mangelt.

Gerade heute habe ich mit einem Geschäftsführer, der auch noch "Programmiererhäuptling" ist, gesprochen. Es war wie im Buch. Es gibt keine Einheitlichkeit im Team - außer, wenn er ansagt. Das Geschäft funktioniert also, weil die Programmierung autokratisch geführt ist.

Damit lässt sich Geld verdienen. Aber das hat eben seine Grenzen, die man dort nun sehr schmerzhaft spürt. Sonst hätte er mich nicht kontaktiert.

Man kann eine Gruppe von Entwickler ausrichten, indem man jeden einzelnen solange in den Hintern tritt, bis alle in dieselbe Richtung schauen. Dann nochmal treten und sie marschieren los :-) Und dann immer wieder treten, sonst bleiben sie stehen.

Ich finde das anstrengend. Mindestens. Das ist am Ende sowas wie Micromanagement.

Wenn es aber anders laufen soll. Wenn eine Gruppe Entwickler ein Team (!) sein soll... dann kann es keinen Antreiber mehr geben. Dann muss "shared understanding" in allen Aspekten her. Und dabei kann man nicht drauf hoffen, dass es vielleicht da ist. Das muss sicher sein bzw. sicher hergestellt werden. Ganz schnell.

Matthias Hlawatsch hat gesagt…

@Rainbird
Du schreibst „Angenommen für ein Projekt ist die Architekturentscheidung - zunächst - auf folgende Werkzeuge gefallen“. Eine Passiv-Konstruktion, die hübsch das eigentliche Problem versteckt. Architekturentscheidungen fallen nicht (schon gar nicht vom Himmel), sie werden immer von jemandem getroffen – von einem einzelnen oder einer Gruppe, bewusst und absichtlich oder auch unbewußt nebenbei, „by doing“. Hoffentlich aber ersteres, also explizit und mit Überlegung. Aber dafür muss man doch wissen, was die Aufgabe der betreffenden Person(en) ist, was auf der Tagesordnung steht – und was nicht. Darum geht es hier: was ist zu entscheiden und zu erarbeiten, wenn es um Software-Architektur geht? Wie soll das Ergebnis aussehen, was soll es leisten? Und genauso für Software-Design. Ich stimme Ralf zu, dass da noch viel zu wenig Klarheit und Übereinstimmung herrscht.

Kleines Beispiel gefällig? Du führst als Teil der Architekturentscheidung auf „Quellcodeverwaltung: TFS“. Für mich hat das mit Architektur gar nichts zu tun. Mein Kriterium: wo ich meine Sourcen verwalte, hat keinen direkten Einfluss auf die Eigenschaften des Endprodukts. Anderer Punkt: Du fokussierst stark auf Technologien und Tools. Gehört für mich zwar mit dazu (ein Hausarchitekt muss sich auch irgendwann zwischen Holz und Stein entscheiden), steht aber nicht im Vordergrund. Wichtiger sind Fragen wie: bauen wir ein „richtiges“ Domänenmodell, lesen/schreiben wir einfach nur „Daten“ oder formen wir daraus Objekte, ist prinzipiell der Einsatz eines O/R-Mappers sinnvoll? (Oder eben, wie in Deinem Beispiel, nicht, und es wird mit DataSets oder etwas anderem gearbeitet.) Folgt die Kommunikation der Metapher verteilter Objekte, entfernter Dienstaufrufe oder asynchronem Nachrichtenaustausch? Wieviel Logik am Client, am Server, in der DB? Welches UI-Pattern – MVP, PresentationModel, oder möglichst schnell vom EventHandler zur Datenbank? Usw. Wenn das geklärt ist, können die passenden Technologien ausgewählt werden, und der große Vorteil aus meiner Sicht ist, dass man dann auch weiß, warum man sie verwendet. So ziemlich jede Technologie lässt sich nämlich auch missbrauchen, und wenn gar nicht klar ist, warum eine bestimmte Bibliothek ausgewählt wurde, dann steigt die Gefahr erheblich, dass irgendjemand das auch macht.

Vielleicht hattest Du das auch alles mit im Hinterkopf und hast es nur nicht so deutlich hingeschrieben, aber ich formuliere mal allgemein und nur leicht überspitzt die Hypothese: es gibt genug Leute in der Branche, die eine Handvoll Kästchen mit Technologienamen drin und ein paar Pfeilen dazwischen für eine komplette Software-Architektur halten. Und es gibt welche, die das nicht so sehen. Und es gibt viele, die da noch nie so richtig drüber nachgedacht haben. Und um diese Diskrepanz geht es Ralf (glaube ich zumindest), und ich stimme ihm darin zu, dass es not tut, sie deutlich zu verringern.

Anonym hat gesagt…

Software-Architektur ist der Aufbau der Software. (Die statik, damit das Bauwerk nicht in sich zusammen fällt.)

Software-Design ist der Prozess aus einer Idee/Anforderung zur Software-Architektur zu gelangen.

Rainbird hat gesagt…

@Matthias Hlawatsch: Es geht ja nicht nur um den Begriff Architektur, sondern auch um Softwareentwurf (engl. software design). Unter den Überbegriff Softwareentwurf gehören alle Aspekte des Erstellens einer Software. Dazu zählt auch Quellcodeverwaltung, Projektorganisation, Status-Besprechungen (engl. meetings), Dokumentation, usw.

Es geht nicht nur um Werkzeuge, sondern auch um konkrete Methoden, Entscheidungen und Teamwork.

Natürlich stehen am Anfang die Anforderungen und nicht die Werkzeuge. Werkzeuge werden nach den Anforderungen ausgewählt. Aber nicht nur! Sie werden auch anhand der Fähigkeiten des Teams ausgewählt. Wenn wir z.B. keinen Webentwickler dabei haben, können wir keine Webanwendung schreiben, selbst wenn das eine Anforderung ist.

Die Technologieauswahl kann natürlich auch nach und nach erfolgen. Ob ich mit System.Diagnostics oder NLog oder Log4Net Protokolldateien erstelle, wird in der Architektur eine untergeordnete Rolle spielen. Aber ob ich Windows.Forms oder WPF oder ASP.NET für mein GUI nehme, oder vielleicht auch eine Auswahl davon, muss ich sehr früh wissen und festlegen, dann das hat große Auswirkungen auf die Architektur.

Deshalb sage ich, dass die Achitektur und die Methoden des Softwareentwurfs sehr stark von der Auswahl der Werkzeuge beeinflusst werden. Deshalb spielen meiner Meinung nach, Werkzeuge eine größere Rolle, als oft fälschlicherweise angenommen wird.

Softwareentwurf braucht selbstverständlich auch fundierte Vorgehensweisen. Davon gibt es jede Menge für die verschiedensten Aspekte des Softwareentwurfs, z.B. TDD, AOP, ORM, SOC, YAGNI, DI, EBC, FlowDesign, UML, Scrum, xp, usw.

Das sind alles Methoden, Vorgehensmodelle und Prinzipen die man unter den Überbegriffen Softwareentwurf und Architektur einordnen kann.

Aber welche ich davon für mein Projekt einsetze, hängt maßgeblich an den Werkzeugen. Ich kann natürlich Werkzeuge wählen, die Methoden unterstützen, welche ich gerne Einsetzen will (weil sie für das konkrete Projekt sinnvoll sind, nicht weil sie cool, hip oder sonst was sind). Mann kan auch andersrum vorgehen. Egal, Methoden und Werkzeuge stehen in einer engen Beziehung.

Noch ein Wort zu DataSets. Ob meine Datenklassen vom DataSet-Designer oder vom Entity.Framework-Designer oder vom Linq2SQL-Designer erzeugt werden, hat mit der Qualität einer Software nichts zu tun.

Warum habe ich in meinem Beispiel DataSets und nicht OR-Mapping aufgeführt?

Bei dem Beispiel handelt es sich um eine verteilte Anwendung (Stichwort .NET Remoting). Das Werkzeug ADO.NET Entity Framework unterstüzt verteilte Anwendungen nur mangelhaft und ist deshalb für die Anforderung "Verteilte Anwendung" nicht gut geeignet. Außerdem habe ich als GUI-Werkzeug Windows.Forms angegeben. Die Datenbindung von Windows.Forms hat eine ausgezeichnete Unterstützung für DataSets/DataTables. Die beiden Werkzeuge arbeiten sehr gut zusammen. Das ist auch ein Faktor bei der Entscheidung für oder gegen bestimmte Werkzeuge. Passen die Kandidaten gut zusammen? Das Gespann Windows.Forms + .NET Remoting + DataSets ist aus einem Guss und arbeitet reibungslos zusammen (Das liegt natürlich auch daran, dass die drei aus der selben "Epoche" kommen und zur selben Zeit veröffentlicht wurden.

Was haben wir bis jetzt herausgefunden?

- Es gibt mehr als nur Werkzeuge
- Methoden stehen aber mit Werkzeugen in Beziehung
- sog. Soft Skills sind außerdem erforderlich
- Softwareentwurf != Architektur

Eine präzise Definition der Begriffe haben wir aber immer noch nicht.