The Human Factor in Software Engineering

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

Theresa A. Steinbach and Linda V. Knight in their article "The Relevance of Information Systems Research: Informing the IS Practitioner Community; Informing Ourselves" discuss how software engineering research can become more relevant for practice. Several measures can contribute to this:
- develop closer relationships with practitioners (e.g. by research funding by industry)
- doing more relevant research (by topics and methods of higher relevance)
- changing faculty evaluation
- better dissemination

During my researcher time I often had discussions with others, because for them it seemed natural that each research institute - like each consulting company - needs to develop its own methods and never use those of others.
It is only since I am senior enough that I could choose as research topic rather fundamental questions which I investigate by empirical research, like "Which properties must a good method have?" or "Why is this software activity so difficult to perform?"
After my experiment series about risk estimation, I am currently gathering literature about complexity and will probably come up with the idea for a new experiment series about complexity reduction in software engineering soon. I think that this is rather what practitioners will help in their work, not the requirements engineering method number 215.

Just some few thoughts about the difference of the time management of a manager and of someone who does “real work”. You know what I want to say… In my work life, I have had both types of jobs, alternatingly. The really hard jobs are those where I am a manager and am expected to do real work. Because this in practice means that I am a manager as long as the sun shines and I am a worker during the night and week-ends. Without kidding!

The Manager
The manager is someone who is doing his work by communicating: listening to presentations, giving presentations, talking on the phone, reading and writing emails, publications, meeting protocols and press releases. His days are fully booked by several weeks in advance. One meeting follows the other and between the meetings does 5 minute tasks.
Such 5 minute tasks are phone calls, organizing something, reading or throwing away unread journals and emails, planning trips and sticking train tickets on paper.
This rhythm of work makes his time planning very predictable. His secretary always knows where he is and when he will be busy and when he can be called by phone.
Top managers even manage to be at two places the same time, i.e. they book several meetings for the same time and then just skip or two – or all of them, if something even more urgent pops up.
In fact, a manager´s stress is born by the fact that there is always more information crying for his attention then a human brain can take up, and there are always more meetings than he can attent.
Therefore, he needs a clear strategy and vision which helps him to decide what is important and what is less important.
But the good news is that many meetings can take place without him and he can do his job without having read all emails and all publications thrown onto him. Often, it is even not so important
whether he managed to bring all projects to fly because not starting a project is less a problem than not finishing a project.
Managers always are in hectic and must be well-organized, especially take good notes. As they do not work deeply in any project but instead supervise many of them, they easily get confused, start mixing up different projects and forget what they said yesterday, because they say so much. When I am a manager, I have 5-10 meetings/ phone calls a day and write 30-50 emails per day.
When a manager must do “real work” like reading a longer text or writing something or programming something (some managers do), he must sit on it late in the night because during the day´s hectic, between all these meetings and with the phone ringing frequently, he can not concentrate on anything for longer than 10 minutes.
Among the managers, there are not only those with a manager´s job title, but also secretaries, teachers, call center agents, doctors and hospital personnel, and many more.



Those who do the “real” work
Not everyone can organize and manage things, talk and listen. Some people must also do real work like writing text, programming software, building houses, baking break and all these basic activities where you must sit or and for a while and concentrate on something for a longer time. They all produce something and the more hours they work, the more they concentrate, the more the produce.
Often, they need some time until they have prepared the tools for their work and at the end of the work, they must clean tools, wash their hands, range material, park the tractor.
Many productive activities make no sense when you have only 20 minutes for them, especially complex knowledge work where you need 20 minutes until your brain is fully prepared for the task.
While some of the productive work can be boring, it is also relaxing and when you have routine, you can listen to music or feel the famous flow in your brain, you can become faster or better or try different variants of something. You become calm and beautiful results leave your hand like magic.
Meetings, phone calls, any disturbance keeps you not only from working and producing, but it also interrups your flow. Usually, the worker´s usefulness is measured by the number of products he produces, sometimes also by their quality. Therefore, these persons must be able to work under high concentration as long as they wish, without being disturbed.
When they work on innovative tasks, things always take 2-4 times as long as expected, and this can even happen for tasks which they have done before.
Often, there is a deadline until which things must be finished, and this is what causes the stress. The worked, too, always has more to do than he can do during your work day, but unlike the manager, no tricks are possible. Maybe, he can skip a meeting, but he can not skip or delegate his work. He must do it. He needs a clear strategy what to do in this case. Working more hours? Delivering late? Doing sloppy work and like this save time?
It is also an art to apportion large blocks of work on a longer period of time, like a marathon runner must apportion his forces.
Because of these differences between manager and worker, it makes not much sense when managers gives hints on good time management to their staff, because what works for the manager does not work for those who do the productive work.

As I love lists and statistics, I have counted how many books and articles I have read since 2004 about software engineering. They are 252 books and 2761 articles. :-)
Not counted are novels.

Each half-year, I write 2000 emails. This makes 20 per work day. Isn´t this crazy? No, I am no call center agent, I am a knowledge worker. Team work creates such an amount of communication. I apply some Best Practices for reducing the amount of emails written:
- ask less questions: Sometimes, it is attractive to just ask a stupid question in order to get the email and topic out of my mail box and send the ball of action to someone else. Until he answers my stupid question, I do not need to do anything about this topic. But, of course, the ball will return in the form of an answer. And this will force me to act anyway. Why not spare the world useless questions and just decide myself? Many people are not so fond on answering questions and making decisions, so my stupid question just creates work and stress on the other side.
- clear responsibilities: Sometimes, you do not mind who out of three persons answers your question. All you need is an answer. The problem is that the more people you send the question to, the less they will feel responsible for answering. Why me? Someone else will answer... If you want to triple the probability that you get an answer, then you must write to three persons individually, not by the same email.
- Tracking: 50% of all questions and tasks I send out by email go to the abyss. Some people´s inboxes are black holes where messages disappear. So, you can not trust that if you have asked a question, that you get an answer. Therefore, I track when I sent which question where and do not hesitate to repeat my email two weeks later. It is even better to contact the other on another medium like phone or just popping in his office or being in the kitchen at the same time.
- do not talk about others: If you have something to say to or about someone, do not create complex forward chains. When Alice asks you who has the book about X, and you believe that it is Bob, then do not do this: ask Bob, wait for his reply to forward it to Alice. Instead, tell Bob that Alice wants to know it, send Bob her email address and tell him to answer to her directly.
- answer emails within 24 hours: In one company where I worked, we had the order to answer each email within 24 hours. Such an answer can also be an out-of-office reply or the information that I will answer next week because I am currently on a training or because I must ask Bob and he is on vacation.
- keep promises: When you do not keep to the promises you made, you need not wonder that you get avoidable emails - in the worst case going to your boss per cc. (No good style, but more painful for you than for its author.)
- no preliminary information: Do not send intermediate versions of documents or preliminary information, except for very rare cases where someone is very eager on receiving information fast, even if it is preliminary. Do not send a new version of the same document every 6 hours to everyone. Because then, people will not read any of them, they just can not distinguish between main releases and mini changes.

In my former research, I showed that goal-oriented self-management leads to detrimental side-effects. Now, I work in a company that practices goal-oriented management. Recently, I experienced one of these side-effects. One of my objectives is to submit a certain number of research proposals this year. Now, I have a research idea that is not much more than an idea and a draft, we do not even have testbed partners for the evaluation of our idea. And the research partner will be on vacation the next two weeks. The deadline for the submission is 15th October. So, what alternatives do I have?
(a) To write the proposal all alone, what would have been feasible, as I write fast. But the consortium would be not very convincing and they would probably also not be convinced of what I wrote because they had no occasion for contributing their visions. Consequently, the probability of success would be low. I expect that the project either would not be funded or it would be funded but would shipwreck. However, I would have added one point to my proposal count.
(b) There will be another deadline for this programme next spring, so we can now take our time to discuss and find the right partners, and then submit half a year later. The idea is great, and we will probably be successful then in all respects. This is better for the company, but I will personally pay for having taken this decision. I will earn less money because of this.

A system that forces me to pay with my own salary for taking decisions that lead to a better success of my company, that is quite perverse. I believe that work life is such a complex system that conditions or criteria for success can not be expressed by a handful of key performance indicators (KPI). Such criteria indeed steer decisions, but this can go in the wrong direction, as in the example above. And I could tell more of these.

Of course, one could argue that I must have failed earlier, if two weeks before the deadline I realize that there is a problem. Well, I saw the problems approaching long time ago, but it was not in my hand to organize the consortium. There were several delays NOT caused by me; I did even worked on free days when it was my turn. That´s one unjust factor in this objective: The number of submitted research proposals does not depend on me alone, it is teamwork.

PS: The publication which I wrote about the effect of KPI is in German, see: Herrmann A (2009) Wie KPIs auf Entscheidungen wirken: ein explorativer Selbstversuch im Zeitmanagement. Metrikon 2009, Kaiserslautern, Germany