Gibt es in der Softwareentwicklung nur Architekten? Jens Schauder meint es so, wenn er in seinem Blog schreibt:
“I currently work on a team of 8. 8 architects. […] There is no human construction worker involved. That is the part of the metaphor that falls apart. All the building happens by software and each developer is an architect.” [Meine Hervorhebung]
Hört sich irgendwie nett an. Klar, wer möchte nur Maurer sein, wenn er doch Architekt sein kann? Architekt klingt viel besser als Maurer oder Programmierer.
Ich halte diese Sicht jedoch für kontraproduktiv. Ebenso wie die simple Sicht, Code sei schlicht Design – und damit das Ende der Entwurfsfahnenstange erreicht (s. dazu auch diesen Blogartikel).
Wer die Softwareentwicklung runterbricht auf nur eine Tätigkeit – Architekt sein –, der stellt sie nicht nur undifferenziert dar, sondern verschenkt Chancen zur Verbesserung der Softwareentwicklung.
Schade, dass Jens nicht den Mut hat, konsequent zu sein. Denn eigentlich ist er nicht undifferenziert. Nach ihm ist der Job eines Architekten:
- Anforderungsanalyse, “They analyse what the needs of the clients are”
- Softwarerahmendefinition, “They make very detailed prescriptions about how the software is to be build”
- Usability Design/GUI Programmierung, “They design carefully how the user will interact with the resulting program”
- Build-/Releaseplanung, “They plan when what piece of the software gets build”
- Codieren, “We write programs and build scripts”
- Qualitätssicherung nicht funktionaler Anforderungen, “We carefully tune all things which the customer will see. Most notably the GUI, but also performance, stability, maintainability”
Jens sieht eine Menge verschiedener Tätigkeiten (die sogar noch weiter aufgefächert werden könnten) – doch für ihn gibt es nur einen Job, der sie erledigt: von der Kundeninteraktion bis zur Codeoptimierung.
Damit steht er nicht allein da, würde ich sagen. Andere geben dem Job vielleicht einen anderen Titel und nennen ihn nicht Architekt, sondern bescheidener einfach nur Softwareentwickler. Am Ergebnis ändert das nichts. Nach 60 Jahren Softwarebranche ist die Differenzierung damit nicht vorangekommen. Eine sich entwickelnde Branche verweigert sich damit förmlich bewusst der natürlichen Evolution jedes anderen Gewerbes.
Entweder, man ist Softwareentwickler/Softwarearchitekt – oder man gehört sozusagen nicht dazu. Alles, was damit zu tun hat, aus Anforderungen auslieferbaren Code zu machen, wird durch eine Jobbeschreibung abgedeckt.
Aber wer hätte das je bei etwas komplizierteren Gewerben wie der Gesundheitsbranche, dem Baugewerbe, dem Flugzeugbau, der Filmproduktion, der Lebensmittelproduktion oder sonstwas gehört?
“Gesundheit wird durch den Arzt hergestellt. Basta!”, “Die Butter wird vom Bauern hergestellt. Basta!”, “Den Film dreht der Regisseur. Basta!”
Ich denke, die Softwareentwicklung tut sich keinen Gefallen, aus einer grundsätzlich richtigen Analyse wie der von Reeves, dass Softwareentwicklung Design und nicht “normale” Produktion sei, zu folgern, dass alle irgendwie am Code beteiligten Architekten seien.
Solche enge Sichtweise ist kontraproduktiv aus mehreren Gründen:
- Sie steht einer unabhängigen Weiterentwicklung der unzweifelhaft sehr verschiedenen Tätigkeiten entgegen, die zur Softwareentwicklung gehören. Wo alles auf einem Haufen liegt, fällt es schwer, etwas herauszulösen und sich konzentriert um seine Verbesserung zu kümmern.
- Sie steht einer bewussten Modusänderung im Wege, die nötig ist, um die unterschiedlichen Tätigkeiten effektiv durchzuführen. Anforderungsanalyse ist schlicht etwas ganz anderes als Buildscriptbastelei.
- Sie steht einer Ausbildung im Wege, die unterschiedlichen Persönlichkeitstypen unterschiedliche Tätigkeiten effizient nahebringt. Wenn es nur einen Job gibt, dann müssen alle den einen Job lernen. Wer aber visuell inkliniert ist und sich vor allem auf Usability konzentrieren will, der muss auch den ganzen Rest pauken; und es ist fraglich, ob er seiner Neigung fokussiert später nachgehen kann, weil ja alle alles machen müssen.
- Sie steht einer gehaltsmäßigen Differenzierung im Wege, die in einer ohnehin an Aufstiegschancen schwachen Branche, nötig ist, um zukünftig mehr Menschen zu begeistern.
Dazu kommt, dass ich ganz einfach überhaupt keinen Vorteil darin sehe, erstens alle Softwareentwickler über einen Kamm zu scheren und zweitens sie auch noch alle zu jeder Zeit Architekt zu nennen. Was soll das? Hat das einen Vorteil in der Sache? Jens nennt keinen. Hat das einen Vorteil für die Personen? Jens nennt keinen. Gibt es ansonsten eine Not dazu? Jens nennt keine.
Meine Position ist daher der von Jens entgegengesetzt. Ich bin für ausdrückliche Differenzierung der Jobs in der Softwareentwicklung – oder besser in der Softwareproduktion. Denn um nichts anderes geht es: um die Produktion von Code aus Wünschen. Ideen, Wünsche, Vorstellungen werden in einem mehrstufigen Prozess in Softwareprodukte transformiert, die hoffentlich die Initiatoren und Geldgeber begeistern.
Weg mit dem allgemeinen Gerade über “Code ist Design und keine Produktion”. Klar, das ist irgendwo richtig und Unterschiede gegenüber Schusterhandwerk oder Autoindustrie sind deutlich zu machen. Deshalb aber nur noch von Architektur zu reden, schüttet das Kind allerdings mit dem Bade aus.
Wenn wir Softwareentwicklung nicht anfangen als Produktionsprozess zu sehen, der methodisch und technisch stetig verbessert werden kann, dann haben wir keinen Ansatz für Veränderungen. Dann sind Veränderungen anekotisch und subjektiv. Dann klappt etwas für den einen, für den anderen aber nicht gleich, also lässt der es sein. Allemal ist dann unklar, wo mit Veränderungen angefangen werden sollte. Solange alles undifferenziert irgendwie Teil desselben Jobs ist, ist alles gleich, was irgendwie nach Verbesserung riecht. Expression Blend steht dann auf einer Stufe mit Scrum oder Unit Tests oder Continuous Integration oder WCF oder zwei Monitoren für jeden Arbeitsplatz.
Und so haben wir uns auch in den letzten Jahren verhalten. Undifferenziert, unsystematisch. Das Ergebnis ist denn auch allerorten zu sehen: schlechte Qualität. Hohe Bugzahlen, Unwartbarkeit, Lieferverzug, Überstunden, Unsicherheit und Uneinigkeit in Entwicklergruppen (von Teams mag ich kaum reden)… das ist Normalität.
Ja, ich denke, der Grund für all das ist fundamental in einem zu suchen: in mangelnder Systematik. Man geht die Softwareentwicklung weitgehen irgendwie an. Jeder nach seiner Manier, jeder aus seiner begrenzten Perspektive. Die Welt der Projekte ist so groß wie der Teller Suppe, in dem die Mitglieder schwimmen. Darin strampelt man sich ab. Unter Druck, mit wenig Fortbildung, mit Fokus auf Code.
Das geht. Irgendwie. Muss ja auch.
Dabei könnte es mir viel weniger Schmerzen noch besser gehen. Schneller, leichter, befriedigender. Doch dafür müssen die Softwareentwickler den Kopf recken und über ihren Tellerrand blicken. Sie müssen die Komplexität des Business ernst nehmen und den Weg gehen, den alle anderen komplizierten Businesses auch gegangen sind: den Weg der Systematisierung und der Differenzierung.
Einen Vorschlag für einen systematischeren Blick auf die Softwareproduktion habe ich in einem früheren Blogartikel gemacht. Da gibt es sieben Jobs auf dem Weg von der Anforderung bis zum auslieferbaren Code:
- Anforderungsanalyst
- Architekt
- Modellierer
- Arbeitsvorbereiter
- Codierer
- Prüfer
- Qualitätssicherer
Sieben Jobs, sieben ganz unterschiedliche Tätigkeiten, sieben Persönlichkeitstypen, sieben Verantwortlichkeiten, sieben Denk-/Arbeitsmodi…
Wenn das keine gute Voraussetzung für gezielte Verbesserungen ist, weiß ich auch nicht mehr. Wer so unterscheidet, kann viel besser Fragen stellen und Qualität prüfen. Wer so unterscheidet, kann viel besser Engpässe feststellen und optimieren.
Softwareentwicklung ist mehr als ein Job; alles andere ist eine kontraproduktive Wunschvorstellung. Ob diese Jobs dann in Personalunion, allein oder in einer Gruppe erledigt werden, ist eine ganz andere Frage. Begrenzte Ressourcen und Psychologie stellen dafür die Spielregeln auf.
Unzweifelhaft ist jedoch, so denke ich, dass es eben mindestens diese verschiedenen Jobs gibt. Nicht alles, was in der Softwareproduktion passiert, ist Architektur. Und vor allem nicht alles ist Design oder Codierung.
Wer sich fragt, ob Softwareentwicklung für ihn etwas sei, muss sich also nicht fragen, ob der die nächsten Jahrzehnte “Code Slinger” sein will. Softwareentwicklung macht ein vielfältiges Jobangebot. Da ist für jeden etwas dabei, auch wenn man nicht Architekt werden will.
