Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News The Role of Emotions in Software Engineering

The Role of Emotions in Software Engineering

This item in japanese


A recent study by the Carlos III University of Madrid (UC3M) investigates the importance of emotions in software engineering. In the study requirements engineering is considered. There is a good reason for this specific focus. As Ricarda Colomo from the UC3M mentions,

In the world of computer system development consultants, I have often met disappointed users whose unhappiness was produced by a deficient collection of requirements.

The scientists have applied a tool of social psychology, the affect grid invented by J. A. Russel. As the authors of the studies explain,

This instrument provides emotional outlines for different versions of the requirements, in addition to facilitating an analysis of the emotions of those involved in the development of the system.

The results of the study show that emotions need special consideration when negotiating and establishing requirements.

In the press release it is pointed out that previous studies have also shown the impoirtance of emotions in software enginering such as the finding that

listening to music improves the performance of some systems analysts.

The human factor seems to be widely underestimated in software engineering. Eventually, humans create software systems that are used by humans.

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • How ironic

    by Rick Verdonschot,

    • How ironic

      by Rick Verdonschot,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      I was a software developer and I did see the big picture and I warned the project leader that certain functional decisions would lead to unhappy customers (everybody hates slooooooow software, right?). I was told not too look at the big picture but instead focus on the technical details.
      2 years later: Software went slow -> Unhappy customers, project leader made sure he was gone before SHTF and then I am the one who gets pushed under pressure to fix the problem. And then this human factor unit crashed...burnout...

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p