Unfortunately, the expert who has grasped all aspects of a domain and can describe them is rarely the one who can develop the software himself. On the other hand, the software developer is not necessarily able to decide for himself whether the domain is correctly reflected in code. In order to solve a real world problem with software, both sides are therefore absolutely dependent on each other if they want to achieve suitable results.
It is therefore advisable to establish a model of cooperation that has been practiced in this form in research and science for a long time: working in interdisciplinary teams. Scientific research is a division of labor that, like software development, results in specialization. However, reality which wants to be reflected by both – scientific research and software development – is in contrast multilayered and complex. Problems of the real world rarely keep to disciplinary boundaries. However, the resulting questions can usually not only be answered comprehensively from a single point of view, which is why cooperation between the disciplines is absolutely essential.
Subject-specific instead of technical teams
If there is a consensus that software should be developed in a collaborative, interdisciplinary process, it is necessary to choose subject-specific rather than technical teams. Their constellation depends on the concrete requirements of the particular project, but it's nevertheless possible to identify areas that should be represented in such a team in a reasonable way:
- Domain: It is essential to have one or more business experts in the team for the domain to be developed. Only they can decide in the last instance whether processes are mapped correctly or not. A positive side-effect of involving business experts in the development process is that they learn to read code over time, enabling them to better evaluate whether domains are correctly reflected.
- Development: The development of software obviously requires developers. Backend and frontend developers are just as relevant here as experts for DevOps and data processing or hardware engineers.
- Design: An application should also be designed with an appealing user interface that should be intuitive to use. Here the team needs experts for UI/UX design in order to provide the user with an optimal user experience. The more the designers understand the domain to be captured, the more suitable surfaces they can design.
- Optional areas: It would be desirable, although not absolutely necessary, to involve editors and marketing experts in the work of an interdisciplinary team as early as possible. For example, editors are of enormous relevance where results and procedures need to be documented. Marketing experts will find easier access to a product to be marketed if they are involved in the development process right from the start. This enables them to tailor marketing strategies more appropriately to products and develop more successful campaigns.
In addition, the decision in favour of subject-specific teams has the advantage that all business units relevant to the particular project are involved in the entire process right from the start. In the case of problems or even failure, this means that there can be no fingerpointing on a certain department. They all contribute equally to the success of a project, and only together the goal can be achieved.
Model first, implement second
The process in which software is developed has significantly evolved over the last few years through agile methods such as Scrum. Particularly where the concrete architecture of a project, its implementation and the associated unit tests are concerned, short iterations with regular feedback loops make work much more efficient.Unfortunately, however, this knowledge isn't yet applied enough to the surrounding areas, so that no holistic process can be created. The requirement specifications are often still drawn up at the beginning of a project and then pulled out of a drawer for acceptance. Is it - in retrospect - really so surprising that the implementation in most cases did not produce the things that were actually needed or expected? What follows are lengthy discussions and expensive rework.
If, from the very beginning, interdisciplinary teams are put in place in which the experts constantly keep an eye on the correctness of the domain to be implemented, this does not initially lead to less or less complex communication. However, since all these discussions take place before and during implementation, you never lose sight of the real domain. Here too, feedback loops should be used in short iterations. In this way, one avoids presenting something completely different during final acceptance than what was originally stated in the requirement specifications.
Before the first line of code can be written, it makes sense to model the domain to be implemented in software. For this, a team can apply simple logical if/then designs that capture the processes of the software to be developed or use proven methods such as domain-driven design (DDD). No matter which way a team chooses to go, because of the fact that communication comes first and implementation follows, many problems can be avoided, so that misunderstandings cannot arise in the first place.
Communication, especially when it goes beyond disciplinary boundaries, isn't a pleasant idea for many developers. Explaining rudimentary database concepts to non-technicians, for example, often seems to be extremely pointless and is perceived as a waste of time. This feeling corresponds to reality, because the communication that an interdisciplinary team needs at the beginning of a project is not a technical one: the team has to learn to conduct the discussion on a purely subject-specific level in such a way that everyone is participating - including the developers. In order to achieve this, a few principles of conduct within interdisciplinary teams make sense.
1. Be respectful and empathetic!
Each team member has valuable knowledge and skills needed to lead the project to success. These should therefore be appreciated by everyone. Only in an atmosphere of mutual respect can everyone find their best performance and thus contribute to the success of the project.
It is at least as important to develop a good feeling about whether all team members feel understood in their specific areas and whether they can keep up with each other in gaining knowledge. The team can only fulfil its task comprehensively as a unit.
2. There are no stupid questions!
This old saying from school days is still valid. Different approaches from different points of view raise various questions which, however, all have the same raison d' être.
It is essential that everyone in an interdisciplinary team can see the subject matter of their work through the eyes of the other team members and their professional glasses. But be aware, there are limitations here: the designer does not have to understand all decisions of the backend developer, and the domain expert does not have to be involved in the technological choices of the UI/UX designer.
3. Find a common subject-specific language!
Once an interdisciplinary team has agreed on all facets of the common subject matter, a common language will be developed, which will flow into the code as a basis. Every member of the team, whether domain expert or designer, will be able to read the functional aspects of the code over time and decide whether the domain has been correctly captured.
4. Do not strive for perfectionism!
If you approach the domain to be implemented by modelling, you should not make the mistake of expecting a perfect result in the first attempt. Modeling works best in short iterations, with a high willingness to fail and restart. Discarding a model of a domain before it is written in code is much less costly than the customer denying approval of the finished implementation.
The process of software development in an interdisciplinary team directs the focus away from the technical to the subject-specific side of an implementation and requires an increased willingness to communicate. If cooperation is to be successful beyond the disciplinary boundaries, all team members must meet certain prerequisites. In addition, there must also be a willingness to accept the peculiarities of other members.
Developers will certainly find it difficult to not always think in database schemas at the beginning of their work in such a team, and designers will probably find it difficult to not immediately think in terms of images and UIs. It may therefore make sense to complement the staffing of an interdisciplinary team with the role of a moderator - at least at the beginning of the collaboration.
From time to time it makes sense that an outsider reminds the parties involved to move the focus away from the respective technical point of view to the subject-specific one. If an interdisciplinary team has already grown together through the cooperation in a number of projects and has learnt the new behaviours and patterns of thought, this role of moderation is no longer necessary.
Better communication = better software
In summary, it can be said that working in an interdisciplinary team is by no means a self-perpetuating process that automatically leads to better results. New ways of working and behaving must first be accepted and implemented before the first successes can be achieved.
The willingness and the ability to talk more to each other is central here: Only through better communication between all parties involved better software can be created. Interdisciplinary teams are the ideal breeding ground for this, as abilities and skills from different areas unite to achieve a common goal.