Follow my new blog

Sonntag, 24. April 2011

Mehr als ein Job in der Softwareproduktion

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:

  1. Anforderungsanalyst
  2. Architekt
  3. Modellierer
  4. Arbeitsvorbereiter
  5. Codierer
  6. Prüfer
  7. 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.

Kommentare:

Lars hat gesagt…

"Architekt":
"Das ist ne Basisklasse und deswegen soll sie abstract sein. Da müssen Interfaces zwischen...und die Datenbank soll normalisert sein.
Und ich will eine hohe Testabdeckung!"

"Maurer":
"Dann bekommen aber unsere Designer Probleme, weil ihr Tool der Wahl nicht mit abstacten Controls umgehen kann. Die Abfragen laufen aber auf die ach so toll normalisierten DB 10X langsamer.
Und warum brauchen auf mal alle unsere kleinen Tools, die schon seit Jahren funktionieren Unit-Tests?"

Wer hat denn jetzt mehr recht?
Es ist doch so, dass der Architekt die Besonderheiten eines Frameworks/der Praxis kennen muss um gute Vorgaben zu machen...und der Coder muss eine Menge von Architektur verstehen, um sich der ganzen Problemlagen bewusst zu werden.

Die CCD-Initiative ist ja z.B. eigentlich Handwerkszeug für den Maurer...aber vermittelt wird auch viel Architektur-wissen. Ganz einfach, weil das eine ohne das andere nicht geht.

Ich sehe da keine Hierarchie (und das finde ich auch motivierend!). Ich sehe eher Rollen, in die man schlüpfen kann...bei dem einen Job "Software-Entwickler".

Ralf Westphal - One Man Think Tank hat gesagt…

@Lars: Natürlich gibt es erstmal nur Rollen. Aber je nach Aufgabenumfang können Rollen zu Jobs werden, mit denen Menschen dann vollauf beschäftigt sind.

Jemanden aus der Qualitätssicherung mit Architektur zu betrauen, halte ich z.B. für kontraproduktiv.

In dem einen Projekt, mag dann ein Architekt noch mitcoden, in einem anderen halt nicht. (Was nicht bedeutet, dass er nicht grundsätzlich coden können soll. Dirigenten können auch immer mindestens 2 Instrumente sehr gut spielen.)

Es geht auch nicht um Rechthaberei, sondern um unterschiedliche Perspektiven. Die stellst du ja auch da.

Wo jedoch alles über einen Kamm/Job/eine Rolle geschoren wird, da gehen solche Perspektiven schnell unter. Architektur braucht ein anderes Mindset als Implementierung und als Qualitätssicherung. Und ich behaupte: Wer das nicht glaubt, der hat das einfach noch nicht ernsthaft probiert; der hat noch keine explizite Architektur betrieben oder sich mal wirklich in den Qualitätssicherungsmodus begeben.

Mir ist auch schleierhaft, warum es immer wieder als Ideal hingestellt wird, dass alles irgendwie "eins" sei, dass alle gleich seien im Sinne von "das Gleiche tun". Das halte ich für eine romantische Vorstellung, eine Idealisierung.

Wie die Projekte aussehen, in denen alle immer alles tun und Rollen nicht differenzieren, weiß ich. Ich sehe davon Dutzende jedes Jahr. Rollen/Jobs sind nicht besetzt oder werden falsch ausgefüllt. Das führt zu massiven Qualitätsproblemen. Und alle ringen die Hände und wissen nicht, wo ansetzen zur Verbesserung.

Die Diagnose lautet dann oft Anosognosie: die Organisation ist unfähig zu sehen, wo sie ein Problem hat - selbst wenn man ihr den Finger in die Wunde legt.

Um an ein christliches Bild anzuschließen: Da ist nicht Thomas ungläubig, sondern Jesus. Der will es nicht wahr haben, dass er tot ist/war ;-)

Lars hat gesagt…

Das Problem ist ja eher, dass aufgrund von Fachkräftemangel/Demografie es immer mehr Aufgaben gibt, die von immer weniger Personen bearbeitet werden müssen.
Natürlich wäre etwas anderes wünschenswert, aber die Welt ist ja kein Ponyhof.
Es wird also leider dazu kommen, dass jeder zum selben Zeitpunkt immer mehr Rollen einnehmen muss.
Sicherlich hast du recht, dass der Einheitsbrei nichts erstrebenswertes beschreibt, aber vielleicht beschreibt er die faktische Realität (wie du es ja auch in vielen Projekten siehst).

Die Lösung einfach die Rollen möglichst mit getrennten Personen zu besetzen ist aufgrund von Kostendruck und Arbeitsmarkt relativ schwierig um zu setzen.
Die weit praktikablere müsste eigentlich darin liegen Werkzeuge zu schaffen, sodass man während der Entwicklung kaum noch Kontextwechsel im Mindset benötigt.

Und auch gerade dafür gibt es ja in deinem Blog viele spannende Anregungen...

Sven hat gesagt…

Auf den ersten Blick gefällt mir die Einteilung in die verschieden Rollen innerhalb der Softwareentwicklung schon recht gut. Sie folgt halt einfach dem Prinzip, ein großes Aufgabengebiet in mehrere kleine Teildisziplinen zu unterteilen. Im Anschluss daran werden "nur noch" die Spezialisten für die Abarbeitung der Teilaufgaben benötigt.

Allerdings sollte man dabei folgendes beachten: Viel Software wird nicht in großen Softwareschmieden entwickelt, in denen genügend Personal für die einzelnen Rollen vorhanden ist oder eingestellt werden kann. Viele Firmen haben kleine Softwareteams in ihre Produktionskette integriert um spezielle Software für ihre Produkte zu entwickeln. In diesen kleinen Teams ist dann jeder "Softwareentwickler" automatisch gezwungen sich mit mehreren, wenn nicht sogar allen, Rollen zu beschäftigen, da die Aufgabenverteilung sich meist nicht an den Rollen, sondern dem Thema (Datenbank, Softwaremodule, GUI) orientiert.

Somit sehe ich hier einige Konfliktpunkte zur schönen Aufspaltung des Softwareentwicklers in die erwähnten Rollen. Die Alternative wäre, um die Rollenverteilung einzuhalten, die Aufgabenverteilung eben nicht themenorientier, sondern rollenorientiert vorzunehmen. Dabei entstehen allerdings folgende Probleme:

1. Jeder muss mehrere Rollen übernehmen, da nicht genügend "manpower" vorhanden ist. Dies lässt sich wohl noch recht einfach lösen, indem man sinnvoll mehrere Rollen zusammenfasst und diese vergibt.

2. Die Ausrichtung eines jeden Entwicklers auf ein spezielles Thema geht verloren. Dies ist meiner Meinung nach das Hauptproblem an dieser Herangehensweise.

Ist es wirklich produktiver eine Rolle(z.B Architekt) jedes Thema(z.B. Datenbank und GUI) bearbeiten zu lassen, als einen Entwickler sein spezielles Thema komplett abarbeiten zu lassen?

Ich weiß die Antwort auf diese Frage auch nicht, tendiere aber eher zu der Meinung, dass eine themenbezogene Entwicklung in kleineren Teams eher vorteilhaft ist, da jeder Entwickler für ein "greifbares Produkt" zuständig ist. Dadurch wird auch die Kommunikation mit anderen Teams innerhalb der Firma, welche keine Software entwickeln, sonder verwenden, einfacher. Somit kann auch auf Anforderungsänderungen, Testergebnisse und Gestaltungswünsche der Software schneller und besser reagiert werden.

Ralf Westphal - One Man Think Tank hat gesagt…

Wir sollten unterscheiden zwischen Rollen und Jobs.

Ich habe in die Überschrift provokativ "Job" geschrieben. Aber eigentlich geht es mir um Rollen.

Die Rollen zu unterscheiden, ist der erste und wichtigste Schritt. Nur bei Unterscheidung der Rollen kann ich die genannten Vorteile erreichen.

Ob dann die anerkannten Rollen in Personalunion besetzt werden oder nicht, ist eine zweite Frage. Darauf gibt es einerseits nur eine teamindividuelle Antwort, die von Projektgröße, Budget und sonstwas abhängt.

Andererseits gibt es aber auch eine allgemeine Antwort, die man kennen sollte: Personalunion und damit einhergehendes Multitasking bergen die Gefahr reduzierter Effizienz und Effektivität.

Mehr will ich hier nicht sagen: "Leute, denkt dran, dass es verschiedene Rollen sind, in die die SWentwicklung zerfällt. Nicht nur Tätigkeiten einer Rolle, sondern eben Rollen."

Und dann kann jeder für sich entscheiden, wie aus den Rollen Jobs werden, die unterschiedliche Leute inne haben.

Anonym hat gesagt…

Die Auftrennung in Rollen würde in vielen Fällen helfen die heutigen Probleme (gefrickel u. frackel, fehlende Reproduzierbarkeit, zu lange Releasezyklen, ...) zu beheben. Leider wehren sich gerade die Betroffenen teilweise wie die Pest dagegen.

Jens Schauder hat gesagt…

Hi Ralph,
ich denke so weit wie es auf den ersten Blick aussieht und wie du es beschreibst sind unsere Meinungen gar nicht.

Mein Blog bezog sich auf einen Artikel von Olaf Lewitz, in dem dieser die Meinung vertritt, es gäbe keine Architekten in der Softwareentwicklung die Aufgaben wahrnehmen, wie diejenigen im Baugewerbe. Und meine These ist: Doch die gibt es, alle Entwickler nehmen Architektenaufgaben war. Nur die Maurer (die nicht denken dürfen), die gibt es nicht.

Wie du richtig feststellst macht es keinerlei Sinn alle ständig als Architekt zu bezeichnen. Aber es ist wichtig, dass alle sich bewusst sind, dass sie eine solch verantwortungsvolle Rolle wahrnehmen. Und halt nicht nur Code da hinbauen, wo es ihnen irgendwer gesagt hat.

Die Aufgaben hinter den Jobs/Rollen, die du nennst müssen alle erledigt werden. Eine Trennung zwischen diesen Aufgabenbereichen wie im Baugewerbe, in dem sich Maurer und Architekten im wesentlichen mittels Dokumenten unterhalten ist aber kontraproduktiv. Denn den Job des Maurers, streng nach Plan die Mauern zu setzen ohne über den Sinn nachzudenken. Denn übernehmen in der Softwareentwicklung Compiler und ähnliche Tools

Ralf Westphal - One Man Think Tank hat gesagt…

@Jens: Ja, eine so stumpfe Tätigkeit wie das Mauern gibt es in der SWentwicklung nicht. (Ohne den Maurern unrecht tun zu wollen.) Offshoring hat daher auch nur begrenzten Erfolg.

Alle Entwickler sollten ein Verständnis für Architektur haben.

Aber deshalb sind eben nicht alle Architekten und auch nicht zu jeder Zeit. So habe ich es aber aus deinem Artikel herausgelesen.

Ob es einen speziellen Architekten gibt, der dann gar nicht entwickelt, lasse ich mal dahingestellt. In kleinen Teams allemal kann es den nicht geben; er wäre zu teuer.

Aber in einem bin ich ganz gewiss - und auch das habe ich nicht bei dir herausgelesen: Architektur ist nicht immer. Codieren ist etwas ganz anderes als Architektur entwerfen. Wenn ich also codiere, dann bin ich eben kein Architekt.

Das bedeutet wieder nicht, dass ich dann unkreativ bin oder stumpf arbeiten könnte. Es bedeutet eben nur, dass ich dann bestimmte Entscheidungen nicht treffe.

Softwareentwicklung ist ein Produktionsprozess wie das Kochen oder der Hausbau. Da ist nicht immer alles gleichzeitig, sondern ganz unterschiedliche Tätigkeiten laufen nacheinander ab. In welcher Frequenz lasse ich wieder mal dahingestellt.

Und in diesem Prozess steht die Codierung ziemlich weit hinten. Und sie ist der kritischste Prozessschritt, als da das hergestellt wird, was sich am schwierigsten ändern lässt: Quellcode und andere Artefakte. Deshalb (!) will dieser Schritt gut geplant sein. Deshalb muss er auch explizit sein und darf nicht mit anderen vermischt sein.

Architekturentwurf ist ein vorgelagerter Schritt, der sicherstellt, dass die Implementierung das Richtige tut.

Anonym hat gesagt…

So geht Datenrettung heute: www.fotos-wiederherstellen.de und www.preiswertedatenrettung.de

Anonym hat gesagt…

Arbeite auch als Entwickler, habe aber gekündigt, da mir diese einseitige Rollendefinition auf Dauer keinen Spaß macht. In der Firma gibt es die Parteien der Konzepter, der Entwickler und der Tester. Manchmal sind Tester und Konzepter auch die gleichen Personen.

Als Entwickler bekommt man die in Visio angefertigten GUI-Vorlagen vorgeworfen und dazu ein Fachkonzept, in welchem beschrieben ist, was bei welchem Button zu passieren hat. Nur der Konzepter spricht mit dem Kunden und hat in der Regel keinerlei Programmiererfahrung.

Diese Rollentrennung halte ich für Entwickler als ziemlich frustrierend. Man bekommt man schon halb vorgekaute Entwürfe, die "nur noch" in Code zu gießen sind. Durch die fehlende Rückkopplung der Programmierung zum Design-Prozess, kommt dabei oft ein unglückliches Produkt hinten raus. Garbage in - garbage out. Für was hat man ein Informatik-Studium hinter sich, wenn man am Ende in seiner Kreativität so beschränkt wird? Identifikation und Begeisterung für das Produkt würgt man so gezielt ab. Gerade die Abdeckung des ganzen Prozesses ist doch das was der Spaß in der Softwareentwicklung bringt. Den Kunden beraten, wie man sein Problem löst, es dann selbst lösen und am Ende einem zufriedenen Kunden seine Lösung geben zu können.

Gelingt das Produkt, hat der Konzepter toll gearbeitet. Gelingt es nicht, hat es der Entwickler verbockt. So sieht es jedenfalls die Geschäftsleitung, die sich studierte Softwareentwickler als reine (frustrierte und ständig kündigende)Programmierer hält.

Zum Glück gibt es Firmen, die es anders sehen und in einer solchen werde ich bald arbeiten.