Code cleaning – aber wann? [endlich-clean.net]

Neulich habe ich ein hübsches Scrum-Buch gelesen: Scrum mit User Stories. Darin gibt es eine “Definition of Done”. Die beschreibt, wann ein User Story (Anforderung) eigentlich vom Team als fertig anzusehen ist. Denn erst wenn sie fertig ist, kann das Team mit der nächsten in einem Sprint weitermachen.

Ein Kritierium für “Done” ist darin: “Die User Story führt zu keinem Anstieg der ‘Technischen Schuld’”. Das hört sich gut an. Da hab ich bei der Lektüre sofort zustimmend genickt. An anderer Stelle ist es so formuliert: “[Nicht] refaktorisierte User Stories [sind] nicht fertig.”

Dass zu fertig die Refaktorisierung gehört, steckt auch im TDD-Vorgehen red-green-refactor drin.

Also ist alles klar, oder? Fertig bedeutet refaktorisiert. Ein Entwickler fühlt sich nicht wohl, bevor der Code nicht sauber gemacht ist. Erst dann gibt er ihn guten Gewissens an die nächste Phase im Softwareproduktionsprozess weiter. Das ist Clean Code Development.

Oder vielleicht doch nicht? Heute sind mir nämlich Zweifel gekommen.

Nein, ich zweifle nicht am Wert von Clean Code. Refaktorisierung ist ne gute Sache. Aber wann? Sollten sie am Ende einer Implementierungsphase stehen? Nein!

Es ist ein Missverständnis, mit Refactoring eine Implementation abschließen zu wollen. Ich glaube, wenn man einen kleinen Moment drüber nachdenkt, dann ist das auch ganz einsichtig. Refaktorisierter Code ist ein Feature von Software. Er steht im Grunde auf derselben Stufe mit Funktionalität oder Performance. Nur fordert dieses Feature nicht der Anwender, sondern das Entwicklerteam.

Refaktorisierung unterliegt damit genauso den Prinzipien YAGNI, KISS und Beware of Premature Optimization!

Wenn ein Entwickler auf dem Zettel hat, die Multiplikation für einen Taschenrechner zu implementieren, dann ist seine Arbeit fertig, wenn er die Multiplikation korrekt aus Sicht des Kunden implementiert hat. Wenn er darüber hinaus jedoch auch noch nach dieser getanen Arbeit refaktorisiert, dann halte ich das für eine vorzeitige Optimierung. Niemand weiß, ob der refaktorisierte Zustand der Anwendung irgendwann mal nützlich wird. Vielleicht fällt dem Kunden ein, dass er die Multiplikation nicht braucht und alles per Addition rechnet. Dann ist der Refaktorisierungsaufwand vergebens gewesen.

Ein refaktorisierter Zustand ist daher genau wie jedes andere Feature erst dann herzustellen, wenn wirklich klar ist, dass es gebraucht wird. Das bedeutet, die Arbeit an der inneren Qualität findet vor (!) der Arbeit an der äußeren Qualität statt. Das wird auch klar, wenn wir den TDD-Prozess verlängern und etwas anderes notieren:

• red-green
• refactor-red-green
• refactor-red-green
• refactor-read-green
• …

Refactor steht in der kurzen Phase “red-green-refactor” nur am Ende, weil impliziert wird, dass es danach weitergeht. Insofern finden während der Implementation eines äußeren Features natürlich immer auch Refaktorisierungen statt.

Ich halte es jedoch für sehr bedenkenswert, am Ende (!) nicht ruhen zu wollen, bevor nicht “alles” so richtig sauber ist. Stattdessen sollte der Entwicklungsprozess vorsehen, dass zu Beginn (!) der Arbeit an äußerer Qualität zuerst die nötige innere Qualität hergestellt wird. Und zwar nur die wirklich nötige innere Qualität!

Ohne ein Maß kann Refaktorisierung genauso zur Sucht werden wie Performanceoptimierung. Wenn also Performanceoptimierung nur stattfinden soll mit konkreter Zielvorgabe (“Die Suche nach einem Kunden darf höchstens 1 Sekunde dauern.”), dann soll auch Refaktorisierung nur mit konkreter Zielvorgabe stattfinden.

In Ermangelung quantifizierbarer Refaktorisierungsziele ist deshalb die Zielvorgabe einer Refaktorisierung eine innere Qualität, die die Implementation des nächsten Kundenfeatures leicht macht. Was dafür nötig ist, ist allerdings erst klar, wenn die Arbeit an diesem Kundenfeature beginnt.

Ich denke daher, die Arbeit an einer User Story sollte so definiert sein:

1. Plane Implementation der User Story bzw. einer Task innerhalb der User Story
2. Refaktorisiere vorhanden Code vor Beginn der Implementation nach Bedarf
3. Implementiere mittels refactor-red-green
4. Liefere User Story bzw. Task aus

Am Ende des letzten kleinen refactor-red-green-Schrittes bleibt dann zwar etwas technical debt übrigen, aber das macht nichts. Solange keine weitere Anforderung existiert (oder genauer: keine weitere User Story/Task begonnen wurde), wüsste ja niemand, welchem Zweck eine weitere Refaktorisierug dienen sollte.

Die ursprüngliche “Defintion of Done” ist damit sogar fast erfüllt. Zwar ist der Code nicht ohne “Technische Schuld”, aber die ist verschmerzbar klein, nein, sogar unvermeidbar, wenn Sie nicht in Bezug auf CCD in die YAGNI-Falle tappen wollen.

Nur so ist sichergestellt, dass die CCD-Bausteine konsequent, d.h. selbstbezüglich angewandt werden. CCD-Bausteine sind kein Selbstzweck und müssen mit Augenmaß angewandt werden.

Ist Kunden schlechte Softwarequalität egal? [endlich-clean.net]

In einem Kommentar zum Interview über CCD, das heise Developer mit mir gemacht hat, heißt es, dass Kunden doch sowieso keinen Sinn für schlechte Softwarequalität hätten. Gemeint ist natürlich nicht die äußere Qualität, die unmittelbar ihren Anforderungen entsprechen soll. Kunden haben selbstverständlich kein Verständnis, wenn Funktionalität fehlt oder die Software zu langsam ist. Da sind sie ganz sensibel. Gemeint ist also ein mangelnder Sinn für die innere Qualität von Software, um die es bei Clean Code Developer geht.

Das hört sich plausibel an. Ihnen ist diese innere Qualität egal, deshalb wird soviel schlechte innere Qualität produziert und akzeptiert. Ist das aber wirklich so? Ist den Kunden die innere Qualität wirklich egal?

Nein, das glaube ich nicht. Sie ist ihnen natürlich nicht egal. Ihnen mag egal sein, was Entwickler bei der Produktion schlechter Qualität empfinden, ob denen das egal ist oder sie sich ständig dabei unwohl fühlen. Aber schlechte innere Qualität ist ihnen nicht egal. Warum ist die Qualität dann so schlecht, wenn es den Kunden doch nicht egal ist und vielen (oder gar den meisten?) Entwicklern auch nicht? Ich glaube, dafür gibt es zwei Gründe:

1. Missverständnis: Die Kunden leiden unter einem Missverständnis. Sie glauben, die innere Qualität sei hoch. So wie die innere Qualität von Autos oder Butter hoch ist.
2. Blindheit: Weil die Kunden glauben, die innere Qualität sei hoch, vertrauen sie der Softwareentwicklung, wenn die ihnen sagt, wie teuer etwas sein wird und wie lange es dauert. Schlicht aus Basarmentalität heraus feilschen sie dann selbstverständlich – jeder weiß ja, dass es immer noch ein wenig schneller und preiswerter geht, als ein Anbieter behauptet –, doch letztlich akzeptieren die Kunden die Behauptungen und Versicherungen der Softwareentwicklung. Und weil sie das tun – womöglich auch aus einem Gefühl der Inkompetenz heraus –, schauen sie nicht genauer hin. Sie haben keinen eigenen Anspruch an die innere Qualität und damit keinen Maßstab und keine Messinstrumente für die innere Qualität. Auf dem Auge “Innere Softwarequalität” sind sie sozusagen blind. (Die üblichen Controller sind da übrigens kein korrektiv, weil sie selbst auch keine Wahrnehmung, keinen Anspruch an innere Qualität haben und ihr Horizont eher eng ist.)

Das bedeutet, Kunden akzeptieren aus einem Missverständnis heraus und aufgrund einer Unfähigkeit, das Gegenteil behaupten zu können, die schlechte Qualität von Software. Aber nicht, weil sie ihnen egal ist.

Wenn nun jemand daher kommt und den Kunden klarmacht, dass 1. die innere Qualität von Software schlecht ist, sie also einem Missverständnis aufsitzen, und 2. diese schlechte Qualität sie viel Geld kostet, dass hier also einiges an Einsparpotenzial in den IT-Ausgaben schlummert, dann… ja, dann muss sich die Softwareentwicklung warm anziehen. Denn dann werden die Kunden ganz deutlich ihren Qualitätsanspruch formulieren. Wohl dem also, der dann schon die Kompetenz hat, ihre neuen Ansprüche auch zu erfüllen.

Oder kommt dann alles anders? Winken die Kunden dann ab und gähnen, weil sie das doch schon alles wissen? “Klar, wir wissen, die innere Qualität ist schlecht und wir hauen riesige Summen für Änderungen an verquarzter Software raus – aber es ist uns egal. Wir tun das ganz bewusst, weil wir schneller Ergebnisse jetzt sofort sehen wollen, statt später mit höherer innerer Qualität.” Könnte es sein, dass Kunden diese Antwort geben? Vielleicht der eine oder andere. Im Großen und Ganzen bezweifle ich es jedoch.

Es bleibt also dabei: Wenn die Kunden anfangen, sich den Sand des Missverständnisses aus den Augen zu wischen und ihre Blindheit überkommen, dann wird es wirklich spannend in der Softwarebranche.

Mehr Termindruck braucht die Softwareentwicklung – aber den richtigen [OOP 2009]

heise Developer berichtet gerade über eine Studie in der Java-Welt – das 2. Java-Trendbarometer der expeso GmbH –, die die Verhältnisse bei der Projektabwicklung als nicht sehr rosig darstellt. Das ist mir als .NET-Entwickler ein kleiner Trost, denn ich dachte, in der Java-Welt sei das Gras grüner bzw. die Projektwelt rosig-erleuchteter. Nicht nur hüben, sondern auch drüben gibt es also einiges zu tun.

Die Begründung für die verbesserungswürdigen Zustände:

“Die Qualität leide[t] unter der häufig sehr stark termingetriebenen Entwicklung.”

Wer hätte das gedacht? Ja, alle denken und wissen das. Und viele ringen mit den Händen und fragen, “Ja, was sollen wir denn machen?”

Dabei ist die Lösung ganz, ganz einfach:

Softwareprojekte brauchen noch mehr Termindruck!

Wer hätte das gedacht? Wenige. Aber es ist so. Wir brauchen nicht weniger Termine, sondern mehr. Das ist der Kerngedanke der Agilität. Viele und ganz regelmäßige Termine sind nötig, damit es mit einem Softwareprojekt vorangeht. Die liegen dann 2 oder 3 oder vielleicht auch 4 Wochen auseinander. Und die Zeiträume zwischen den Terminen heißen Iteration oder Sprint.

Diese Termine sind allerdings keine Meilensteine! Das (!) ist der entscheidende Unterschied zu den heutigen Terminen, die soviel Druck machen. Denn Meilensteine definieren eine Menge von Arbeit, die geschafft sein muss; bei Meilensteinen geht es um Inhalte. Iterationsendtermine drehen sich hingegen nur um verlässliche Zeitangaben.

Iterationen takten die Auslieferung. Sie garantieren, dass zu festgelegten und sehr häufigen Terminen etwas geliefert wird, das Feedback vom Kunden bzw.  seinem Vertreter braucht. Kommt solches Feedback nicht, dann wächst die Gefahr, dass Geld und Motivation schlicht verbrannt werden. Deshalb sind es auch immer mehr Iterationsendtermine als Meilensteintermine in einem Projekt. Softwareprojekte profitieren davon, wenn Entwickler und Kunden quasi ständig kurz vor einem Abgabetermin stehen. Das nächste Release – in welcher Größe auch immer – ist immer nur maximal 2-3 Wochen in der Zukunft. Es ist sozusagen immer “Meilensteinendphase” – allerdings ohne den Scope-Druck der Meilensteine.

Denn da liegt das wahre Übel bei der Projektabwicklung: Termindruck ist nur ein Symptom von Scope-Druck, d.h. vom Anspruch eine bestimmte Menge an Inhalten zu schaffen.

Und woher kommt diese Vorstellung, dass sich zu einem Termin eine vordefinierte Menge an Inhalten, an Features produzieren ließe? Die resultiert aus einem Grundmissverständis her. Es stammt aus einer Zeit, da Softwareentwicklung im Grunde nur Hardwaremanipulation war. Sie ist ein Relikt aus der Elektrotechnik und dem Maschinenbau, die beide ausgedehnte Produktionsphasen kennen.

Mit solchen Produktionsphasen wird Softwareentwicklung verwechselt. Für ein Auto oder einen Schaltkreis oder ein Gebäude können wir schon lange recht gut angeben, wann die Produktion zu welchem Prozentsatz abgeschlossen ist. Bauphasen lassen sich planen – vorbehaltlich auftretender Störungen z.B. durch Probleme mit Lieferanten oder am Produktionsort.

Doch Softwareentwicklung ist keine Produktion! Softwareentwicklung ist Entwicklung, Entwurf, Design, Kreativität, Problemlösung. Niemand sage also, er hätte es nicht gewusst. Im Deutschen wie im Englischen steckt die Natur der Sache schon im Begriff: Softwareentwicklung, software development. Nomen est omen.

Jack W. Reeves hat das schon vor bald 20 Jahren deutlich herausgearbeitet. Er sieht “Code as Design”. Seine unmissverständlichen Worte sind hier zu lesen, und hier gibt es noch ein Wiki zum Thema. Dennoch scheint die Fehlwahrnehmung unausrottbar. Denn nicht anders ist zu erklären, dass immer noch Meilensteine als erreichbar gelten.

Wer hätte jedoch von Meilensteinen bei kreativen Aufgaben je gehört? Die Entwicklung (!) des iPod hat sicherlich nicht in festgelegten Meilensteinen stattgefunden. Die Entwicklung (!) des Smart hat sicher nicht in Meilensteinen stattgefunden. Nichts anderes ist aber auch die Entwicklung (!) einer Warenwirtschaft oder eines Dokumentenverwaltungssystems.

Entwicklung ist ein kreativer Prozess, der zwar ein grundsätzliches Ziel hat - aber bei dem man erstens nicht weiß, wie ganz haargenau das Ziel eigentlich aussieht, und zweitens wann es denn erreicht sein wird. Das ist ein fundamentales Gesetz der Softwareentwicklung. Sicherlich muss ein Entwicklungsprozess Fortschritte machen; das Gefühl einer stetigen Annäherung an das ungenaue Ziel muss da sein. Aber ansonsten ist nichts fix. Ab einer gewissen Reife der Entwicklung kann quasi immer jemand sagen, “Es ist genug! Ich bin zufrieden. Lassen wir es dabei. Wir gehen in Produktion.”

Entwicklung lässt sich nicht in Meilensteinpakete aus Inhalt+Termin verpacken. Entwicklung lässt sich höchstens zeitlich takten, um sicherzustellen, dass sie fortschreitet. Das ist alles. Das ist die Natur der Sache der Softwareentwicklung.

Und deshalb braucht Softwareentwicklung mehr Termindruck, quasi den ständig drohenden Termin. Interessanterweise droht der dann aber gar nicht mehr, wenn ihm keine Inhaltslast mehr anhaftet. Der ständig in 2-3 Wochen liegende nächste kleine Abgabetermin kann vielmehr als eine produktive Rhythmisierung der Arbeit empfunden werden.

Nur eine kleine Voraussetzung ist dafür nötig: Vertrauen. Vertrauen in die Teammitglieder, dass sie bis zum nächsten Termin ihr Bestes geben, soviel wie mit vernünftigem Zeitaufwand eben möglich ist auch inhaltlich umzusetzen. Aber das ist ein anderes Thema.

Hierarchische partielle Klassen [endlich-clean.net]

Neulich habe ich einen Weg beschrieben, um Code, der nach dem Single Level of Abstraction (SLA) Prinzip strukturiert ist, übersichtlicher zu machen – ohne gleich andere CCD-Bausteine in Anschlag zu bringen. Mein Vorschlag: Partielle Klassen. Damit kann man die durch SLA entstehende Unübersichtlichkeit einer Klasse auflösen, indem man sie partiell macht und auf mehrere Quelldateien verteilt. Ich finde, das funktioniert wunderbar.

Nur einen Nachteil gibt es: Dadurch steigt die Zahl der Quelldateien in einem Projekt. Also habe ich Teile einer Klasse, die sich mit niedrigeren Abstraktionsniveaus beschäftigen, in einen Projektordner ausgelagert:

Das war allerdings nur eine Krücke. Schön fand ich diesen Weg nicht, weil er die Klassenteile voneinander trennt. Viel besser wäre es, wenn man sie zusammenhalten könnte, indem sie dem höchsten Abstraktionsniveau echt untergeordnet werden (hier die Datei TextFileGeneratorSLAv2.cs). Meine Versuche, sie wie die Code-behind-Klassenteile “darunter zu ziehen”, schlugen leider fehl. Also habe ich mich mit dem Projektordner beschieden.

Dank Blog-Leser Karl (der Nachname ist leider mit einem Chatfenster verschwunden) kann ich diese Krücke nun jedoch wegwerfen. Karl hat mich auf dieses Visual Studio Add-In aufmerksam gemacht: VsCommands von Mokosh. Einfach runterladen, MSI-Datei auspacken und installieren; läuft mit VS 2008. Dann ist dies ganz einfach möglich:

Jetzt sind die Teile der partiellen Klasse auf einem niedrigeren Abstraktionsniveau direkt denen untergeordnet, die sie verfeinern. Mit VsCommands können partielle Klassen also quasi hierarchisch gemacht werden.

Um eine Datei einer anderen unterzuordnen, die beiden in der Reihenfolge “oben” - “unten” selektieren und dann im Kontextmenü “Group Items” aufrufen:

Sehr cooles kleines Tool! Es eröffnet eine neue Dimension der Codeorganisation in Visual Studio Projekten. Danke, Karl, für den Hinweis.

Wahrhaft modulare Software nur mit konsequent weniger Abhängigkeiten

Warum hat die Softwareentwicklung das mit der Modularität bisher nicht so richtig hingekriegt? Mir scheint eine wesentliche Ursache die zu große Abhängigkeit zwischen Modulen. Wir müssen anders über Abhängigkeiten nachdenken als bisher.

Darüber habe ich auch schonmal geschrieben, z.B. grad neulich hier. Doch mein Denken kreis immer wieder um das Problem. Deshalb hier nochmal eine etwas andere Perspektive, über die ich schon lange schreiben wollte. Anstoß hat jetzt ein Artikel in der Geo über synthetische Biologie gegeben. Dabei geht es darum, neue Lebewesen (Bakterien) zu produzieren, indem man ihre DNA aus Bausteinen (BioBricks) zusammensetzt, die jeder eine gewünschte Eigenschaft beschreiben. Ein Comic erklärt recht plakativ, wie das zu verstehen ist und funktioniert. Nein, das ist kein Science Fiction! Es wird schon getan.

Die Elektroniker können es also, die Bauingenieure, ebenso die Möbelbauer können es – und nun auch noch die Biologen. Alle können ihre Produkte aus Bausteinen, Bricks, Komponenten zusammensetzen.  Nur die Softwareentwicklung tut sich immer noch schwer. Warum?

Naja, ganz grundsätzlich können wir das natürlich auch. Softwarebausteine gibt es schon lange. Früher mussten sie statisch gelinkt werden, heute geht das dynamisch. DLLs oder Bibliotheksassemblies sind kein Hexenwerk. Allemal die User Control Industrie hat das in den letzten 18 Jahren seit VB 1.0 bewiesen.

Und dennoch: irgendwas fehlt, habe ich das Gefühl.

Was das ist, ist mir jetzt nochmal wieder bewusst geworden bei Lektüre des BioBricks-Artikels. Es fehlt uns der rechte Umgang mit Abhängigkeiten.

Ich stelle mal ein paar ganz unterschiedliche erfolgreiche Bauteile nebeneinander:

 

Warum sind Bauteile von Lego über Moto bis Steuerelement so erfolgreich? Warum funktioniert Wiederverwendung hier?

Ich glaube, erfolgskritisch ist die Entkopplung von ihrer Umwelt. Klingt nicht neu, dass zur Modularisierung irgendwie lose Kopplung gehört. Aber es hilft ja nichts: Wenn wir wider diesen Wissens es nicht tun, dann kommen wir nicht dort an, wo wir hin wollen.

All den erfolgreichen Bauteilen ist gemeinsam, dass sie keine internen funktionalen Abhängigkeiten haben. Was meine ich mit internen funktionalen Abhängigkeiten?

Ich unterscheide zwischen Abhängigkeiten. Natürlich ist die Funktionalität eines Motors davon abhängig, dass er mit Treibstoff versorgt wird. Ein UI Control muss mit Daten gefüttert werden. In einen Transistor muss Strom fließen.

Das sind für mich aber externe oder gar triviale Abhängigkeiten. Ich möchte sie mit dem Begriff Input belegen. Ohne Input erfüllt ein Baustein seine Zweck nicht. Doch dieser Input kommt von außen. Er fließt sozusagen in den Baustein hinein. An der Tonerkartusche wird von außen ein Zahnrad bewegt, ein Legostein wird auf eine Platte gesetzt, ein Treeview Control wird von außen mit Daten befüllt.

Solchem Input, d.h. äußerer Abhängigkeit, stelle ich interne Abhängigkeit gegenüber. Intern ist eine Abhängigkeit, wenn ein Baustein beim Einbau intern verändert werden muss. Dann muss er nämlich seine Umgebung kennen.

Ein unabhängiger, entkoppelter, echter und erfolgreicher Baustein sieht so aus:

Alle oben angeführten Bausteine entsprechen diesem Bild. Man steckt sie mit anderen zusammen zu einem größeren Ganzen – das dann wieder ein Baustein auf einer höheren Abstraktionsebene sein kann. Ein Motor als Baustein eines Autos besteht z.B. aus Zündkerzen, Zylindern, Rohren, Kolben usw. die alle für sich wiederum Bausteine in Bezug auf den Motor sind.

Dieses Zusammenstecken geschieht entweder direkt wie beim Motor oder indirekt über ein Medium wie eine Leiterplatte:

Indirekter Zusammenbau ist flexibler. Die Bauteile müssen nicht so gut aufeinander abgestimmt sein wie beim direkten Zusammenbau, wo wirklich eines in das andere passen muss.

Was aber tun wir, wenn wir unsere “Bausteine”, die Klassen und Assemblies unserer Software entwerfen? Wir koppeln sie ganz fundamental eng, weil wir sie intern (!) voneinander abhängig machen. Da machen auch Interfaces und Adapter keinen Unterschied. Das sieht dann so aus:

Unsere Bausteine sind allermeistens keine Black Boxes, sondern höchstens Grey Boxes. Denn wo wir etwas über die Interna wissen, da herrscht zumindest etwas Durchsicht durch die Bausteinwand. Und nichs anderes als Interna sind es, wenn wir wissen, dass ein Baustein zur Adressdublettenprüfung von einem Persistenzbaustein abhängig ist:

Früher war diese Abhängigkeit statisch und dynamisch in der Klasse, heute ist sie nur noch statisch, weil die konkrete Implementation des Persistenzbausteins dynamisch zur Laufzeit per Dependency Injection (DI) in die Dublettenprüfung “gespritzt” wird. Ein Baustein A ist nicht mehr von einem konkreten Baustein B abhängig, sondern nur noch von Bausteinen, die irgendwie wie B aussehen und funktionieren.

class EinfacheDublettenprüfung : IDublettenprüfung
{
    private IPersistenz db;

    public Einfache Dublettenprüfung(IPersistenz db) { this.db = db; }

    …
}

Das ist ein netter Fortschritt, der uns schonmal erlaubt, die Dublettenprüfung isoliert zu bauen und zu testen. Eine Komponentenwerkbank ist damit möglich, auf der ich immer nur an einem Baustein zur Zeit konzentriert arbeite.

Je länger ich darüber jedoch nachdenken, desto mehr komme ich zu der Überzeugung, dass das nur eine Symtomkur ist oder ein Übergangsstadium. Wir sollten bei DI nicht stehenbleiben. Früher waren statische Abhängigkeiten, jetzt sind noch dynamische Abhängigkeiten. Morgen sollten es keine (internen) Abhängigkeiten mehr sein.

Ja, das meine ich so. Wenn ich die erfolgreichen Bausteine anschaue, dann lehren sie uns, dass sie nur praktikabel sind, weil sie eben keine internen Abhängigkeiten haben. Wir stecken nichts in sie hinein. Es gibt keine Dependency Injection in eine Tonerkartusche hinein. Alle Abhängigkeiten sind an der Oberfläche und heißen Input. Ihnen stehen gegenüber andere “Oberflächlichkeiten”, nämlich der Output – der wiederum Input für andere Bauteile ist.

Solange wir unsere Softwarebausteine noch so entwerfen, dass wir sie (dynamisch) immer wieder anpassen müssen, solange haben wir ein Kompositionsproblem. Denn solange ist der Zusammenbau, die Komposition von etwas größerem immer schwierig. Solange gibt es nämlich kein Halten was die Kompliziertheit der “Steckverbindungen” angeht. Eine interne Abhängigkeit ist – so möchte ich mal sagen – per se eine enge Kopplung.

Sobald wir aber dahinkommen, unsere Bausteine nur über Input- und Output-“Pins” zu verbinden, werden wir erleben, dass die Entkopplung steigt und die Wiederverwendbarkeit. Dann werden wir nämlich anfangen, wirklich hierarchische System mit Bausteinen auf unterschiedlichen Ebenen zu bauen, die insbesondere auf niederer Abstraktionsebene besser wiederverwendbar sind.

Und dass sie das auf höherer Ebene nicht sind, macht dann nichts. Das liegt erstens in der Natur der Sache – ein Motherboard kann in weniger Zusammenhängen gebraucht werden als ein Kondensator, der darauf steckt – und zweitens können wir auf einer neuen “Leiterplatte” viel einfacher eine neue Baugruppe zusammenstecken.

Für mich ich also eine fundamentale Separation of Concerns (SoC) überfällig, die noch klarer als bisher mit DI Containern zwischen Baustein und Leiterplatte unterscheidet. Voraussetzung dafür: die Bausteine werden intern unabhängig.

Was könnte das für die Dublettenprüfung bedeuten? Sie wüsste nichts mehr von ihrer konkreten Umgebung. Sie würde von keinem Persistenzbaustein mehr abhängen:

Stattdessen hätte sie weitere oder anders gestaltete Inputs und Outputs, die dann mit beliebigen Inputquellen und Outputsenken verbinden ließen. Die Dublettenprüfung hätte damit die volle Hoheit über ihre “Oberfläche”. Sie wäre von keiner weiteren Schnittstelle abhängig.

Die Veränderung des Programmier- bzw. Denkmodells gegenüber dem heutigen mit seinen internen Abhängigkeiten wird noch deutlicher, wenn ich das obigen Zusammenspiel zwischen Dublettenprüfung und Persistenz “auseinanderziehe”:

Das bedeutet vielleicht etwas mehr “Leiterplattenaufwand”, aber das finde ich nicht schlimm. Der Gewinn an Entkopplung und Wiederverwendbarkeit und Klarheit (SoC) wiegt ihn mehr als auf.

Allerdings: dafür ist ein Umdenken nötig. Das will geübt sein. Ich fange grad auch erst damit an. Aber ich bin guter Dinge, dass in dieser Richtung Erfolg zu finden ist. Mehr Evolvierbarkeit tut Not. Denn wenn die biologischen System evolvierbar sind und jetzt auch noch mit echten Bausteinen “programmiert” werden können, dann sollte das doch auch ein Rezept für die Softwareentwicklung sein.

Partial Classes helfen dem Single Level of Abstraction Prinzip [endlich-clean.net]

Eines meiner Clean Code Developer (CCD) Lieblingsprinzipien ist Single Level of Abstration (SLA). Wenn man es befolgt, dann wird Code ganz einfach viel lesbarer.

Eigentlich. Denn auch wenn bei einer einzelnen Methode durch Fokussierung auf ein Abstraktionslevel die Übersichtlichkeit steigt, so kann sie für eine ganze Klasse sinken. Das habe ich immer wieder bemerkt und auf Abhilfe gesonnen. Nicht immer besteht die nämlich im Single Responsibility Principle (SRP), nach dem eine Klasse bei anhaltender Unübersichtlichkeit vielleicht besser in mehrere zerlegt werden sollte.

Aber jetzt habe ich eine Lösung im Rahmen der verfügbaren Sprach- und IDE-Mittel gefunden, glaube ich. Als Beispiel eine Methode, die eine Textdatei erzeugt und mit Zeilen aus Dummy-Worten füllt. Solche Textdateien brauchte ich neulich mal für Tests eines kleinen Flow-Frameworks.

V0 – Unrefaktorisiert

In der ersten Runde habe ich den Textfile-Generator natürlich einfach erstmal so runtergeschrieben. Nicht sehr clean, wie diese Abbildung zeigt:

Ich wollte möglichst schnell Funktionalität auf die Straße bekommen. Und da die Lösung einfach ist, war innere Qualität zunächst nicht so wichtig. Wer kennt das nicht? :-)

Die zentrale Methode Generate() sieht daher sehr typisch aus. Es steckt alles drin, was ein Mann zur Textfile-Generierung braucht ;-) Da werden solange Zeilen bestehend aus Worten erzeugt, bis eine festgesetzte Gesamtzeichenzahl (max_number_of_chars) erreicht ist. Und die Zeilen haben auch eine ähnliche Länge (MAX_CHARS_IN_LINE), die sich aus der Summe von mehreren Worten unterschiedlicher Länge (von MIN_WORD_LEN bis MAX_WORD_LEN) ergibt, die durch Leerzeichen getrennt sind. Alle soundsoviele Zeilen feuert die Routine einen Event, den der Aufrufer für eine Fortschrittsanzeige benutzen kann.

Das ist alles nicht schwer zu verstehen – aber wenn Sie in den Code blicken, müssen Sie schon einen Moment hinschauen, um die Algorithmusbestandteile zu identifizieren. Sie müssen sozusagen ihr geistiges Auge erst scharfstellen, bevor sie den Algorithmus wirklich sehen/verstehen.

Auch mit der obigen Beschreibung dauert das etwas, weil die Bestandteile/Verarbeitungsschritte nicht klar getrennt sind im Quelltext. Ein wenig helfen die Einrückungen der Schleifen. Doch letztlich zeigen sie nur an, dass etwas zusammengehört, aber nicht was es ist.

V1 – Refaktorisieren mit SLA

Viel leichter haben Sie es, wenn die Methode Generate() dem SLA Prinzip folgt:

Ah, jetzt sehen Sie klar! Die Dateierzeugung besteht aus drei Schritten: Initialisierung einer Statistik, der eigentlichen Textfile-Generierung und dann einem Abschlussbericht über die Statistik. Diese Methode liegen alle auf demselben Abstraktionsniveau – auch wenn unterschiedlichen Verantwortlichkeiten angehören (Statistik, Textfile-Generierung).

Wenn Sie dann Details interessieren, dann schauen Sie sich die Methoden genauer an, z.B. GenerateFile():

Ah, jetzt sehen Sie auch sofort klar! Geschrieben wird über einen StreamWriter() solange die Datei noch nicht groß genug ist. Eine Zeile nach der anderen wird erzeugt und zur Statistik hinzugefügt.

Und wie wird eine Zeile erzeugt? Drill-down in die Methode GenerateLine() hinein:

Ah, alles klar! Eine Zeile wird aus Worten zusammengebaut und dann weggeschrieben.

Und so weiter und so fort… SLA bietet Ihnen auf jeder Ebene einen schnellen Überblick des Zusammenspiels von Bestandteilen (ungefähr) gleicher Abstraktheit. Sie müssen sich nur soweit mit Details konfrontieren, wie für Ihr Informationsbedürfnis in einer Situation nötig ist.

SLA-Problem Unübersichtlichkeit im Großen

Wo Licht ist, da ist auch Schatten. So auch bei SLA. Die Übersichtlichkeit im Kleinen, in der Methode, führt relativ schnell zu einer Unübersichtlichkeit im Großen, in der Klasse. Denn aus einer überschaubaren Klasse mit einer Methode

ist eine geworden, die viele Methoden auf unterschiedlichem Abstraktionsniveau hat:

Nun ist es einfach zu verstehen, was Generate() tut – aber die Klasse zu betrachten verwirrt eher, auch wenn die Sichtbarkeitsangaben helfen, einen Einstieg in die Interpretation zu finden.

Schlimmer wird es mit der Unübersichtlichkeit, wenn Sie in den Quellcode schauen:

Von Abstraktionsebenen keine Spur mehr. Methoden weiter oben mögen auf einem höheren Abstraktionslevel liegen als solche weiter unten. Aber klare Grenzen sind nicht zu erkennen. Ich habe mit Einrückungen experimentiert, aber die bleiben nicht immer erhalten.

Was also tun? Muss ich denn für mehr Übersichtlichkeit gleich SRP in Anschlag bringen und neue Klassen definieren, z.B. eine für die Statistik, eine zum Erzeugen einer neuen Zeile usw. Das fände ich misslich. Denn eine weitere Klasse bedeutet immer mehr Aufwand als eine weitere Methode.

V2 – Partial Classes für mehr Übersicht

Jetzt habe ich allerdings eine Idee gehabt, die als Zwischenstufe helfen mag, die Übersichtlichkeit bei Anwendung von SLA zu erhalten, ohne auf SRP übergehen zu müssen. Ich zerlege meine methodenreichen SLA-Klassen in Partial Classes, die sich jeweils auf ein Abstraktionslevel konzentrieren.

Der “oberste” Klassenbestandteil für das Beispiel sieht dann z.B. so aus:

Er zeigt die wesentliche Methode auf höchstem Abstraktionsniveau. Wenn Sie dann mehr wissen wollen, schauen Sie sich den “darunterliegenden” Klassenbestandteil an:

Hier finden Sie nun zwei Abstraktionsniveaus vereint. GenerateFile() liegt höher als GenerateLine(). Doch da der Klassenbestandteil insgesamt nicht zu lang ist (1 Bildschirmseite) und die drei Methoden eng zueinander gehören, habe ich keine weitere Aufteilung für nötig befunden.

Insgesamt besteht der TextFileGenerator nun aus 4 Klassenbestandteilen, von denen drei die Textfile-Generierung schrittweise verfeinern und einer die auf verschiedenen Ebenen genutzten Statistikfunktionen zusammenfasst. Im Solution Explorer bekommen Sie also auch schnell einen Überblick über eine Klasse:

Ein weiterer Vorteil: Indem ich mit dem simplen SLA anfange, meinen Code zu refaktorisieren, und mit Partial Classes ein unaufwändiges Mittel nutzen kann, um die Übersichtlichkeit zu erhalten, merke ich ganz natürlich und konkret, wann sich das SRP lohnt. In diesem Szenario kristallisiert sich z.B. die Statistik als Kandidat für eine Auslagerung in eine eigene Klasse heraus. Aber das ist ein anderes Thema…

Erstmal bin ich zufrieden, in einfacher Weise Übersichtlichkeit in Klassen mit Methoden auf unterschiedlichem Abstraktionsniveau herstellen zu können. Partial Classes to the rescue. SLA kann also eines meiner Lieblingsprinzipien bleiben.

Romantik rettet die Softwareentwicklung? [OOP 2009]

Jetzt stehen mir meine wenigen Haare doch zu Berge. Jeff Atwood hat das geschafft. Aus dem witzigen Titel “Coding Horror” seines Blog – das ich eigentlich sehr schätze – ist für mich bitterer Ernst geworden. Sein Beitrag “Software Engineering: Dead?” lässt mir kalte Horror-Schauer den Rücken herunterkriechen. Wie das sein kann? Er meint das Fragezeichen in seinem Beitragstitel ernst:

“what we do is craftsmanship, not engineering. And I can say this proudly, unashamedly, with nary a shred of self-doubt.” (Atwood)

Software Engineering ist tot, es lebe die Handwerkskunst! Das ist der Schlachtruf eines Bloggers, der von Zehntausenden gelesen wird. Mit Verlaub, ich kann es nicht fassen. Schon lang er das Handwerkerherz in seiner Brust schlagen hören, aber mochte sich nicht so platt outen. Nun jedoch, anlässlich eines IEEE-Beitrags von Tom DeMarco, da fühlt er sich erleichtert und bestätigt in seinem Fühlen und lässt es raus. Und nicht nur er mag sich erleichtert fühlen, sondern eine ganze Bewegung, die des Softwareware Craftsmanship. Tom DeMarco erteilt den Software Craftsmen, den Handwerkern für die Softwareentwicklung, seine Absolution für ihre Bewegung gegen das Software Engineering:

“I’m gradually coming to the conclusion that software engineering is an idea whose time has come and gone.” (DeMarco)

Aus, Ende, tot, bye bye, Software Engineering. Sagt Tom DeMarco. Anscheinend.

Dass Jeff davon jetzt erst so freudig erregt wird, liegt am IEEE-Artikel, der der Selbstverortung von Tom DeMarco kaum ein Jahr hinterherhinkt. Denn spräche Jeff Deutsch, dann hätte er schon im Objektspektrum 6/2008 viele für ihn neue Aussagen DeMarcos schon lesen können.

Nur weil DeMarco dem Software Engineering neuerdings skeptisch gegenübersteht, sehe ich jedoch nicht, dass er das Software Craftsmanship Manifest mit Freuden unterschreibt. Er schreibt ja auch deutlich:

“I still believe it makes excellent sense to engineer software.” (DeMarco)

Seine Kritik gilt also nicht ingenieursmäßigem Denken im Allgemeinen, sondern einer konkreten Ausprägung.

“But that isn’t exactly what software engineering has come to mean. The term encompasses a specific set of disciplines including defined process, inspections and walkthroughs, requirements engineering, traceability matrices, metrics, precise quality control, rigorous planning and tracking, and coding and documentation standards. All these strive for consistency of practice and predictability.” (DeMarco)

DeMacro stört sich vor allem an der Kontrollillusion des Software Engineering, die sich in einem Berg an Messinstrumenten und Planungsvorgaben ausdrückt. Der begräbt die simple Wahrheit, die er nun erkannt hat:

“Software development is and always will be somewhat experimental.” (DeMarco)

Bravo, würd ich sagen. Hört, hört! Das (!) scheint mir – auch weil es am Ende des Beitrags steht – die wesentliche Einsicht, aus der es Konsequenzen zu ziehen gälte. Bedeutet das jedoch den Tod des Software Engineering?

Auch ich bin kein großer Freund “mächtiger Methoden” und “allumfassender Ansätze” oder “zwangsweiser Normierung”. Dennoch halte ich es für ein ganz falsches Signal für eine Branche, die zu einem Großteil auf Autodidaktentum gegründet ist, das Bisschen Ingenieurskunst, mit dem sie inzwischen aufgeladen wurde, so zu torpedieren. Der Mann, der Bärentango geschrieben hat, würde ihr damit einen Bärendienst erweisen.

Definiere Software Engineer

Was ist denn eigentlich das Problem mit dem Bild des Software-Ingenieurs, des Softwaretechnikers, des Software Engineer? Hier die grundlegenden Definitionen aus Wikipedia für Ingenieur bzw. Engineer:

“Der Begriff Ingenieur […] umfasst im herkömmlichen deutschen Sprachgebrauch im weiteren Sinne ein Berufsbild, welches durch die systematische Aneignung, Beherrschung und Anwendung von wissenschaftlich-theoretisch fundierten und empirisch gesicherten technischen Erkenntnissen und Methoden gekennzeichnet ist. […] Ingenieure sollten sich durch analytisches Denken, gute theoretische und anwendungsorientierte Fachkenntnisse, verbunden mit praxisorientierten und auf termingerechte Umsetzung bedachte Vorgehensweisen auszeichnen; Grundlage für erfolgreiches Arbeiten ist ein fundiertes Fachwissen und eine gute technische Allgemeinbildung. Die Hauptaufgabe des Ingenieurs stellt der Entwurf von Systemen dar. Dabei handelt es sich um einen komplexen Prozess, bei dem sowohl analytische Fähigkeiten als auch Kreativität eine große Rolle spielen. Die Entwurfstätigkeit ist eine schöpferische Tätigkeit, bei der der Ingenieur sein Wissen einsetzt, einem System eine bestimmte Funktion, Form oder Materialeigenschaft zu geben. Ein wichtiger Faktor bei der Entwicklung eines Systems ist aus Wettbewerbsgründen die Zeit. So muss sich der Ingenieur in der Praxis häufig mit einer nicht optimalen Lösung zufrieden geben, die aber dennoch als gut einstufbar ist.”, http://de.wikipedia.org/wiki/Ingenieur

“Engineers are concerned with developing economical and safe solutions to practical problems, by applying mathematics and scientific knowledge while considering technical constraints. The term is derived from the Latin root "ingenium," meaning "cleverness". The industrial revolution and continuing technological developments of the last few centuries have changed the connotation of the term slightly, resulting in the perception of engineers as applied scientists. The work of engineers is the link between perceived needs of society and commercial applications”, http://en.wikipedia.org/wiki/Engineer

Wo ist das sch… Problem mit diesen Definitionen? Warum sollten wir Softwareentwickler Anstoß daran nehmen? Warum sollten wir nicht danach streben, so zu arbeiten wie die hier beschriebenen Ingenieure?

Ja, gut, Software ist komplexer als ein Auto. Die Anforderungen für eine Software lassen sich schwieriger erheben als für eine Brücke. Und? So what? Sollten wir deshalb verzichten auf “systematische Aneignung, Beherrschung und Anwendung von wissenschaftlich-theoretisch fundierten und empirisch gesicherten technischen Erkenntnissen und Methoden”? Das kann weder Jeffs noch DeMarcos Ernst sein.

Gut, wir haben immer wieder Probleme mit dem Vorgehen bei der Softwareentwicklung und der Kommunikation mit Kunden und anderen Stakeholdern. Und? So what? Sollten wir deshalb nicht immer noch als Ziel haben “economical and safe solutions to practical problems, by applying mathematics and scientific knowledge while considering technical constraints”? Das können beide doch auch nicht ernsthaft meinen.

Die Softwaretechnik – deutscher Begriff für Softwareengineering – mag etwas aufgebläht sein und hier und da noch zu sehr versuchen, ihren Geschwistern einer mechanischen und elektronischen Welt nachzueifern. Sie mag noch zu sehr an einer Kontrollillusion festhalten. Aber muss sie deshalb für tot erklärt werden? Komplett tot? Da kann ich nicht anders als Quatsch! auszurufen. Da schütten Leute grad das Kind mit dem Bade aus. Und ich frage mich, was sie dazu treibt. Wie groß müssen Unsicherheit und Frust für solch eine pauschale Proklamation sein?

Sicherlich täte die Softwaretechnik gut daran, etwas aufzutauen und durchlässiger zu werden. Sie könnte von einem akademischen Dünkel entstaubt werden. Das wäre eine Integration eines Traditionsbegriffs, der nicht so falsch ist, wie Jeff und DeMarco Glauben machen wollen. Stattdessen: Ausgrenzung, Verdrängung, Amputation. Au weia!

Definiere Software Craftsmanship

Und was bietet Jeff als Alternative? Ein Hurra für das Handwerkertum. Webster´s definiert craftsman so:

“An artificer; a mechanic; one skilled in a manual occupation.”, http://1828.sorabji.com/1828/words/c/craftsman.html

Oder hier eine andere Definition:

“1. a worker in a skilled trade; artisan
2. any highly skilled, painstaking, technically dexterous worker, specif. in the manual arts”, http://www.yourdictionary.com/craftsman

Da steckt dann auch noch der artisan, der Kunsthandwerker drin:

“Der Begriff Kunsthandwerk steht für das Handwerk für dessen Ausübung künstlerische Fähigkeiten maßgebend und erforderlich sind. Die Produkte des Kunsthandwerks sind in eigenständiger, handwerklicher Arbeit und nach eigenen Entwürfen gefertigte Unikate (Kleinkunst/Autorenprodukte').”, http://de.wikipedia.org/wiki/Kunsthandwerk

Ist der Software Kunsthandwerker oder der Software Handwerker (von mir aus auch der Software Facharbeiter) nun eine soviel passendere Bezeichnung für das, wonach wir streben? Ich zumindest fühle mich nicht besser beschrieben als jmd, der “skilled in a manual occupation” ist. Und ich glaube auch nicht, dass ein Entwickler, der an einer Warenwirtschaft oder einer Hochregallagersoftware oder an einer Triebwerkssteuerung sitzt, danach streben sollte, “künstlerische Fähigkeitheit” auszubilden.

Zugegeben, wir produzieren meist Unikate. Und? So what? Ein Brückenbauingenieur tut das auch. Sind wir deshalb gleich (Kunst)Handwerker? Und auch zugegeben, wir vertun uns mit unseren Schätzungen und sollten daher ganz anders damit umgehen, agil zum Beispiel. Iterationen sind für ein Projekt wie den Potsdamer Platz eher nicht das akzeptierte Vorgehen und auch nicht nötig, wie wir sehen, wenn wir ihn besuchen. Für eine Anzeigenlayoutsoftware oder eine Gemeindeverwaltungsanwendung aber schon. Und? So what? Deshalb sollten wir uns unser Wissen nicht systematisch aneignen und nach wissenschaftlicher Erkennnis über unser Metier streben?

Termingerecht muss für uns anders definiert werden als für einen Maschinenbauer. Ok. Aber deshalb gilt doch auch für uns:

“Die Hauptaufgabe des [Softwareentwicklers] stellt der Entwurf von Systemen dar. Dabei handelt es sich um einen komplexen Prozess, bei dem sowohl analytische Fähigkeiten als auch Kreativität eine große Rolle spielen. Die Entwurfstätigkeit ist eine schöpferische Tätigkeit, bei der der Ingenieur sein Wissen einsetzt, einem System eine bestimmte Funktion, Form […] zu geben.”

Wenn die Software Craftsmanship Bewegung das nicht unterschreiben will, dann fällt mir nichts mehr ein. Wenn sie sich so gegen ein zugegeben überladenes Bild vom Software Engineer wendet, dass sie dessen Fundament - die Systematik, das Analytische, die Kreativität, die Gründung in der Wissenschaftlichkeit – aus dem Blick verliert, dann sehe ich nicht, wie sie der Branche einen Dienst erweist.

Damit behaupte ich nicht, dass die Software Craftsmen in allem falsch liegen. Keineswegs! Aber ihre plakative Botschaft, die seitenweise Zustimmung zu Jeffs Posting generiert, die halte ich für ab-so-lut kontraproduktiv.

Craftsman, d.h. Handwerker oder gar Kunsthandwerker, beschwört eine romantische Vorstellung herauf von Überschaubarkeit, Gemütlichkeit, Nähe, Ernsthaftigkeit, Stolz… dass es nur so eine Freude ist. Da riecht man förmlich den Holzleim und hört den Hobel; von Ferne tönt der Schlag des Schmieds im Verein mit dem Generalbass seines Blasebalgs; und da ein munteres Lied auf den Lippen des Schneidermeisters wie er zusammen auf dem Tisch mit seinen Lehrlingen sitzt.

Software Craftsmen sitzen natürlich nicht auf Tischen und schitzen auch nicht so wie Schmiede. Dafür wenden sie sich im Pair Programming väterlich ihren Adepten zu, lernen am liebsten auf der Walz, stehen über den technologischen Moden, bringen sich voll mit ihrer Kreativität ein und geben sich ganz der Produktqualität hin. Nicht die Tranfunzel erhellt ihre Hightech Büros, sondern die Lavalampe im Grün der korrekten Tests vom letzten automatischen Build. Zum Mittag treffen sie sich dann alle im Refektorium ihres Entwicklerklosters und lauschen der Lesung aus einer ihrer Bibeln, zum Beispiel “Clean Code” oder “Software Craftsmanship”. Anschließend zurück an die Softwarewerkbank oder in die Codeschreibstube.

Mir wird schon ganz warm ums Herz. Ich will auch…

Nein, natürlich nicht. So schön die Vorstellung ist, so verständlich ich den Wunsch nach einem anderem Leitbild als dem gescheiterten finde, das Handwerkertum halte ich für ab-so-lut ungeeignet als Vision für die Zukunft der Branche. Das ist etwas für Romantiker und überlastete Gekränkte. Kein Wunder auch in einer Branche, die am Burnout vorbeischrammt.

Fazit

Mir ist eigentlich egal, was genau “Software Engineering” bedeutet, wie es von den allgemeinen Definitionen von Ingenieur oder Engineer abweicht. Wenn ich lese, was Ingenieur bzw. Engineer im Allgemeinen tun, dann meine ich, dass wir weiterhin oder gar vermehrt danach streben sollten, so wie sie zu werden.

Die Softwareentwicklung muss noch einiges lernen. Ohne Frage. Doch dass sie mehr und besser lernt, wenn wir sie den Kunden oder nachwachsenden Generationen als Handwerk verkaufen, das kann ich nicht glauben. Software Craftsmanship, wenn es denn seinem Namen gerecht werden will, ist eine romantische Vorstellung; ich würde sogar fast schon sagen, Software Craftsmanship ist eine Regression eines Teil des kollektiven Psyche unserer Branche.

Alskönnten Ingenieure nicht mit Unwägbarkeiten umgehen, als würden sie nicht experimentieren, als würden sie nicht Stolz für ihre Arbeit empfinden, als strebten sie nicht nach Qualität, ja, und als seien sie nicht kreativ. Wasfürein Humbug, wenn Software Craftsmanship all das den Ingenieuren abspricht. Ein Elektrotechnik Ingenieur mag anders vorgehen als ein Softwareentwickler. Aber das tut auch ein Maschinenbauer oder Motorkonstrukteuer im Vergleich zu einem Elektrotechniker. Software Engineers müssen nicht in allem mit anderen Ingenieursdisziplinen gleichziehen.

Auch müssen nicht alle Softwareentwickler Software Engineers werden. Es bleibt Raum für Software Handwerker wie es Raum für Heizungsbauer und Klempner und Tischler gibt. Doch wir alle wissen, was wir einem Maurer zutrauen im Vergleich zu einem Bauingenieur. Und wir alle wissen, was wir dem korbflechtenden Kunsthandwerker zutrauen im Vergleich zu einem Webmaschineningenieur. Kunsthandwerk ist eine schöne Sache – im wahrsten Sinn des Wortes. Wenn die Schnitzerei aus schlechtem Holz ist, die getöpferte Schale nicht spülmaschinenfest… dann ist das nervig, aber nicht wirklich schlimm. Kunsthandwerkliche Produkte treiben uns selten in den Runin, wenn ihre Qualität nicht stimmt.

Wer möchte aber Hunderttausende Euro einem Kunsthandwerker anvertrauen? Oder wer lässt einen Eiffelturm von Handwerkern planen? Hand hoch!

Nein, nein, so einfach sollte es sich Software Craftsmanship oder zumindest Jeff Atwood nicht machen. Die Softwarewelt wird nicht durch mehr Romantik genesen. “Mehr Licht!” wie Goethe schon an seinem Ende sagte und vielleicht doch damit die Aufklärung meinte, das ist eher die Lösung.

Zu schade also, dass ansonsten sehr hell Köpfe wie Jeff Atwood und Tom DeMarco (der allerdings eher unfreiwillig) solchem Rückfall in “voraufklärerische Zeit” der Softwareentwicklung Vorschub leisten. Auch Robert C. Martin ist da kräftig tätig – was Clean Code Developer nicht davon abhält, seine Verdienste um “Clean Code” anzuerkennen.

Um meine Haare jetzt wieder zu glätten, lese ich am besten erstmal ein Werk über softwaretechnische Ingenieurskunst wie z.B. “das Drachenbuch” (gibt es auch in neuerer Auflage) oder dies hier.