The Human Factor in Software Engineering

Using the data about accidents that have taken place, the risk of the maximum accident has been corrected. The research group of Jos Lelieveld (Max-Planck-Institut für Chemie in Mainz, Germany) counted 14.500 years of nuclear power plant operation so far and 4 worst case accidents (one in Tschernobyl, three in Fukushima). Multiplying this frequencies with the number of active nuclear power plants (440 currently active, 60 further are planned), they obtained an average mean time between two such accidents of 10-20 years. South-western Germany is the region with the highest risk, because the density of nuclear power plants (German and French) is highest here. We (me!) can expect one accident in 50 years. The probabilities had been assumed to be 200 times lower so far! This study has recently been published in the journal "Atmospheric Chemistry and Physics".

Die Frage "Was braucht die Einführung von Software Engineering Methoden?" beschäftigte mich weiter. Da es sich bei der Einführung letztlich um nichts mehr und nicht weniger handelt als um das Einführen von organisationalen Veränderungen, las ich mehrere Bücher über Change Management. In dieser Disziplin weiß man, wie man Veränderungen einführt. Davon können wir lernen. Ich habe dabei zweierlei gefunden: Die fünf Phasen eines Veränderungsprojektes und was dabei wichtige Prinzipien sind. Meine beste Quelle war das Buchkapitel von Axel Kaune "Moderne Organisationsentwicklung – ein Konzept zur mitarbeiterorientierten Gestaltung von Veränderungsprozessen" (in: Axel Kaune (Hrsg): Change Management mit Organisationsentwicklung - Veränderungen erfolgreich durchsetzen. Erich Schmidt Verlag, 2. Auflage, 2010, S. 11-66).

Die fünf Phasen eines Veränderungsprojektes sind:
1. Auftragsphase: Hier wird geklärt: Ziele, Kompetenzen, Kapazitäten, Zeiträume, Vertraulichkeit, Vorgehen bei Widerständen.
2. Diagnosephase: Analysiert wird die Ist-Situation: Probleme, Fakten, Emotionen; darauf aufbauend werden Hypothesen entwickelt.
3. Planungsphase: Geplant werden Maßnahmen + Plan, Zeitpläne, Verantwortlichkeiten, Kriterien für Erfolg
4. Durchführungsphase: Der Umsetzungsprozess erfolgt so plangemäß wie möglich, so flexibel wie nötig.
5. Auswertungsphase: Führten die Maßnahmen zur Zielerreichung? Ggf. werden nun Folgemaßnahmen geplant.

Die SWE-Einführung braucht...
- klare Ziele und Kennzahlen, z.B. weniger Fehler/ Missverständnisse, Zertifizierung
- Einbeziehung und Beteiligung der Mitarbeiter, z.B. bei Zieldefinition, Prozessentwurf und Auswahl der Notation
- viel offene, klare Kommunikation
- Rückhalt durch die gesamte Organisation, d.h. es muss klar sein, wer wie vom SWE profitiert, und welche Rolle sie spielen im Einführungsprozess
- Identifikation von und Umgang mit Widerständen
- gutes Timing
- Training, Moderation
- Coaching, Feedback

Das ist nun natürlich recht abstrakt. Wenn ich es mir konkret vorstelle, klingt es nach vielen Meetings, viel Vermittlungsarbeit, bis man genau die Software Engineering Methode gefunden hat, mit der alle leben können (=Kompromiss). Schulungen sind nur ein Teil des ganzen großen Einführungsprojektes. Oder der Anfang.

Prof. Dr. Jochen Ludewig: "Software Engineering: Von der Theorie in die Praxis - Von der Praxis in die Theorie"

Gestern Abend hielt Prof. Ludewig bei der GI-Regionalgruppe Stuttgart-Böblingen (http://rg-stuttgart.gi.de/) einen Vortrag mit obigem Titel. Die Schwierigkeiten beim Transfer von Forschungsergebnissen in die Praxis und auch umgekehrt die Schwierigkeit von Forschern, überhaupt über die Schwierigkeiten der Praxis zu erfahren, sind hinlänglich bekannt. U.a. gibt es nur wenige Forscher mit Praxiserfahrung, insbesondere unter den Doktoranden. Dieser Vortrag ging aber noch weiter und zeigte auf, in wie fern Software Engineering Forschung anders ist als die Ingenieurwissenschaften und der Rest der Informatik. Das Software Engineering entwickelt nicht Problemlösungen, sondern Modelle und Techniken, die man auf die Problemlösung anwenden kann. Hierfür braucht es in den Firmen einen Wissens-Scout, der Tagungen und Zeitschriften nach nützlichen Ansätzen durchsucht. Leider werden sogar bei den ganz großen Firmen genau diese entsprechenden Abteilungen und Stellen immer weiter eingespart.

Prof. Ludewig betont, dass Software Engineering nur dann erfolgreich ist, wenn es das Denken und Handeln von Menschen verändert. Das Software Engineering darf sich daher nicht damit zufrieden geben, Modelle und Techniken zu entwickeln, sondern muss sich auch beschäftigen mit der Einführung eines Verfahrens im Zusammenspiel von Randbedingungen, die Veränderung des Selbstverständnisses der Beteiligten und wie man Widerständen und Problemen umzugehen ist. Hierzu ist mehr empirische Forschung nötig und auch die kritische Erprobung von Techniken. Obwohl der Befund, dass eine Methode praktisch nicht anwendbar ist, auch ein wichtiges wissenschaftliches Ergebnis darstellt, findet man doch in wissenschaftlichen Veröffentlichungen fast nur Erfolgsberichte.

Mir spricht dieser Vortrag voll aus dem Herzen!

Dienstag 24.4. und Mittwoch 25.4. war ich in Düsseldorf auf der iqnite Konferenz.
Dort habe ich mein Tutorial "Komplexität in der Softwareentwicklung reduzieren" gehalten und mich auch selbst fortgebildet. Besonders spannend waren die Keynote Vorträge. Hier meine Key Learnings aus diesen:
- Harry Sneed ("40 Jahre Software-Qualitätssicherung im Rückspiegel: "Die Entstehung einer umstrittenen Disziplin") verkündet das Zeitalter der Tester. Die Zukunft gehört den Testern! Entwickelt wird heutzutage kaum noch, stattdessen werden vorgefertigte Komponenten integriert, z.B. Web Services. Anmerkung: Da mein Herz ja für das Requirements Engineering schlägt, möchte ich hinzufügen, dass natürlich vor dem Kaufen und Zusammenstecken von Komponenten das Requirements Engineering erfolgen muss. Requirements Engineering wird also auch wichtiger!
- Prof. Gunter Dück sprach über "Professionalität im digitalen Zeitalter". In der Zukunft werden alle Routinearbeiten und einfachen Probleme in die Cloud, an einen Automaten oder nach Indien geschickt und dort von Billiganbietern erledigt. Oder der Kunde hilft sich selbst, dank dem Wissen aus dem Internet. Dies führt zur zweiten Revolution im tertiären Wirtschaftssektor.
Ärzte, Apotheker, Professoren, Rechtsanwälte, aber auch Programmierer und Tester verlieren die gut bezahlte, leichte Arbeit und übrig bleiben nur noch die schwierigen Aufgaben und üblen Probleme. Das heißt, Dienstleister müssen in Zukunft richtig gut sein und sich auch mit exotischen Themen auskennen, wenn sie noch Geld verdienen wollen. Hinzu kommt, dass sie außer dem traditionell am höchsten gewichteten IQ noch weitere
Intelligenzen haben müssen, nämlich emotionale Intelligenz, Kreativität, Wille, Attraktivität, Sinn. Aber, so sagt Dück, 98% aller Menschen über 18 sind nicht mehr kreativ! Wir müssen uns also vollständig ändern oder untergehen, insbesondere im Vergleich zu einer jüngeren Generation, die bereits besser für die digitale Zukunft gerüstet ist.
- Joey Kelly ("NO LIMITS - Wie schaffe ich mein Ziel"): Um seine Ziele zu erreichen, selbst ganz hoch gesteckte Ziele, braucht man Biss, Disziplin, man darf nicht wehleidig sein und muss immer wieder über seine Grenzen hinaus gehen. Daraufhin habe ich meine Zieleliste für die nächsten Jahre nochmal um einige aberwitzige Ziele ergänzt. Es ist nicht völlig unmöglich, dass ich sie erreiche, aber der gesunde Menschenverstand würde mich für verrückt halten. Darum verrate ich sie auch erstmal nicht.
Und zu guter Letzt noch: J.K. meinte, dass er vielleicht irgendwann seine Deutschlandtour wiederholt. Wer mit will, solle sich melden. Er dachte wohl, wir sind alle abgeschlaffte Informatiker, die sich davor scheuen, in 17 Tagen Deutschland von Nord nach Süd zu durchqueren und nur das zu essen, was man in der Natur findet. Haha, nach dem Vortrag fragte ich J.K., ob er das ernst gemeint habe. Nee, war ein Scherz. Schade, ich wäre ernsthaft interessiert gewesen. Fasten kenne ich schon, das kann ich. Also, vielleicht mache ich demnächst meine Deutschlandtour ohne Joey. Schade ist nur, dass man über solche Wanderungen eigentlich kein Buch mehr schreiben kann. Selbst nicht, wenn man mit einem Kühlschrank reist!

Ooops, I am currently writing a publication about how to prepare and to perform a risk estimation workshop. I decided to replace my usual example of the power plant by a hospital example. I do this for two reasons. Firstly, I feel at awe to discuss about the cost of a power plant explosion. It feels like doing something nasty on a graveyard. (I think of Japan.) Secondly, I am not sure whether I am right with my argumentation.

This is what I wrote in an earlier publication:
"My favorite example of a risk event where the mere risk number does not make sense is the one of a severe accident at a nuclear power plant. Such an event´s probability is very low, but the damage can be so high that it cannot be quantified reasonably. When assuming numbers for probability and damage and multiplying them, you can obtain any arbitrary number, depending on the assumptions, and if you calculate that the risk is 1000€ per month, this is of no significance, because it is clear that such an accident must never happen, independent of whether the risk is 10€ per month or 1000€ per month. The argumentation of above works here also: If we knew for certain that a nuclear power plant explodes once a year, we would not build them."
Reads a bit like nonsense, because a lot of people still think that nuclear power plants are a safe (and cheap!) way of producing energy.

I know: Psychologists can explain this using terms like "risk perception" and "risk attenuation". It is known that risk perception is constructed by a social process, not by facts. Thinking about this is a bit scaring because this means that a lot of avoidable accidents happen while on the other hand people by risk amplification constrain their lifes and avoid doing things that are not so dangerous after all.

OK, I return to my numbers. They make feel safer, don´t they?

next shows:
organiser of the CREARE workshop (Creativity in Requirements Engineering) March 19
http://www.refsq.org/2012/workshops/

Tutorial "Komplexität in der Softwareentwicklung reduzieren" April 24, iqnite conference
http://www.iqnite-conferences.com/de/index.aspx

7-8 Mai Seminar "Entscheidungen im Software Engineering -
Systematisches und rationales Entscheiden" at SIGSDATACOM

9 Mai Seminar "Komplexität im Software Engineering" at SIGSDATACOM

Meine Vision
Software-Engineering-Methoden unterstützen...
- … Risiken zu kontrollieren, d.h. das Projektteam kann mit weniger emotionalem Stress bessere Software herstellen.
- … die Reduktion von Komplexität. Dadurch verringert sich nicht nur die Zeit für die Aufgaben (und folglich erhöht sich der Profit) und verringert die Anzahl an Fehlern, sondern vor allem vermeidet es den Schmerz der kognitiven Überlastung.
- … die Standardisierung oder sogar Automatisierung der Arbeitsprozesse des Teams. So werden die einfachen Aufgaben tägliche Routine und die Leute brauchen nur noch über die innovativen, riskanten und kreativen Teile des Projektes zu diskutieren und zu entscheiden. Kurz: Sie können sich auf das konzentrieren, das wichtig und interessant ist.

Dies sind die Themen meiner Schulungen:
- Requirements Engineering/ Anforderungsspezifikation
- Projektmanagement
- Zeitmanagement
- Komplexitätsreduktion in der Software-Entwicklung
- Entscheidungen in der Software-Entwicklung

Meine Kurse basieren auf Best Practices aus der Praxis, empirischen Forschung und meiner eigenen Vision. Ich bin spezialisiert auf kleine Projekte und leichtgewichtige Methoden.

Warum verwenden Praktiker oft Software Engineering Methoden nicht? "Das funktioniert hier nicht" ist nicht der wahre Grund. Dies kann durchaus sein, wenn Methoden oder Werkzeuge zu komplex für den Zweck sind oder einfach nicht passen. Was Praktiker aber wirklich brauchen, um ihre Software-Entwicklungs-Prozesse zu verbessern, ist:
- Die sanfte (allmähliche) Integration leichtgewichtiger Methoden in ihre aktuellen Prozesse. Auch während die Prozessverbesserung durchgeführt wird, müssen sie immer noch ihre tägliche Arbeit tun können. Jede revolutionäre Änderung hält sie nicht nur von der produktiven Arbeit ab, sondern bringt auch das Risiko mit sich, dass mit den neuen Methoden alles noch schlimmer wird als zuvor. Man schlägt sich lieber mit den bekannten Problemen herum als zu lernen, mit neuen Problemen umzugehen. Andererseits können mit einfachen Vorlagen, Checklisten oder mentalen Modellen bereits große Verbesserungen erreicht werden.
- Übersetzung von Forschungsergebnissen in die Sprache der Praktiker. Wenn ein Praktiker einen Forschungsartikel liest, fragt er sich hinterher: "Na und?", da Forschungsartikel üblicherweise nur sehr spezielle Fragen beantworten und einen inkrementellen Wissensgewinn darstellen, die für sich genommen keinen großen praktischen Nutzen haben. Um Nutzen daraus zu ziehen, müssen sie in den Zusammenhang mit dem Stand der Forschung gebracht werden, mit ähnlichen Forschungsergebnissen kombiniert und in praktische Best Practices übersetzt werden (wie: "Diese Forschungsergebnisse bedeuten, dass Sie nie mehr als 9 Aufzählungspunkte pro Folie haben dürfen.")
- Übersetzung von allgemeinen Modellen in Best Practices. Wenn ein Praktiker ein 300-Seiten-Buch liest, so kostet es ihn mehrere Stunden seiner Zeit, wiederholt aber nur dieselben abstrakten Grundkenntnisse, die er wahrscheinlich schon kennt. Um nützlich zu sein, muss abstraktes und allgemeines Wissen auf das Projekt angewendet werden, in dem man gerade arbeitet. Dies ist nicht einfach und verlangt ebenfalls einen Übersetzer.
- Sogar mit leichtgewichtigen Methoden fühlt man sich nur dann wohl, wenn man etwas Übung damit hat. Viele Leute lernen und werden überzeugt, indem sie Dinge anfassen oder tun, nicht dadurch dass sie einem Experten zuhören.

Darum besteht das Konzept meiner Schulungen darin, dass ich wissenschaftliche Forschungsergebnisse vorstelle und daraus praktische Schlussfolgerungen ziehe. Ich stelle leichtgewichtige, aber effiziente Methoden und mentale Modelle vor, und empfehle Best Practices. In den Übungen wenden die Teilnehmer die empfohlenen Methoden an und erhalten Vorlagen, Checklisten und andere einfache Werkzeuge, die mit nach Hause nehmen und bei ihrer täglichen Arbeit einsetzen können.

Viele Entscheidungen während der Software-Entwicklung verwenden Risikoschätzungen als Begründung/ Kriterium. Allerdings ist es gar nicht leicht, Risiken realistisch zu schätzen. Darum erforsche ich seit Jahren in einer Reihe von Untersuchungen, wie gut Menschen Risiken schätzen können. Ich möchte Sie bitten, den folgenden Fragebogen auszufüllen. Dies dauert nur 20 Minuten und leistet einen wichtigen Beitrag zur Erforschung der Risikoschätzungen. Sie brauchen keine Erfahrung mit der Entwicklung von Software zu haben. Bitte schätzen Sie spontan und ohne nach der richtigen Lösung zu recherchieren.

https://www.soscisurvey.de/risikoDelphi

Die Umfrage läuft noch bis Ende April 2012.
Ich sende Ihnen gerne im Juni die Ergebnisse der Untersuchung zu.

Herzlichen Dank!
Andrea Herrmann

Software Engineering methods allow to
- … control risks, what means to produce better software with less emotional stress for the project team.
- … reduce complexity. This not only reduces the time needed for specific tasks (and consequently enhances project profit) and reduces the number of errors, but first of all it reduces the pain that is caused by cognitive overload.
- …standardize or even automate the development team´s work processes, so the simple tasks become daily routine and people only need to discuss and decide about the innovative, risky and creative parts of the project. Simply: They can focus on what is important and interesting.


These are the topics of my trainings:
- requirements engineering
- project management
- time management
- complexity reduction in software engineering
- decision-making in software engineering

My courses are based on Best Practices from practice, empirical research results and on my vision.
I am specialized on small projects and light-weight methods.


I believe the reason why practitioners often do not apply software engineering methods is not “This does not work here”. This can be true when methods or tools are too complex for the purpose or simply do not fit. What practitioners need for improving their software engineering processes is:
- Smooth integration of light-weight methods into their current processes. Even while improvement takes place, they still must be able to do their daily work. Any revolutionary change not only keeps them from productive work but also entails the risk that with the new methods things become even worse than before. Managing the known problems is always preferred to learning to manage new problems. But with simple templates, checklists or mental models, much improvement can be achieved.
- Translation of research results into practitioner language. When a practitioner reads a research article, afterwards he asks “So what?” because research articles usually answer only very specific questions and present incremental knowledge gains which for themselves are of not much practical value. In order to make sense, they must be put into the state of the research context, combined with similar research results and translated into practical Best Practices (like: “These research results mean that you must never have more than 9 items on your slides.”)
- Translation of general models into Best Practices. If a practitioners takes his time to read a 300 pages book, this book although costing him several hours of his time, only repeats the same abstract basic knowledge that he probably already knows. In order to be useful, abstract and general knowledge must be applied to the project in which the practitioner works. This is not easy and might also demand a translator.
- Even light-weight methods need some experience in order to feel at ease with them. Many people learn and get convinced by touching things and by doing, not just by listening to an expert.


Therefore, the concept of my trainings is that I present results of scientific research and draw practical conclusions from them. I present light-weight but efficient methods and mental models, and recommend Best Practices. In the exercises, the participants apply the recommended methods and are provided with templates, checklists and other simple tools that they can take home and use daily.

Everything has a reason. The reason why this blog was so inactive the last months is that I realized that there are some reasons for not writing about the topics that are currently keeping me busy. Firstly, some topics are secret. I do not want that the public knows too soon what I am working on, BEFORE I publish my results. The topics on which I work for my employer are company secret anyway. Secondly, the human factor of software engineering is a topic that touches very personal and emotional questions and the answers on these are subjective, sometimes beliefs and mine are based on (Christian) moral premisses that not everyone shares. Software engineering partly is a social science and as such treats systems whose components are humans. Each human is a complex system, hardly describable by a limited set of variables. And a group of humans is a system with emerging properties that can not be derived from the properties of the individuals. A group can be more competent than the most competent member, but also more cruel than each group member alone. This complexity makes research about humans developing software a field where research is highly difficult. We can measure effects and statistically detect correlations among variables, but interpretation of research results involves beliefs and guesses.

Most of my work life, I have been employed for realizing my superiors´ visions. However, for three semesters, I was a university professor (on a vacant professorship) and tasted the liberty of realizing my own visions. I had returned from practice to science in order to do research which is relevant for practitioners, which makes work life easier. This was my vision, which I could not realize before I was my own boss. I miss this taste! Therefore, I will be my own boss again, starting 1st June 2012. So, if you like, you can hire me respectively my trainings!

I liked this article about medieval marketing:
http://www.colemanmgt.com/medieval-marketing/

Start June 1st, I will be my own boss. I will offer software engineering and management trainings. And I will finish several of my books. :-)
Andrea