The Human Factor in Software Engineering

Das Fachgruppentreffen Requirements Engineering war wieder ein tolles Treffen mit interessanten Vorträgen, viel Networking und einer konstruktiven, freundschaftlichen Atmosphäre. Dazu beigetragen hat natürlich auch die großzügige Verpflegung und lückenlose Organisation durch unsere Gastgeber, die Sophisten. Ich selbst bin mit einigen neuen Ideen aus dem Treffen herausgegangen, insbesondere für zukünftige Kooperationen.

Ich möchte hier nur die beiden eingeladenen Vorträge wiedergeben, obwohl die anderen natürlich auch spannend waren.

Chris Rupp (Geschäftsführerin von Sophist) trug vor über "Blitzverblödung und tote Pferde – wie menschliche Verhaltensmuster Projekte prägen". Dabei stellte sie vier Anti-Muster vor, die wir dann auch in Kleingruppen diskutierten:
1.) Totentwicklung eines Systems: Es wird eine Software entwickelt, die keiner (mehr) braucht oder haben will. Trotzdem wird daran weitergearbeitet.
2.) Reportismus/ Managerismus: Man verbringt mehr Zeit mit Dokumentation und Rechtfertigungen als mit produktiver Arbeit.
3.) Kompliziert oder komplex: Software wird unnötig kompliziert, um die komplexe Wirklichkeit abzubilden. Dabei könnte man stattdessen den Benutzern auch ein wenig Intelligenz zutrauen.
4.) Blitzverblödung: Dieselben Themen werden immer wieder neu diskutiert. Selbst wenn bereits eine Entscheidung getroffen und in einem Protokoll dokumentiert worden war.
Diese Muster kannten wir alle, haben auch die eine oder andere Lösung dafür gefunden.

Unsere Key Note von Frau Prof. Bürsner behandelte unser diesjähriges Schwerpunktthema: "Abenteuer RE in KMU – zwischen erfolgreicher KMU-Praxis und methodischer Perfektion". Der Vortrag gab einen tiefgehenden Überblick darüber, wie in KMU Requirements Engineering praktiziert wird und machte auch Vorschläge, wie man Verbesserungen durchführen kann. Unter anderem empfahl Frau Bürsner ein inkrementelles Vorgehen. Besonders hängen geblieben ist bei mir der Begriff "Essenz des RE". Es geht nicht darum, die richtigen Notationen und Vorlagen zu empfehlen, sondern darum, diese Essenz zu vermitteln. Dies ist nun nicht nur ein Beratungs-Thema, sondern eben auch für die Lehre wichtig. Aber was ist denn diese Essenz?? Ich habe davon natürlich meine eigene Vorstellung, die sich in meinen Kursunterlagen bereits findet. Teilweise natürlich zur Verwirrung der Teilnehmer, die auf ihre "Wie soll ich es denn machen?"-Fragen eine Antwort bekommen, die beginnt mit "Es kommt darauf an...". Und dann folgt eine Fallunterscheidung. Wie aber würde ich die Essenz des RE kürzest möglich zusammenfassen? Da fiel es mir wie Schuppen von den Augen: Das gibt´s doch schon im Agilen Manifest! Genau darum geht es: Requirements Engineering unterstützt nur die Kommunikation und den Weg zum Ergebnis. Bei jeder Entscheidung in Bezug auf das RE sind die Prinzipien des Agilen Manifests die Entscheidungskriterien.

Was für ein Freudentaumel! Es ist mir gelungen, mich bei Elster anzumelden! Ich war schon so gut wie sicher, dass mich der Timeout erwischen würde. Der Tod durch Timeout tritt 90 Tage nach Beginn des ersten Anmeldungeschrittes ein. Es sind zwar insgesamt nur zwei Schritte, wie die Webseite verkündet, aber nicht mitgezählt sind unzählige Zwischenschritte, deren richtige und effiziente Reihenfolge ich mühsam durch Trial and Error herausfinden musste. Finanzamt, falls ihr einen Tipp darüber braucht, welche Informationen auf eurer Webseite fehlen, bitte melden, solange mein Trauma noch frisch ist! Ja, das Wissen ist vorhanden. Ich habe jetzt wochenlang immer wieder dieselbe Fehlermeldung erhalten, hartnäckig. Der Trick liegt darin, die beiden Tipps aus dem Benutzer-Forum durchzuführen und auch noch die Tipps der drei Hotline-Mitarbeiter, mit denen ich im Verlauf der letzten Wochen telefonierte. Alles zusammen ergibt die Lösung. Der letzte, zugegeben harmlose Scherz war dann noch dieser: Ich sollte eine PIN wählen, ganz für mich allein. Ich weiß nicht wieso, aber irgendwie dachte ich, PINs seien immer vierstellig. Ich gab also zweimalig meine neue PIN ein und den 12stelligen Aktivierungscode. Die ganze Zeit unter der Drohung, dass wenn ich den Code drei Mal falsch eingebe, doch noch alles vorbei sei. Und was passiert? Eine rote Fehlermeldung, die PIN müsse sechsstellig sein. Das steht da nirgends, Entschuldigung! Also nochmal... PIN, PIN, 12stelliger Aktivierungscode. Gratulation, Frau Herrmann, Sie sind drin!
Oder wie ein früherer Chef von mir stets sagte: "Es ist immer wieder faszinierend. Kaum macht man es richtig, funktioniert es plötzlich." Jawohl, und wie gut sich das anfühlt! Ich hatte allen Ernstes befürchtet, ich müsse einen Steuerberater damit beauftragen, mich bei Elster anzumelden.
Wieder eine Sorge weniger... Darauf einen Kakao!

Am 29.+30.11. findet in Nürnberg das Treffen der GI-Fachgruppe Requirements Engineering statt. Ich bin dort als Organisatorin der Veranstaltung und als Leiterin bzw. Mitglied von drei Arbeitskreisen. Ich freue mich schon darauf. :-)

When I first heard this saying, I thought it is nonsense. When the full bucket pours water into the empty buckets, then there is more growth in the empty buckets. And when the bucket is almost full, how much additional water can be poured into it? There is more free space in empty buckets.
But, finally, knowledge is no material like water. When I pour knowledge into my students, then I do not empty myself. Knowledge, like joy, love, friendship etc. multiplies by sharing. However, it does not multiply by a linear function. Teaching 100 students at a time is not the same as teaching 10. In a small group, each student can learn more than in a large group because in the small group there is less distance between us and I can adapt the training better to each student´s needs. On the other hand, groups can be guided to learn from each other and these synergy effects can scale, using the right exercises. Nevertheless, in a large group, my ability of steering the learning effect diminishes. I do not automatically get feedback about learning progresses and misunderstandings, but must organize such feedback loops intentionally.
I as the trainer do not loose any knowledge by teaching. I just share it. And if done well, I can learn a lot from teaching. While being an expert, I have the head in the skies and philosophise about intellectually fascinating details, my teaching forces me to stay on the earth with my feets. Again and again, I am asked what these methods are good for and how they can/ must be applied in practice. Very trivial practical questions arise like "What material is needed for this method? How many meta plan cards are needed per participant?" Teaching forces me to NOT forget that what I teach is not trivial and not self-explaining. Feedback from exercises and exams teaches me which method is how easy to learn, but also whether my teaching (material) is appropriate. Finally, as I teach the simple bascis, the training MUST allow everyone to learn everything. So, the students teach me to teach. I am only full master of a method when I can teach it, and not only apply it myself. Software engineering is team work, so this is more important in software engineering than in mathematics. One can be a good mathematician without being able to explain one´s work to everyone. But if I can not explain software engineering to all stakeholders from directors to secretaries, then I am no good software engineer. Hard, but true.
The third way how I learn from teaching is that I enter into many exercises with a more or less formal research question in mind. Some exercises are even formally prepared, executed and evaluated as scientific experiments, which not only provide aha experience to me, but also to the scientific world. Most often, the research question is informal. For instance, I was curious to apply Kano requirements prioritization compared to another method, with the same unbiased stakeholders to the same requirements, to experience the difference. For the students, it was just an exercise where we used two different methods for the same task. So, they know them both and can they apply in their job when needed. But for me as an expert, the learning effect was much higher. When prioritizing requirements in categories "low", "average" and "high", we met those difficulties that one always has then. Questions arise like "Whose perspective do we take? The user´s? The manager´s? The developer´s?" And "How high is high? What is our reference?" With Kano prioritization, those questions did not arise at all, because we clearly took the user perspective and the reference is the state of the art/ the market. This made the prioritization extremely fast and the group agreed easily. Differences in opinion could be eliminated by mentioning a competing product that already has a certain feature. It became also clear from our discussion, that when the market advances, the Kano priorities become out-dated, and that a prioritization from other stakeholders´ perspectives must probably be done additionally. This was a clear result, but I am not sure whether the students fully can enjoy this result or whether they think it is trivial. These findings were not unexpected, but as a critical spirit, I had to experience and see it before I fully believe it. In my current software engineering course, we regularly transform one UML model into another (e.g. activity diagram into sequence diagram, state diagram into activity diagram) to experience the difference. I designed these exercises in a way that also I do learn something and this makes my course more interesting for myself. Anyway, I constantly modify my courses in order that they stay interesting and new for myself. I am such a bad comedian. When the course is boring for me, then the participants fall asleep. So, I am in constant search for more exciting stuff, the latest trends, and thrilling exercises. (Well, anyway, as in IT half of the knowledge becomes obsolete within 4 years, the same is true for my training material. Half of the slides become out-dated within 4 years!)
So, yes, the teacher´s strive for learning in his own courses improves the courses.

Es ist zu putzig. Nun habe ich ca. 35 als Hausaufgabe erstellte UML-Diagramme bewertet und weiß immer noch ganz genau, ob ich dieses schon hatte. Wohlgemerkt: Es sollte KEINE Gruppenarbeit sein. Trotzdem bemerke ich gewisse "Produktlinien", d.h. Verwandtschaftsbeziehungen zwischen den Diagrammen. Die Studenten waren immerhin nicht frech genug, mir identische Kopien einzureichen. Der eine sendet in Farbe ein, der andere in Schwarz-weiß. Oder jeder im Viererteam wählt sein eigenes Layout. Oder man hat noch kleine Umbenennungen gemacht. Aus der Bedingung "richtig" wird "korrekt".
Wäre es leicht, das Original von der Kopie zu unterscheiden, dann würde ich nur einer Person die Punkte geben. Nach dem Speicherdatum der Datei mag ich dabei nicht gehen. Vielleicht sollte ich so ein Team gemeinsam entscheiden lassen, wer von ihnen den Punkt bekommt. Früher habe ich dann einfach aufgeteilt. Gab die Aufgabe 2 Punkte und vier Leute haben ein "gemeinsames" Ergebnis eingereicht, dann bekommt jeder eben nur einen halben Punkt. Die liebste Lösung wäre mir, ich könnte die Plagiatoren dazu verdonnern, stattdessen eine ganz eigene Aufgabe zu lösen. Schließlich geht es hier nicht um Punkte oder um Strafen, sondern darum, UML zu lernen!
In der nächsten Vorlesung werde ich dann mal meiner Verblüffung Ausdruck geben, wie weit die Kunst der Gedankenübertragung in diesem Kurs verbreitet ist...

Martin Wehrles "Ich arbeite in einem Irrenhaus - Vom ganz normalen Büroalltag" ist ein Buch über Firmen, in denen der Irrsinn regiert. Eine solche Organisation zeichnet sich durch die Merkmale aus:
1.) Heuchelei: Die Firma tut nicht, was sie sagt, und sie sagt nicht, was sie tut. Sie verspricht Mitarbeitern (und Kunden) mehr als sie hält.
2.) Profitsucht
3.) Egozentrik: Die Firma ist vor allem mit sich selbst beschäftigt, nicht mit dem Markt.
4.) Dilettantismus
Um diese Themen geht es dann im ganzen Buch: Um Image-Lügen, wie durch Profitsucht Firmen in den Ruin gewirtschaftet werden, um sinnlose Prozesse und sonstige schlechte Arbeit.Eine wirklich irre Firma wächst in ihre Rolle hinein und der neue Mitarbeiter passt sich schnell und gründlich an. Die Wachstumsstory einer irren Firma verläuft in den folgenden 4 Phasen:
1.) Dorfkultur: Jeder kennt jeden, alles funktioniert informell per Flurfunk und kurzem Dienstweg. Leider hat die neue, finanzschwache Firma erstmal nicht die besten aller Mitarbeiter für sich gewinnen können.
2.) Dschungelkultur: Die Firma wächst, alles wird größer, unübersichtlicher, und eigentlich funktionieren die bisherigen Vorgehen nicht mehr. Der Chef will aber nach wie vor alles wissen, alles bestimmen und alles steuern. In der Belegschaft entsteht eine Zwei-Klassen-Gesellschaft: Auf den Chefsesseln sitzen die Gründungsmitarbeiter, die Neuen arbeiten unter diesen. Eventuell sind die Neueingestellten sogar kompetenter als ihre Vorgesetzten, die ja nicht wegen ihrer Qualifikation, sondern wegen ihrer Treue befördert wurden.
3.) Stadtkultur: Wird das Chaos zu groß, erkennt man, dass Regeln nötig werden. Ab nun wird alles starr geregelt. Die Firma wird anonymer, bremst sich durch ihre neuen Regeln teilweise auch selbst aus.
4.) Wanderkultur: Mit der Etablierung der Firma etabliert sich auch ihr Irrsinn. Mitarbeiter bleiben nur noch kurz.

Durch seine echten, skurrilen und doch so wohlbekannten Beispiele und starken treffsicheren Formulierungen ist das Buch ein Lesegenuss. Hier ein paar Beispiele:
"Die Entscheidungswege vieler Firmen sind so verschlungen, dass der brasilianische Regenwald dagegen übersichtlich wie der Stadtpark wirkt. Der Dienstweg spielt kaum eine Rolle. Zwar gilt er offiziell als Entscheidungshauptstraße, doch im Alltag schleichen sich wichtige Beschlüsse auf den informellen Trampelpfaden an. Diese Wirklichkeit ist im Organigramm nicht enthalten."
§11 Irrenhaus-Ordnung: Ein neuer Mitarbeiter wird auf dem schnellsten Weg zur Vernunft gebracht und von seinen fixen Ideen geheilt. Als Vernunft darf gelten, was
die Firma schon immer tat - als fixe Idee, was der Mitarbeiter einführen will.
§16: Wer vor dem Meeting ein Problem hatte, ist danach einen Schritt weiter - er hat mindestens zwei Probleme!
§17: Mit dem Handeln im Unternehmen ist es wie mit dem Frauenzersägen im Zirkus: Man muss es nicht tatsächlich tun, sondern nur möglichst spektakulär vortäuschen. Das reicht für den Erfolg.

Martin Wehrle rät dringend, in solchen Firmen nicht zu arbeiten. Zur Unterstützung des Lesers gibt er konkrete Hilfen, z.B. einen Irrenhaus-Test, anhand dessen man
feststellen kann, wie irre die eigene Firma ist. Nach einer gewissen Zeit hat man sich ja so angepasst, dass man es ohne objektive Kriterien nicht mal mehr bemerkt. Dann gibt er Tipps für die Flucht und dafür, wie man vor der Einstellung eine irre Firma erkennt. Schon während der Bewerbungsphase und des Gesprächs ergeben sich
viele wichtige Hinweise. Beispielsweise kann man sich ja bereits frühzeitig zu Dienstschluss unter die Menge an der Bushaltestelle mischen und Mäuschen spielen. Worüber sprechen die Mitarbeiter dieser Firma, wie ist deren Stimmung, was stört sie?

Dieses Buch plädiert für gesunden Menschenverstand, für ordentliche Arbeit und versucht eine Widerstandsbewegung gegen den Irrsinn zu etablieren. Denn dieser ganze gefährliche Quatsch wird nur dadurch ermöglicht, dass wir alle mitmachen!

In the book "Nutella hat Lichtschutzfaktor 9,7: Die volle Dosis unnützes Wissen" about useless knowledge, I read that one person on average owns 60,000 things. How did they count? Do they count all the potatoes in the kitchen? Probably. I would have guessed that I own 1,000 things, when thinking of the last time when I packed everything in boxes, wrapping each single thing in paper. I think of counting seriously all my things now... I do not believe that they are 60,000, even counting all potatoes.
I also wonder: How many data files does one person own? This is easier to count. Maybe, I will count one day. I estimate that I so far got about 60,000 emails and have written about 6,000 emails in my life. Fortunately, most of them are deleted. At least, I hope so!
But: 60,000 things?? Difficult to believe. At today´s shopping, I bought 20 things, but I will eat most of them. And I do now not count all peanuts, tea bags and apples individually. Otherwise, I probably bought 200 things.

A citation from Grace Hopper: "It´s always easier to ask forgiveness than it is to get permission." *lol* I always say something similar: "If you ask for permission, you risk to get a negative answer."