Skip to main content

Search...

Why Other Disciplines Build Better Software

Homogeneous teams build products that reflect only one perspective. What this means in practice and how stereotypes within a team can be broken down.

8 min read
Cover for Why Other Disciplines Build Better Software

Diversity in software development means that teams include people from different disciplines—such as design, psychology, or sociology—not just computer scientists. Those who are missing leave gaps: Products reflect the values of those who build them. Interdisciplinary teams make better decisions because they compensate for the blind spots of individual perspectives.

Key Takeaways

  • When a software team consists exclusively of computer scientists, the products they build inevitably reflect only their values and worldview, and important design aspects are missing.
  • Disciplines outside the field—such as psychology, sociology, and design—contribute methods to software development that computer science programs rarely cover, such as user research and ethnographic studies.
  • According to a survey, many female graduates in design, sociology, or psychology are unaware that they could make a concrete contribution to software development.
  • Unconscious thought patterns and privileges exist in every person; raising awareness of them is the first necessary step before methods or structures can take effect.
  • Small teams and agile work methods actively promote collaboration in diverse groups because they structurally prevent hierarchical communication patterns.

Why Diversity in Software Teams Leads to Better Products

Diverse teams develop better software because they incorporate more perspectives into their products. If only one perspective is represented on the team, that very perspective shapes the outcome. This isn’t due to any ill will, but rather an effect that no one can fully control.

People bring their values into the design process. Claudia Nass Bauer illustrates this with a personal example: For her, innovation and creativity are strongly emphasized, while sustainability is less so. In a data-intensive system, she might therefore celebrate a recommendation feature as a cool idea, while the resource consumption of that feature hardly registers for her. If a team consists only of people with similar worldviews, no one will ask whether a more economical alternative might suffice.

This is precisely where diversity comes into play. It brings together values, methods, and experiences that a single discipline cannot cover on its own. And it ensures that less important aspects don’t simply get overlooked in decision-making processes.

What Different Disciplines Bring to Software Development

The benefits of diverse teams are methodologically measurable: people from different academic backgrounds bring different tools to the table. Design teaches different methods than computer science, and sociology and psychology teach yet others. This mix of methods helps ensure that software is designed better.

One specific area where this is evident is user research. Conducting interviews, carrying out ethnographic studies, and surveying real users: these are skills drawn from the social sciences. They are rarely covered in many computer science curricula.

In practice, this work is often done by people who never formally learned it but picked it up on the job. Claudia Nass Bauer poses a clear question on this topic: Who actually does this? The answer is often sobering.

The division of roles is key here. It’s not about computer scientists picking up sociology and design on the side. Piling too many skills onto one person doesn’t work. It’s better to bring people with different areas of expertise together and foster genuine collaboration.

Diversity creates friction, and that’s part of the price

Different perspectives mean more conflicts, not fewer. Someone from a design background wants to approach things differently than someone from computer science, using different methods and different decision-making criteria. That creates friction.

The human instinct runs in the opposite direction. We like to surround ourselves with like-minded people because it speeds things up. Rationally, the benefits of diversity are obvious. In everyday life, however, the thought lingers: “Then I’ll have to discuss everything; there will be different opinions.” This tension is emotional, not logical.

That’s why diversity requires building competence. Communication skills are one aspect. The other is dealing with the unconscious thought patterns that everyone brings with them.

Minorities on the Team Face Particular Pressure

In a heavily male-dominated field, minority groups face additional pressure. A woman who is the only designer on the team and struggles to contribute her own ideas will often look for something else in the medium term. The role of the lone female fighter isn’t sustainable for long.

A specific pattern also emerges in testing. The proportion of women there is comparatively high. Research offers a clue: When things get uncomfortable, men tend to put women forward for these tasks because they’re good at raising and discussing difficult topics. For the team, this is positive in the short term. For the women involved, however, it’s less so if they’re expected to step forward on every sensitive issue while others sit back.

The goal, therefore, is not to pit one group against the other. It’s about organizing collaboration in which the various roles and perspectives truly come into play.

Awareness of Bias and Privilege Is the First Step

The path to a more open team culture begins with awareness, because the crucial processes take place subconsciously. No one is free from bias. Everyone is biased in one way or another.

It’s hard to attribute privilege to oneself. You either have it or you don’t. In our society, being white is a privilege, and so is being a man—a fact that cannot be seriously disputed. Becoming aware of this advantage changes how you act in specific situations.

I already have a few advantages just by virtue of who I am, which I might be able to use—not just for myself, but also to help my team or others who may not enjoy these privileges. Claudia Nass Bauer

The attitude that follows from this is not one of judgment, but of support. Privilege can be used to empower colleagues who do not have it.

This is precisely where the uncomfortable part lies. Using privilege for others can mean giving up or balancing out one’s own advantages. Not every organization and not every person is willing to do this. The idea that a colleague without a degree in computer science has just as much right to make decisions about a product is easy to say but hard to put into practice.

Small Strategies to Break Communication Patterns

Once awareness is established, concrete methods can be implemented to counteract stereotypical thinking in everyday life. None of these methods solves the problem once and for all. They only work if they’re consistently practiced.

Here are a few approaches that work in everyday team life:

  • Assign one person the task of specifically paying attention to when stereotypical statements are made.
  • In meetings and daily stand-ups, each person is given a set amount of speaking time before the main discussion begins, so that everyone has a chance to speak.
  • Use retrospectives not only to discuss features, but also to talk about collaboration: What went well, where did things get stuck, and where does someone need support?

This is based on findings from research on communication systems. In large meetings and in heavily male-dominated groups, hierarchical communication patterns—in which men are well-trained—predominate. In small teams, non-hierarchical patterns are more prevalent, fostering collaboration and inclusion.

This leads to a practical solution: Agile methods with small teams are better suited for diverse collaboration. With five to seven people, hierarchical communication cannot even take root. The small group forces a different approach.

What doesn’t work is letting things slide and hoping that things will just fall into place on their own. A culture that promotes diversity develops over the long term and must be actively maintained.

Why Women Changing Careers Often Don’t Realize Their Potential

Many qualified people from other disciplines simply don’t know that they are needed in software development. The WISE research project, sponsored by Mainz University of Applied Sciences, Fraunhofer IESE, and LMU, conducted questionnaire surveys on this topic. The result: Most female graduates in sociology, design, or psychology hadn’t considered that they could work in software development.

There are two reasons for this. First, the curricula for these subjects are rarely designed to be interdisciplinary. Students delve deeply into their core subject but fail to see where this knowledge can be applied elsewhere. Second, software development is viewed as a highly technical, male-dominated field in which many do not see themselves fitting in from the outset.

The project addresses this gap with two formats:

FormatGoalParticipants
Solar SessionsFemale students demonstrate that their methods from the social sciences are applicable in software developmentFemale students and graduates
Engagement WorkshopsCollaboratively tackle a real-world problem from a company and bring both sides togetherSMEs and recruited female students

The engagement workshops last between two and five days and are facilitated by Fraunhofer IESE as creativity workshops. A company brings a topic—such as an old product that needs to be modernized or an idea for a new service. The female students gain their first experience with just how creative software development can be. The companies get to know potential talent.

Business and Education Must Work Together

Attracting new talent is pointless if these people can’t find jobs afterward. That’s why WISE actively involves companies. Many SMEs still lack an interdisciplinary approach, and the activation workshops specifically bring both sides together.

The need is real. There is a desire for more interdisciplinarity, for more women in software development, and for more diverse teams. And behind this lies the argument that underpins the entire discussion: better products.

For teams, this means taking an honest look at their own composition. Where is only one perspective represented? Which stereotypes have become ingrained? At what point would a different discipline change the discussion? These questions form the first step toward greater diversity.

Share this page