Coding in teams
The guidelines for bioinformaticians offer few suggestions on teamwork, and most encourage reaching out to others when one encounters a problem. On the other hand, in software-heavy endeavors, coding in teams is the norm. Here, we examine the specialized software engineering literature, which examines how to organize team coding activities effectively.
Indeed, programming as a collective practice is a critical notion in software engineering. Maximizing team cohesion while minimizing code coupling represents a central theme (10.1287/mnsc.1080.0921). The overall performance increases when team members are familiar with each other and together build problem-solving routines through cumulative experience (10.1287/mnsc.1080.0921). From a code writing perspective, adopting sound software design enforcing modularity and extensibility ensures the viability of a software project.From a software development perspective, one should prefer team management practices centered around communication and collective governance (Weinberg G. M., The Psychology of Computer Programming: Silver Anniversary Edition). Knowing who knows what speeds up problem-solving (10.1177/1046496420967764); time spent together and social factors ease technical knowledge transfer (10.1287/mnsc.1080.0921).
We generally understand management as performing specific tasks: planning, monitoring resources, and tracking progression (wrike.com). Typically, a single individual, referred to as the “manager" of the project, takes on these functions. In this context, manager is a role rather than a particular person's title. When considering software project management, a strict division of labor is rarely found in the specific context of academic computational projects. Some tasks, such as risk assessment, budget, and time management, are discussed at the project's conception (e.g., during grant application) and thus decoupled from the actual software development phase. The remaining management tasks would often fall on the developer(s). Implicit decision-making is one of the critical challenges current bioinformatics projects face.
As agile code development is the primary recommendation for team management in the guidelines shown in the A review on software development practices in bioinformatics section, its relevance to academic settings is worth discussing. Agile methodologies, which emphasize iterative development, regular feedback, and flexibility, could significantly improve how teams handle the evolving demands and rapid changes typical in academic computational projects. Practices and methods aligned with agile prescriptions include planning a minimum viable product, documenting requirements, organizing stand-up meetings, defining and assigning tasks, pair programming, and code reviews. Many of these practices do not require the manager's presence but assume efficient and frequent communication within a team, a collegial work culture, and standardized procedures. The additional overhead in terms of time and resources needed when developing is offset by the benefits mentioned above regarding software resilience and improved team capabilities.
Incentivizing software projects with multiple authors promotes the adoption of best practices in software engineering among developers contributing to the project (10.1016/j.infsof.2009.11.004). Indeed, by aspiring to make any developer within the team interchangeable across the various ongoing tasks, software teams create an environment for robust testing, comprehensive documentation, and coherence across the project's different parts (10.1287/mnsc.1080.0921). Furthermore, exposing every developer to various tasks throughout the project development strengthens the knowledge and skill base of the team as a whole. It creates an improved mutual awareness of each team member's expertise. This mutual awareness, which can be thought of as a transactive memory system, is linked to increased team performance (10.1177/1046496420967764). These merits further improve the team's capacity to overcome technical challenges that will likely arise during software development.
As the academic research environment and expected project outcomes (papers, tools, protocols, etc.) are significantly different from the environment and outcomes in the software industry, the guidelines defined by the industry need to be adjusted. A key difference is that the academic system encourages crediting individual researchers to aid their career progression. One adaptation we propose is that interactions between developers can happen even when they work on distinct projects, as these interactions will ensure compliance with the standards and increase software quality.
In our research groups, we implemented an environment in which we, as a group, learn about and implement the software quality practices discussed above. The process of improving software quality can be visualized as rock climbing, with the top of the rock representing our goal of good quality software (figure below). To reach this goal, one needs to become proficient in the various concepts depicted by the holds. These concepts are selected from the literature and our professional experience but are not exhaustive, and each group can tailor them to their specific needs. The higher they are on the wall, the more advanced we consider the concepts to be. As the progress is cumulative, we show the holds representing related concepts that build upon each other in the same color. This way, we mimic traditional computer science education. The order of visiting the topics can vary between groups, but reiterating certain core concepts (e.g., modularization and testing) is highly valuable. Nevertheless, the most crucial point is that rock climbing requires a partner to belay you, just as we believe that other people's input helps us become better programmers.
