The Human Factor in Software Engineering

The ERC has analyzed gender statistics in their grants: How many women submit and how many of them get funding? The success rates of women systematically are lower than those of men. Find the statistics here. I would be interested in knowing what the reasons might be. They do not investigate this further.

"Science never fails" is the motto of the Journal of Unsolved Questions. It publishes research questions which have not been solved and research efforts which did not answer these questions neither. It is not only a chronicle of failed research, but also a source of ideas for future research projects. So far, there is not much talk about software engineering there, but this can be changed. In a quiet minute, I could browse through my own papers and gather all these questions that still move me but which I have no time to answer myself.

This reminds me of a book of Goethe I read one day. When he grew older, he sketched some of his ideas for new novels which he knew he would never write because life is too short. Unfortunately, today the topics proposed there are no longer so relevant, but I liked the idea in itself. Because mature writers or researchers as experts have an abundant treasure of ideas and lack the time do realize all of them. While younger people who are no experts have difficulties to distinguish an innovative idea from a question that has already been answered. They can not easily distinguish a relevant question from an irrelevant question or a solvable problem from an unsolvable one.

My personal opinion: I hate the Ask toolbar. OK, it is my fault when I do not take care to what I install on my computer. It is my responsibility to carefully read everything during a software installation.
Well, I had deinstalled the Ask toolbar, what was really a hard piece of work. And only two weeks later, I did not take care and ... ooops.... it was back. I am now determined to destroy it again.
However, evidently, it becomes more and more difficult each time. Software which has a honest business model can be deinstalled easily. This one not. It is almost like a virus and the deinstallation procedure is similarly tedious.

I am wondering what type of programmer this is who develops something like this. What kind of morale do they have? Do they do it with a bad conscience, just for money without thinking, do they think who does not take care during an installation procedure does not deserve any respect?

Interesting, but also a pity is the following effect which I observe at many universities where I teach. At first, the new teacher has few students, because they do not know how strict she is. So at first, teaching is fun with small groups where only the best of the best students take part, who are really interested in my topic, independent of how much work the course will be. So finally, they end up with very good grades, all of them. When the co-students hear what good grades I gave, they think the course is easy. So, the course gets full the next time. All sorts of students now take part, including such who have already failed at other courses and now hope that this easy course will save their average. As people see what they expect to see, they think my course is trivial and they do not need to learn much. The exercises are trivial, everything trivial. This naturally ends up with really bad exams. We had that recently. Students complained that this exam was more difficult than the other ones and that the exercises in the course where simpler, too. So, they could not expect me to write such a difficult exam. Puh, it was not more difficult than anything else. Of course, it is a psychological effect that the same exercise looks more difficult in the exam. When I studied, I calculated exam questions in half the official time during exam preparations, but never in the exam itself. There, I was slower. Well, anyway, the exam was a massacre. For me, it was painful to correct, too. But I know that I just need to continue. After these ups and downs, finally, students will understand that my course is simply just. Those who work hard get excellent grades, those who do not work hard, can not make it. For the moment, however, the shock is deep. My next course had to be cancelled because no-one wanted to take it. I hope they will return like the tides...

I am not only a trainer, but also a learner. Life-long learning!

As statistics show, almost all MOOC participants drop out from a MOOC sooner or later. Some probably simply are persons who spontaneaously register for any course that sounds interesting, even if they have no time for it, or they register because they think they should learn something in this domain, but in fact do not really want to. They will probably find out very soon. But some learners maybe just need a good strategy how to manage their self-learning.

Here, I offer you some Best Practices for MOOC participants which proved to be useful for my own self-learning:
- Limiting number of inscriptions: Only register for courses for which you have time and motivation. When you register and do not follow the course, this will only make you feel bad. Each MOOC description tells you how many hours per week the course will need. This is usually meant serious. Of course, if you have previous knowledge, you can be faster, and if the topic is completely new to you, you might need more. But essentially, you can assume that the course takes the hours announced. If you are a good time manager, you can quantify exactly, how many hours you can spend on learning. As a rule, for a normal person who already has a full day, I would not recommend to take more than one course at a time.
- Reserving time: It is no use to wait whether you might have time left. You will probably not. If you want to succeed in the course, you must reserve time for it. If it demands 5 hours per week, you can schedule one hour for each day from Monday to Friday or reserve the Saturday morning. But you need to plan the time, because most MOOCs demand significant time that can not be covered by the few hours per week where you feel bored and do not know what else to do. My best time for the MOOCs are the food times: One lecture at breakfast, an exercise for lunch and a last bit of knowledge during dinner.
- Know you goals: What is your goal? Do you just want to get a rough overview? Have fun? Get the degree? Become an expert? Depending on your goal, you will need to work hard or just lean back, wait and see. However, you should know your goal and adapt your learning behaviour. If you are satisfied with a rough overview, then just watch the videos and click through the tests without preparation. If you follow higher goals, you need to consider the following Best Pratices.
- Take notes: The course provides a lot of material which you can re-read and re-watch as often as you want. However, when you try to find a specific bit of information, it is not easy to find it again. Searching is waste of time. Usually, the course contains a lot which you already know or do not need to remember. There are only few key learnings. I always take notes about these key learnings in a separate file. This is not only useful during the course, but especially half a year after the course, when I want to look up something.
- Make sure you understood everything: Even if some knowledge will not be asked for in the quiz, however if you did not understand basic concepts, ideas or words in previous sections, it can keep you from understanding the rest of the course. So, you need to look up words you did not understand and find out what it is. If a course unit was complex or you were not concentrated, then you should better watch the video twice or three times. This is one of the extra features a MOOC offers, compared to a real-life course. Use it!
- Do your homework: It is very common in school, universities and work life to not do your work yourself but just copy it from someone else. This is simple and fast. But it prevents you from learning. I know that in life knowledge counts nothing, certificates and eloquence count much more. But if your objective is to learn something in the course, you should do your homework yourself. You can discuss with others, but for really profiting of the course, you must manage to solve the exercises yourself and understand why it was the solution. I even recommend to do all the voluntary exercises. Because they help you to learn. Fluency results from practice.

Yes, yes, these are the Best Practices for those who really want to learn something. There are lots of ways to betray, but I will not teach you that.

Here a funny video about a phone conference in real: click here. That reminds me of something...

CreaRE 2015: Fifth International Workshop on Creativity in Requirements Engineering
https://sites.google.com/site/creare2015/
The workshop proceedings are available at:
http://ceur-ws.org/Vol-1342/

This Monday, March 23, CreaRE 2015 took place in Essen (Germany). Here, I give a short summary and experience report of the workshop:

• In his key note talk with the title "Creativity is not a talent, it is a way of operating!", Kim Lauenroth (adesso) started with general concepts of creativity and then discussed how much creativity there is in RE and whether the requirements engineer must be or is allowed to be creative. One could also take the position that the requirements engineer is only the "voice recorder" for the customer's voice. Only the customer is allowed to be creative, the requirements engineer simply puts the customers' ideas on paper. In any case: RE is the most creative activity in the whole software engineering process! Requirements build the bridge between problem and solution.
• Sebastian Adam and Marcus Trapp (Fraunhofer Instituts IESE) presented "Success Factors for Creativity Workshops in RE", looking back on 9 workshops they performed in industry settings for RE. The main message they repeat is that creativity workshops must be prepared and executed systematically. The creativity and flexibility is in the content, not in the process! To identify really innovative requirements, they say, mere brainstorming is not sufficient. Some of their success factors are: a set of creativity techniques which the moderators know very well, several roles (among them two moderators) for different tasks, two full days and continuous filtering and prioritization to keep the focus. What I liked to hear especially was that starting with negative ideas ("What must not happen?") is recommended, because this is the basic idea of MOQARE and my MOQARE experience shows this, too. People love catastrophies and horror stories. They make them creative!
• Jennifer Horkoff and Neil Maiden (City University London) under the title "Creativity and Conceptual Modeling for Requirements Engineering" present a new idea how to support the creative process with an online tool, which can maybe replace a professional workshop moderator. The approach is still in the conceptual phase, but I am looking forwards to the resulting tool and process. I, too, believe that creativity needs process support.
• In our interactive session, we distributed the roundabout 20 participants into 3 groups which each applied another creativity method to the same question: How can we improve an existing RE tool? Finally, these groups solved the following three tasks:
1. Using the morphological box, creative new ideas of tool support for RE were developed, in various unexpected combinations of features an RE tool already has.
2. Applying the Force Fit method which brings together what does not belong to each other, combined Facebook with requirements traceability. In fact, they found lots of similarities and applications, like defining friend relations between requirements and prioritizing requirements by liking them.
3. The 6 Thinking Hats group analysed Visio as an RE tool, and although emotions went in the direction of "I hate it", they identified many advantages of the tool, too. Comparing it with alternative tools, enhancement ideas arose and in the end there were two requirements which were thought worthwhile to be treated further in a subsequent RE workshop, one of them the online collaboration which so far is not supported by this tool.

Transparency International collects data about the dependencies of German Universities on industry financement: https://www.hochschulwatch.de/

I must say that I am not very worried when software engineering research is financed by companies. In these cases, the university serves as a temporary employment agency. It employs young academic personnel and lends them to enterprises. The financial profit is on both sides. The professor and University can prove that they work on topics which are relevant for practice, and that they can aquire funding. The enterprise gets a highly qualified programmer or consultant at half the prize they might pay for an employee. The doctoral "student" works in practice, instead of becoming an expert in some philosophical topic which will make people laugh when he tries to enter work-life after the doctoral thesis. There are only two disadvantages of these arrangements:

1. Basic research loses its value. As companies do not pay for research like "empirical research on cognitive load during programming" or so (topics which I find thrilling), this topic does not sell well in general. For instance, when one applies for a professorship.
2. The scientific value of a doctoral thesis written in a company might suffer from the need to do practical work like programming a software product. Of course, software engineering scientists at universities also develop software, but they most often support a scientifically developed method or help to evaluate some theory. While software developed by doctoral students at companies rather solve practical problems. Of course, they will use scientific research results, but do they also produce scientific knowledge? Of course, it is possible but maybe not the sponsor's first priority.

The problem of research financed by companies probably is worse in medicine, pharmacy or biology where research projects not only produce new products (which is not bad), but also evaluate their usefulness. If they are biased, the damage is higher. In software engineering research, a biased tool evaluation can not do much harm. But a biased evaluation of pesticides or medicine can be fatal.

Disclaimer: My current research is completely unfinanced and therefore independent of financially motivated influence. :-)