The Human Factor in Software Engineering

Nun ist es offiziell: Im Wintersemester 2012/13 bekleide ich eine Gastprofessur an der FH Bingen. Meine Aufgaben bestehen in Vorlesungen über Software Engineering, Projektmanagement und wissenschaftliches Arbeiten. Außerdem führe ich mindestens zwei wissenschaftliche Studien zur Gender-Forschung in der Informatik durch.

It is now official: In the winter semester 2012/13 I will be guest professor at the University of Applied Sciences of Bingen. My tasks will be lectures in Software Engineering, Project Management and Scientific Research. Additionally, I undertake at least two scientific studies about gender in computer sciences.

A great and recent literature overview about group performance can be found here:

pdf

Teams are not always more efficient than individuals. Whether they are depends on

• the task type,
• process losses by coordination loss, production blocking and motivation loss,
• but also on motivation gain by social competition + social compensation + Köhler effect,
• individual capability gains and losses,
• leadership style
• group composition,
• group synchronization, and
• group learning.

The article discusses research findings and draws conclusions for practical work.

My literature research also brought me to this study about bullying:
http://www.pistes.uqam.ca/v7n3/articles/v7n3a2en.htm
There are many interesting findings in this study. I am most interested in these two:
- Men are bullied by their superiors exclusively and women not only from above but from all directions, including colleagues and even those below her in hierarchy. This is a strong evidence that women´s position in hierarchy is differently perceived than for men.
- Bullying seems to be related to and supported by performance-based payment. This corresponds to my experience with this tool of HR management. It is a powerful tool, exercising strong influence on people´s thinking and decisions, but it is like magic: powerful, but not completely controllable. I believe that performance- or object-oriented payment/ management destroys the team spirit. Maybe, one should treat teams as a unit and define team objectives, but I am not completely sure that this would work well. I remember from sports where the ambitious team bullied weaker team members. When they get rid of low performers, the team performance is higher. So, maybe management by numbers is a Pandora box that one should not open at all.

Most people say that weeks pass faster the older one gets and also life becomes more hectic. I believe: This is not true at all. On the opposite, our growing experience and self-confidence should take stress from us. The reason why people perceive life flying away and imposing more pressure is that they carry around more and more clutter with them. One of the handfull books that really changed my life is Karen Kingston´s "Clear Your Clutter With Feng Shui". This book´s principles I not only apply to clearing my appartment (the purpose for what the book was written), but also to data (clutter) and to time management. Recently, I deleted lots of GByte of data. And it helps. During the last years, my life has become less and less hectic thanks to my constant strive for de-cluttering, which also includes knowing exactly why each thing, person, task or working group is part of my life. There is almost nothing left that causes me negative stress, bad feelings or loss of energy. If you are interested, I can offer a course about this. For the start, you can also read Karen Kingston´s book and find out what it can do for you.

With respect to data clutter, I see the danger that you now think that storage space nowadays costs almost nothing. However, deleting and archieving is not the same. And things that are out of sight are NOT out of mind. Your subconscience knows exactly what data clutter you hide in your basements and in your data archives. And if they cause you pain when you think of them, they also cause you pain while only your subconscious mind knows of them. Delete them, trample the archive CD to pieces! (Of course, I take no warranty for any consequences of what you do. Sometimes, laws force us to archive data clutter for ten years or so. But you can at least delete the data after the legally demanded period.)

And another finding from the gender research. One extensive study was about study conditions of students in informatics and mechatronics. What sprang to my eyes was this: When being asked whether female students experience depreciating comments and behaviour, it was rather the male students who observed it and said that yes. While the female students observed this less often and said that does not mean anything and they must learn to live with it.

Ilona Horwath, Nicole Kronberger und Irmgard Wörtl: Das Technikstudium aus der Sicht von Frauen und Männern. Institut für Frauen- und Geschlechterforschung, Johannes Kepler Universität Linz, 2007 http://www.tequality.at/source/Bericht.pdf

What I wonder: Studying is a relatively low competitive field of work where collaboration is highly esteemed and resources (good grades) are no limited resource. There is no real need to depreciate women, unlike in work life where a woman might compete with a man about limited resources and he will try to push her down in the hierarchy of respect. And this further makes me wonder: If females get used to being insulted during their years of study, then they will feel less pain in the competitive struggle at work when being treated unfair. And this is a large competitive disadvantage, not to defend one´s limits. (I make a note in my head that I as an instructor will never allow depreciating remarks against any student. We practice respect! This is one of the learning objectives.)

My current literature research is about gender research in software engineering. I can not forget one claim that I found there:
Boys and men are assumed to be competent in the technological field as long as there is no proof for the contrary. If a boy/ man does bad work, people rather suppose that he did not try hard enough, than to think he might be incompetent.
Girls and women are assumed to be incompetent in the technological field as long as she can not prove that she is competent. If a girl/ woman does bad work, people assume that she is incompetent and the wrong person for this task.

Source: Sabine Collmer (1997): Frauen und Männer am Computer. Aspekte geschlechtsspezifischer Technikaneignung. Deutscher Universitätsverlag, Wiesbaden.

This corresponds to my observation that in a new job, I often get only one chance for each specific task. If I do not get it perfect on the first try (i.e. do not do it the way in which my boss would do it), he takes away this task from me forever because I "have the wrong brain structure" or "wrong personality" for doing it. This is the explanation I get when I want to continue doing this type of work. I always wondered how I manage to create the impression that I am overstrained with a task that I loved to do and even did for years before. Maybe, this is a strong part of the explanation.

Dieses Wochenende habe ich mal wieder eine weitere Tour gemacht. In Sandalen. Schließlich sind das die Schuhe, welche meine Füße gewohnt sind. Ich war erstaunt, wie viel Natur es auch in Stadtnähe gibt. Allerdings sieht man auch an den Spuren von Arbeitsfahrzeugen und Waldarbeiten, dass deutscher Wald nichts anderes ist als eine halbwegs naturbelassene Holzplantage. Besonders amüsant fand ich, dass es im Stuttgarter Wald mehr Straßenschilder gibt als in vielen deutschen Innenstädten. Nachdem ich mich zünftig verlaufen hatte, war ich über diese Beschilderung sehr froh, denn ich besitze immer noch kein Fußgänger-Navi. Ansonsten habe ich zwei Schlösser besichtigt und einen hundert Jahre alten Steinbruch. Außerdem habe ich unterwegs immer so gute Ideen. Nach meiner Heimkehr schrieb ich die Einleitung zu einem meiner neuen Bücher. Das Training geht also weiter...

The "Decision" course has started this morning - in English as well as in German.
I am currently preparing concepts for similar formats about data clutter, time management and creativity.

You (as a developer, analyst, manager) can use Software Engineering methods in two ways: either you apply the method or you use it as a mental model. Let´s take the UML use case model as an example.
1.) Method as method: Software Engineering methods come along with templates, notations, rules, tools, etc. When you apply a method in your project, you most probably will have to motivate others to use the UML tool, keep to the UML notations and rules for Use Case specification. This is usually difficult to achieve. Especially if it is not your official task to initiate work process improvements. But even if it is, people do not like to be told to change their way of working.
2.) Method as mental model: Psychologists emphasize the importance of a mental model for systematic work and for communication with your colleagues, team members and all stakeholders. Such mental models can be the project plan, the software architecture, a workflow model etc.. Their function is to steer expectations and to make that the work of each individual fits together with the rest of the project. Therefore, it is important that everyone shares the same mental model. Software Engineering methods often provide such models. You can use them as the basis for structuring all your tasks, communication and documents. You go and ask the stakeholders for actors and use cases, and also for the dependencies among these use cases. You know what to ask and when you have asked enough. Your interview gets a structure by using a method. This looks more professional than saying: "Please, tell my anything I need to know about your requirements." or "Oops, sorry, I forgot to ask one question." You note down the results in a Use Case diagram which you later copy into the requirements specification, in presentation slides, meeting protocols and reports. Maybe, you want to structure requirements document and test cases according to which use case they belong to. This helps you to keep your documents consistent and provides an informal traceability link between them. You can use an UML tool for modeling the use case model, but you need not. If you want others to also edit the graphs, then you might want to use the drawing tool that is already used by your colleagues.

You see the difference? Alternative (1) demands a change in the way of working of your colleagues, while alternative (2) means that you do your normal work in a more structured way.