The Human Factor in Software Engineering

When I was 14, I was a freak because I sometimes spent some hours in front of a computer screen writing computer programs, designing stationary and writing letters. Today, this is normal work.

When I was 25, I was a freak because I met new people online in chat rooms and also met them at chatter parties. We had fun, but we were freaks.

Nowadays, people stare at a computer screen day and night, first thing in the morning, last thing before they sleep. While they walk or eat or talk, they are reading or typing. They tell strangers their sexual preferences or publish family videos. But it is not considered to be freaky. Now, it is freaky to be away from computer and internet for a few hours.

And people not even realize how they changed so completely.

The Implicit Social Attitude tests can measure your attitudes, not based on your self-judgement, which usually is strongly biased. Instead, the test principle is based on measuring how fast you answer to questions. When you are biased, you can answer some questions faster than others. Here, you find the test about gender bias. Further such tests are available here.

Currently, I am doing research about the history of software development process models and while going through the archives, I found this very beautiful analogy about software engineering:

"The third reason that we keep seeing missed schedules was pointed out to me by the editor of one of our best computing journals, who says he has concluded that producing large computer programs is like raising a family. You ean observe your neighbors and see all of the successes and failures in their children. You can reflect on the experiences you had as one member of a large family. You can observe all the proper maxims of life and society. You can even study at length the experiences of many others who have raised families. In the final analysis, however, you have to start out and do it on your own, learn the unique options you have, see what unexpected problems arise, and, with reasonable luck, perform about as well as those who have been doing it forever."

source: H.D. Benington: Production of Large Computer Programs. Proc. ONR Symp. Advanced Programming Methods for DigitalComputers, June 1956, pp. 15-27.

So, software engineering must be learned by doing!

When reading technical literature and information about new technological products and software, I more and more have the impression that all usefull applications have already been developed. For my daily life and work, I do not need additional software and not even additional functionality for my current software. The only improvements that make sense are better quality, security and privacy. For some applications, I would even vote to deleting some functionality in order to improve quality.

In the production domain, more automatization leads to better efficiency, but one day we reach the point where everything that can be automatized already is.

Then, we could relax, but something is driving is to innovation and growth. Financial need or psychological disease??

As a generalist, I have been working in different domains and jobs so far, and I am again and again shocked about how chaotic software is developed. Software development, that is so expensive and success-critical, is developed somehow ad hoc. Often, this is because the programmers are either asocial divas who do not accept any orders from others (that´s what they call the requirements), or autists who can not integrate in a team or egocentrics who do not want to integrate into a team because then their own merits are not well visible. And the good programmers know they can decide how they work because they are indispensable. In other domains, where people are more easily replaced, the pressure to keep to standards and deadlines is much higher.

When I was young, I believed the prejudice that work flows and creativity contradict each other. Standards kill creativity etc etc. But this is not true. Working systematically is a well-known strategy used by successful, productive bestseller authors. Literature magazines, bus timetables, each publication of a club or political party is written with more care than some critical software. And a lot of work is for the dustbin because requirements were not defined in advance or the requirements were wrong. Standards help us to get the real and complete requirements early-on and to be productive and reliable. Currently, I am participating at a work flow of the EU for assessing research project proposals. It is organized like a production chain, but it is OK. I know exactly what to do when, and I know that my results will be used, nothing is for the dustbin. Although the form of the work is like a work chain, the content is highly intellectual, and this is no contradiction.

My own office and work is well-organized (time management!) and it is good to know at any time and any place what the most important work to be done is right now and here. This helps me to concentrate on the content, not on the organization. When you work in chaos, you are always searching for something, you make sub-optimal decisions and most of your work will not lead to a useful result. It might be painful at first to keep to rules and work flows, but it soon becomes a routine.

No, I have not disappeared, I just was elsewhere. I had a crazy winter, travelling around Europe like an opera star. :-)

Recently, I wrote a guest blog article for the Microtool blog with the title: "Inspection as the Path to Good Specifications". If you like, you can join our discussion there about sense and nonsense of requirements inspections.

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?