Das Arbeiten – Ein Vorgang, ein Prozess oder Was?

Ich weiß nicht, irgendwie kommt mir die Diskussion über das Erstellen von Software komisch vor. Die Einen behaupten es ist ein kreativer Prozess, bei dem es wichtig ist, dass der Entwickler all seine Erfahrung und vor allem Kreativität einbringt.
Doch nicht lange und die meisten der Code Reviewer fangen an zu schimpfen.. “ Was hast du dir denn dabei gedacht, kennst du nicht das Pattern für das Problem?” oder “Warum hast du denn diesen Code hier hingeschrieben, der könnte doch viel besser dort hin gehören.” Und so weiter und so fort.
Jeder, der sich Code eines Anderen anschaut, hat irgendwas zu bemängeln. Im allerbesten Fall ist das auch so, wenn man selbst reflektiert. (Übrigens unter girldeveloper sehr schön beschrieben)
Ich frage mich, ob das so sein muss.

Andere, und deren Stimmen werden lauter, rufen nach Standards, Regeln, Normen. Da soll das Konzept nach Vorlage A oder Vorgehen B umgesetzt werden.
Passen diese Sichten irgendwie zusammen? Ich denke schon, aber wer kennt oder definiert die Grenzen von Kreativität und Normung? Gibt es sogar Verschiebungen in diesen Grenzen, sprich mal mehr oder weniger Kreativität oder Normung? Hängt das von der Lösung ab? Kann man Softwareentwicklung als Produktionsprozess betrachten, bei denen ebenfalls Kreativität und Normen Einzug gehalten haben? Wenn ja, welche? Kann man von diesen Prozessen ableiten und in die Zukunft schauen?
All diese Fragen stellte ich mir in der letzten Zeit. Ich dachte, dass dieses Thema nicht mehr relevant für mich werden würde, wo ich es doch für mich vor gut 10 Jahren abgeschlossen hatte,

Passen Kreativität und Normung zusammen?

Was für eine Frage, natürlich passt das zusammen. Einmal, weil nahezu alle Materialen in der Kunst werden nach irgendwelchen Normen hergestellt. Schaut mal nach. Aber der Künstler interessiert sich nicht dafür, sondern benutzt das Material und erschafft Kunst. Gut, der Vergleich hinkt ein ganz klein wenig. Also suche ich mir was besseres
Statt Norm verwende ich nun Regel, weil Norm in Deutschland ein sehr endgültiges Wort ist.
Also, wo wenden Künstler in kreativen Prozessen Regeln an? Ganz einfach. Ein Bildhauer wird immer dafür sorgen, dass er ausgewogen arbeitet, also das Material nicht zerstört, bevor sein Werk fertig ist. Er wird nach der einfachen Regel arbeiten, nicht zu viel Kraft auf den Meißel oder Beitel zu geben.
Ein Grafiker dreht die Feder auf die Seite, um einen dünnen und auf die breite Spitze, um einen dicken Strich zu erhalten. Um diese Regel kommt er nicht herum.
Ja und für die Softwareentwicklung gibt es inzwischen auch ein gutes leicht erlernbares Regelwerk, das der Kreativität des Individuums nicht im Wege steht. Hier kann man sich ein Bild davon machen.

Wo sind die Grenzen?

Hier wird es schwierig, denn was bedeutet schon Grenze im kreativen Prozess und gibt es überhaupt Grenzen? Desweiteren sind die Normen oder Regeln für die Softwareentwicklung noch lange nicht an einer Stelle angekommen wo man von Grenzen reden kann. Schon allein die Tatsache, dass es immer mehr Techniken, Sprachen und Lösungen gibt, verbietet geradezu eine Grenzsetzung der Normen und Regeln. Das ist eine schöne Aussage und einige stimmen mir gerade nickend zu. Doch Vorsicht ist geboten. Es muss nicht gerade gut sein, eine so hohe Vielfalt, eine so großer Artenreichtum. Es ist ein wenig wie in der Evolution, Jedes zu seiner Zeit.
Was sind also nun die Grenzen? Die bestimmen die Erschaffer von Lösungen selbst. Zum Einen durch die Lösung selbst und zum Anderen durch die Technologie und Architektur, die Prozesse und Planung sowie der Kreativität und der Organisation. Kurz die Anatomie der Lösung bestimmt die Grenzen.
Ist das gut? Ich bin derzeit der Ansicht, dass das zu viel Freiheit bedeutet, die zu hohen Reibungsverlusten führen kann. Ich werde weiter beobachten.

Softwareentwicklung als Prozess?

Nun behaupte ich, dass Softwareentwicklung in vorgegebenen Rahmen geplant und umgesetzt werden soll. Dabei darf Kreativität walten und schalten. Aber Regeln sollen unbedingt eingehalten werden. Sprich Software soll in einem Prozess entwickelt werden. Wow, eine ganz neue Aussage. Das klingt nach Erleuchtetem. Alle dürfen sich nun dieser Erkenntnis anschließen und Friede ist mit uns. Quatsch natürlich, es gibt in der Frage einen Haken. Ich behaupte, dass Software in einem mit der Industrie vergleichbaren Prozess zu entwickeln ist.
Stellen wir uns einmal vor, dass Deutschland innovativer Marktführer in der Automobilbranche ist. Fällt uns nicht schwer. Nun stellen wir uns einmal eine Entwicklungsabteilung in dieser Industrie vor. Da stehen eine Menge gut bezahlter Leute in einem Büro und erfinden plötzlich ein super duper Einparkhilfssystem und knall peng ist jedes Auto, was in dieser Sekunde vom Band geht, mit dieser Neuerung ausgestattet. Auch Quatsch. Da steckt natürlich ein hochkonzentrierter, innovativer, vor Normen ächzender Vorgang dahinter. Und jeder R&D Ingenieur behauptet, dass er kreativ bei seiner Arbeit ist. Toll, das möchte ich auch in der Softwareproduktion so sehen.
Also, ich behaupte, dass Software als Produkt in einem Produktionsprozess erschaffen werden soll. Da hat am Ende jeder etwas davon, Kunde und Entwickler. Dazu möchte ich in einem späteren Blog SCRUM und Kanban miteinander vergleichen.

Software als Prozess, geht das etwa auch?

Wenn schon die Lösung selbst als Produkt so erfolgreich hergestellt werden kann, warum sollte es nicht möglich sein, dass die Lösung selbst wie ein solcher Prozess formuliert wird. Denn stellen wir uns einmal vor, dass ein erfolgreiches Modell mehrfach angewendet werden kann.
Um diese Aussage zu stützen muss ich ein wenig in der Geschichte nach ähnlichen Aussagen suche und werde bei diversen Literatur- und Internethinweisen fündig (einfach ‘Software as a Factory’ bei Google eingeben, wirklich gutes Beiträge dabei). Mit diesem Thema haben sich also kluge Leute schon beschäftigt. Es sieht demnach so aus, dass es Bedarf gibt die Verbindung oder besser eine Analogie zwischen traditionellem Produktions- und Softwareprozess herzustellen.
In den nächsten Blogs wird es also vermehrt um eben diese Analogie gehen. EBC 2.0 ist ein hervorragender Ansatz dieses zu realisieren, mit den klassischen Komponentenmodelle klappt das zwar auch, aber es ist ein wenig komplizierter.
Jan