The question in the title of this section may be answered in different ways:

The advantages of a better understanding (and acting based using the knowledge gained) usually result in many improvements. So, if a person participates in production of software of high quality, then he is motivated by the work he does and puts all the creativity and energy into his work (productivity is increased) and it is less probable that he will leave the firm because there are few firms offering high-quality products and because his job-related self-satisfaction is maximised (turnover reduction).

Therefore the results of application of brain to social aspects of software development may yield results which can be described as

{Quality} È {Productivity} È {Turnover reduction}

To understand the problem of people in software development projects it may be helpful to examine the characteristic properties of the craft of programming. According to Brooks there are several joys of programming:

• Joy of making things, particularly of things of one’s own design
• Pleasure of making things that are useful to other people
• Fascination of fashioning complex puzzle-like objects of interlocking moving parts and watching them work in subtle cycles, playing out the consequences of principles built in from the beginning
• Delight of working in very tractable medium which resembles pure thought-stuff, comparable to the medium the poet works with

To my opinion the list omits one of the strongest sources of self-satisfaction of a good programmer, namely the solution of sophisticated problems. They occur relatively infrequently and usually require a high amount of concentration, communication abilities and broad technical knowledge.

Another joy of programming is a possibility to experiment with new functionality of some system. Often experimenting is the most efficient way to learn a new programming language. Like children playing with LEGO bricks, programmers play with functions, classes and interfaces.

The comparison of programming to poetry may seem inappropriate to person who never has programmed but programmers who work for a long time with a certain programming language or hardware platform develop an emotional relationship to it. That results in searching for solutions, which are most elegant with respect to that language. One experiences an enormous pleasure in creating code that performs complex tasks, yet works properly and looks quite simple, which is hard to describe with words…

On the other side this relationship results in a number of negative consequences, namely

• one can spend hours in discussing superficial issues of programming (see figure 1)
• one can create working, elegant and well-designed implementations of algorithms comprehensible only by programmers of the same (very high) ability
• one can have prejudices to other programming languages (and programmers using them, e. g. COBOL) and deny their usefulness for some tasks (aversion of many C/C++ programmer towards Microsoft Visual Basic or religious wars between "Linuxoids" and fans of Microsoft products)
• one can consider criticism of a programming language a personal offence

However, in practice some of the joys may not be present. One often has to create things of other person’s design, which may contradict with one’s own point of view. To my opinion, the view of a software product depends on the role of the viewer in the project. Programmer may look at the efficiency and elegance of the algorithms, designer at the ease of integration of other components into the system, manager at adherence to deadlines. Thus, not all wishes (of rational or emotional nature) of the programmer can be fulfilled.

The joy of making things, which are useful for other people, is obviously not present if the product developed is not used for some non-technical reason. That is the fate of many information systems in enterprise Intranets. The success of them depends to a higher degree on organisational or administrative cleverness than on technical implementation. A perfectly programmed Intranet forum on quality assurance is not useful to anybody if the articles to be found therein date back some months because nobody is interested in that topic.

Brooks mentions following negative aspects of programming

• One must perform perfectly. The computer resembles the magic of legend in this respect. If one character, one pause, of the incantation is not strictly in proper form, the magic doesn’t work. Brooks states that this is the most difficult part of learning to program.
• Other people set one’s objectives, provides one’s resources and furnish one’s information
• Dependence upon works of other people
• Hard work of debugging

• The programming project converges more slowly the nearer one gets to the end (the last difficult bug is harder to find than the first)

I don’t agree with Brooks that perfection is the most difficult part of learning to program. I think this statement was right at times, which Brooks’ book relates to, but is obsolete now, because

• high-level programming languages do not demand perfection from programmer in that syntax errors are discovered and displayed automatically
• semantic errors can be detected more quickly since the compilation time is in most cases relatively low

To my opinion, the most difficult part of learning to program is the ability to generate not programs but tested products with useful comments, sufficient documentation and overall high quality.

The dependence upon other people is given by the fact that most systems interact with other system and/or must model processes of organisations, which often are not logical or comprehensible to the programmer.

Debugging is hard not only because of technical complexity of software systems, but also because of the obvious inability of programmers to regard their programs as programs and not as their brainchildren (which one doesn’t want to hurt). In fact, the practice shows that many programmers are not able to test their programs carefully so other persons must perform testing. This problem can also be diminished by collective code ownership where the code is declared to be property of all programmers and not only of the author. That often improves the ability to criticise and willingness to accept criticism.

One woe omitted by Brooks is the need to document one’s works and keep the documentation complete and up-to-date. In practice one is often forced to make a quick, little change to the program. If one does not have enough time (as it usually is), the change remains undocumented. The only solution for this problem known to me are automated documentation tools, which generate documentation from comments in the program (such as javadoc for Java). In this case, the documentation effort is small enough (one just has to write some text in the comments of the source code and run the documentation generation program).

Writing maintenance manuals is also an inconvenient task. My personal experience is that I am much more productive in writing programs than in documenting them.

Documentation needs to be comprehensible by people whose skill level and mental ability is not known in advance, so the documentation must be written in a very clear manner. On the other side, different people learn differently.

Someone prefers a detailed explanation of principles of work of the program (e. g. by reading a book on databases) described, other persons learn better from examples (e. g. by typing in SQL statements and looking what happens).

Other issue is the presentation of information. In the craft of programming diagrams are widely used and can substitute dozens of pages (e. g. an entity-relationship diagram). The problem arises if one wants to describe a fact by a non-standardised diagram. How can one assure that the reader understands the diagram properly?

As can be seen from this text, the nature of programming is far more complex than just generating some source code.

The ethics of programming may seem inappropriate since most of us are not working in nuclear power plants or developing software for defence organisations where an error of a programmer may have severe consequences or the very fact of working therein may be a "moral acrobatics". However, most programmer are faced with issues which are to more or less extent ethical issues (this is of course a partial list):

• confidentiality and accurate dealing with personal data of other persons
• careful dealing with sensitive customer/employer information
• legality
• making customer/employer aware of problems which cannot be solved by software and providing hints to mismanagement in his processes
• carefulness in communication with the customer or employer

Many programmers get access to databases containing huge amount of personal data due to the requirements of their profession. It is obvious that one should deal with that data carefully. It means not only to not use it in an improper way intentionally, but also to prevent the misuse of data by accident. That could mean for example:

• not printing out and leaving unobserved the database entries
• "lock" the computer when leaving it unobserved such that one only can use it again by entering a password

The second point of the list concerns passwords and login-names of the computers the programmer is working on. They may be a source of great danger if treated carelessly (e. g. using short passwords, speaking them out in presence of other people, writing them down etc).

The legality issue is the most painful one. Almost every person dealing with computers is to more or less extent a criminal – computers with no pirate copies of standard software are seldom. To my opinion the solution for this problem lies in the usage of freely available software that satisfies the needs of private users. The reality looks quite different, instead of acquiring free software or buying commercial, one simply "cracks" the security mechanisms of pirate software.

While developing a concept of the program to be created, software engineers need to analyse the business processes of the customer. In some cases, one detects failures, which arise from the organisation of them and cannot be solved just by automating them. In some cases, a complete automation may even be more a hindrance than a benefit since overautomatisation can make a system "non-self-healing" (DeMarco, Lister 1991). The customer should be notified of such discoveries.

The principle of non-deception of the customer can only be implemented in practice if one pays attention to proper communication with him, avoiding technical terms or thought constructs, which may be incomprehensible for him.

The role of ethics in the software industry will become more obvious in future, when computers will influence our lives in an even more intense way they do today. But the potential importance of ethics (lack of it) can be demonstrated on some examples from the past and present:

• In a globalised world, it may become difficult to distinguish ethical from non-ethical tasks. For example, some Austrian telecommunication firms supplied the Indonesian police in mid-1990s with communication equipment. As is widely known, Indonesian police played a remarkable role in dissolution of demonstrations against the Suharto regime at that time. Is it now ethical to help the enterprises supply undemocratic regimes with technology they use for fighting against their own people or not?
• Data mining is a technology for the analysis of data stored in large databases. It is sometimes used for the analysis of customer behaviour (e. g. "if customer XYZ uses to buy a new car every three years and bought the last one two years ago, it is time to send him our new catalogue"). Nowadays, some experts state that personal data of an average Austrian are stored in 300 databases. It is not impossible that some day, one will be able to analyse the data stored in different big databases. That would open excellent marketing opportunities. Is it now ethical to support such efforts with one’s brain’s power?
• This year, a pilot project was started at the "Higher Technical School for EDP and Textile Industry" aiming at getting first experiences with computerisation of pupils’ data. In the long term, all data of Austrian pupils should be stored in a central database in an easily analysable form. Do software engineers have a notion of ethics at all?

People management in the IT deals with following issues (partial list):

• Exploiting people’s inherent creativity
• Increasing their productivity
• Acquiring and keeping able people
• Motivating people

In order to reach that some measures have to be taken and some others not:

Tom DeMarco and Timothy Lister claim that their research results show a significant correlation between the productivity of programmers and their working conditions such as

• structure of the office
• amount of disturbances during the usual work time

Open-plan offices are big offices where many (more than four) persons are working. Usually, there is little or no separation between the areas of different workers. Personal offices are the privilege of managers.

The other alternative are rooms with no more than four persons working therein, one or more windows (the window issue is a contradictory one – on the one side one often wants to look at something different from source code, on the other side window can cause glare on monitor or glasses of the programmer (INET2001101702)) and a door.

This alternative offers several benefits:

• The noise level is lower since there are only four persons in the room
• Workers have private spheres (i.e. they have places to work alone)
• The work place can be adapted to reflect the individuality of the worker
• The door can be closed and create an atmosphere of silence necessary for performing complex intellectual work
• Windows let the light in and provides natural lighting preferred by most people

If the project is planned to last for many months, the persons working on it can be located to adjacent rooms. There are two main objectives of project-oriented office design: to provide a place for individual and that for group work. McCue (1978) proposes following scheme:

Such an office provides private as well as group workplaces and room for informal communication ("Communal area"). Informal communication plays an important role since it provides an opportunity for exchange of experiences and specialist information (for example the usage of a sophisticated programming library).

The open-plan approach is used very often (at least in USA), although it is neither popular among the workers nor productive. The main advantage of open-plan offices is the ease of wiring the computers and phones as well as cheapness. The productivity increase by putting the workers into offices designed for humans is scientifically proven (for example by McCue). However, the working environment discussed here is often not possible in practice because the increase of productivity doesn’t outweigh the argument of higher costs. Costs are easily measurable, productivity is not.

Since many activities in the IT branch are intellectual ones, their execution requires a certain degree of concentration. Concentrating requires a certain amount of time, after which one can work properly and put all the intellectual power into solving a certain problem. If a person is disturbed, the concentration process must start from the beginning. If a person is disturbed very often, productive work is not possible at all.

There are three major disturbance factors: noise, phone calls and other persons.

Noise is present if people work in open-plan offices or are not able to isolate themselves by the means of a door. To my opinion, in open-plan offices the noise is per definitionem high (the more people are in an office, the more they talk with each other) and often unbearable.

As already mentioned above, the means for prevention of disturbance by noise is the use of smaller rooms.

Phone calls also undermine the concentration. Nowadays, most enterprise phone systems have the option of call redirection and turning the telephone off. If these options are used or not is subject to the firm culture. Other possibility for avoiding the disturbance is the use of electronic mail since in this case one can answer a message when one has time for doing so. To my personal opinion, efficient use of electronic mail requires a certain degree of maturity and understanding that an e-mail is of no little importance than a phone call.

The way e-mail is used is part of the enterprise culture.

However, one should never forget that e-mail is not suitable for communication with more than one person if an immediate answer is important or it is important that a certain question is not ignored. Video and phone conferences as well as instant messaging systems provide such possibilities, but require again a certain discipline from participants. Efficient communication is not achieved by chance but has to be cultivated.

Last major source of disturbance is other people asking for help or demanding some tasks to be done. Contrary to the previous two points, there is no definitive means of attacking this problem but developing a culture, which respects the needs of other workers. DeMarco and Lister (1991) suggest placing little flags on the tables of persons who currently are working on a complex task and do not want to be disturbed. This method only can work if everybody knows of that "custom" and respects it.