The Human Factor in Software Engineering

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."

Am 22. Oktober findet ab 17:30 Uhr die Auftaktveranstaltung für meine Klara Marie Faßbinder Gastprofessur an der FH Bingen statt. Der Titel meines Vortrags lautet: "Frauen im Software-Engineering - Stand der Forschung". Ort und Zeit finden Sie hier.

Meine Webseite ist nun online:
www.herrmann-ehrlich.de
"Ehrlich" ist nicht mein Partner, sondern das Firmenmotto. :-)

My website now is online:
www.herrmann-ehrlich.de

I proudly can announce that my article submitted to the journal "Risk Analysis" has been accepted. After having been in the repeated reviewing process for one year. These experts gave me a lot to think about, to read further literature, to do further statistical analyses, etc. It is a hard job to publish in a good journal. :-)
Anyway, persistence often pays. It is just important to know / guess right where this will be the case.