8. Factors That Influence Productivity: A Checklist

The list of product factors has seen little change over the past ten years. There are several factors related to size and complexity. Software size usually means the size of the code needed for the software system. Product complexity tries to capture how difficult it is to implement the system with more or less code. In any case, the extent and complexity of the software including its data is a major factor that reduces productivity. Related are also technical dependencies. Newer studies have focused on the dependencies between different software modules or components and how this is reflected in social dependencies in the development team. A high number of dependencies reduces productivity.

A further set of factors that are related are constraints on execution time, main storage constraints, and constraints overall, what we term development flexibility. This could be integrated into a single factor. However, the first two describe more specific real-time and embedded systems, while the latter can also cover other constraints. An example of these constraints might be the use of specific operating systems or database systems or a high number of concurrent users. Additional constraints potentially slow down development.

Furthermore, the requirements on the user interface play an important role. It is a difference if a graphical user interface has to be developed or if the product is a background service. Sophisticated user interfaces typically reduce productivity.

The next product factors are related to quality. The current product quality makes it easier or more complicated to work on the software. Higher requirements on reliability and reusability can increase the effort needed. New publications widen this also to other quality attributes.

Finally, what the organization has done before plays a role: precedentedness describes how similar the project in question is to existing software, and reuse describes how much of the new software can be achieved by reusing existing software (e.g., internal or open source).

The next category of factors are still technical but relate more to the process than the product itself. These factors are related to the project: project length and project type. Longer projects are more difficult to organize but benefit more from rules and custom tools. A more recent study [8] distinguished between development and integration projects. Development projects create most of the software during the project, while integration projects mostly connect and configure existing software. They found that integration projects are more productive.

From the next factors, we see that different development activities have an impact on productivity. Architecture risk resolution is important in architecture design and evolution. The completeness of design before the start of coding impacts how much changes need to be done later. Finally, effective and efficient V&V (verification & validation) describes suitable tests, reviews, and automated analysis. Early prototyping can increase productivity because requirements can be clarified and risks can be resolved. Today, this is often replaced by iterative and incremental development. Such a development probably is able to better deal with volatile requirements, but the completeness of the design during initial coding is low.

Most systems today are not completely stand-alone but rely on specific platforms or hardware. If the platform changes frequently (platform volatility), it creates a lot of adaptation effort. The concurrent development of hardware also means that it is difficult to rely on the hardware and might require adaptation efforts in the software.

The last factors are about the process model and the distribution of the work. A general factor is the process maturity, meaning how well-defined the development process is. In the recent years, research has focused on agile processes and found that they impact productivity. A further aspect of recent studies is outsourcing and global distribution of the project.

In the last category, we group factors that are not part of the product but not directly part of the process either.

A very general factor is the domain of the application to be developed. Embedded software systems, for example, often have specific aspects such as cross-compiling that make development more difficult. Also quite general is the programming language used and the use of modern development practices. The latter includes methods such as continuous integration or automated tests that often come with agile development processes but are not restricted to them. Furthermore, the use of software tools such as modern IDEs or test frameworks impacts productivity. Finally, we also count the match of documentation to environmental factors. In particular, it is important if the documentation fits the needs of the current state of development.

We start with the factors related to the culture of the complete organization. All these factors could also be interesting on the team level, but the culture of a company overall reflects down to the teams as well. Researchers have studied the three factors credibility, fairness, and respect especially on the organizational level.

Credibility is probably the most general factor that describes that communication is open overall in the company and the organization is competent in what it is doing. In our context, this could mean, for example, that there is an understanding on the organizational level of how to plan and run software projects. In fairness, we include equal payment opportunities for all employees and diversity in terms of gender or background in the organization. Respect, finally, means that the organization sees their employees not only as “human resources” but as people; management gives the employees opportunities and trusts them with responsibilities.

There has been considerably more research on the team level than on the corporate level. There can be strong differences between teams in the same company. The higher number of studies brought us eight factors in team culture influencing productivity.

Camaraderie means a social and friendly atmosphere where team members socialize but also help each other. The second factor in this category consists of clear goals that are necessary so that all team members work toward the same objective. Most general is the factor communication that includes the degree as well as the efficiency of information flow inside the team. In general, what is surprising in the studies is that communication effort is positive for productivity. In discussions, we often hear that communication should be reduced to decrease unnecessary work. However, the actual problems seems to be the increase of communication effort when putting more and more people on a project. Yet, a high fraction of effort on communication seems like a good investment.

Psychological safety is similar to camaraderie but more specifically refers to an atmosphere where individual developers can take risks and share personal information, but know that teammates will handle these risks with respect and kindness. This is a factor that more recently came into productivity discussions in the context of software projects because of a large study at Google [14]. Also similar but aiming in a different direction is the sense of eliteness of the team. If the team believes that they are the best engineers always building the highest-quality software, they are more likely to go the extra mile to actually achieve this.

Also related to psychological safety is support for innovation. This contains to some degree safety for taking risks, but it also means that the team members are open to bring in innovations and also change the way they work. Yet another view on this is team cohesion. Team cohesion describes how well all team members are willing to work together. This does not necessarily include a social and friendly atmosphere but a professional approach to working together.

A common team identity also seems to support productivity, probably by influencing other factors such as camaraderie or the sense of eliteness. Finally, the turnover in the team might be influenced by the factors mentioned so far. Team changes could also be ordered by management because of other influences. In any case, less turnover is better for productivity, and it is one of the few factors that we can easily measure.

Besides teams, individual skills and experiences are the most well-studied. We found it notable that although experience is often brought up and is in interviews considered important, in empirical studies it is rather insignificant. By far more interesting is the capability of the developers. Hence, this suggests that being in a profession for a long time does not necessarily make one productive.

Therefore, we have factors for the analyst capability, the manager capability, and the programmer capability. Each refers to the skills of the individuals in their respective roles. For each role, these skill sets will differ, but there is thus far no fixed set of skills necessary for the roles that came out of the studies.

Experience does play a role but more in the sense of the experience with application domains and platforms. We have the three factors of application domain experience, manager application domain experience, and platform experience. The first two refer to how long and with what intensity the developers and managers have worked on software in a specific application domain. The latter refers to the experience of the individuals with a hardware and/or software platform such as the iOS operating system for mobile Apple devices.

Developer personality has been investigated in many empirical studies. Few measure personality according to the state of the art in personality psychology. A more recent study [19] found only one personality trait—conscientiousness—impacted productivity (positively).

Similarly to the study of personalities, another important psychological area has recently been investigated: the emotions of developers. Several studies [16–18] looked at the relationship of happiness of developers and their productivity. They found indeed that happy developers are more productive. You can find more details in Chapter 10.

This category of factors could be seen on the organizational or team level. Yet, as there are five factors, we decided to put them in their own category. They describe the direct work environment of the software engineers.

The e-factor introduced by DeMarco and Lister in Peopleware [3] emphasizes that uninterrupted time for work is important for productivity. Chapter 9 discusses this in more detail, and Chapter 23 shows an idea to improve the e-factor.

Although we have not found studies focusing specifically on software engineering teams, there are several studies on office layout that should apply in our context. In software companies, we frequently see open-plan offices with the reasoning that interaction between team members is important. A recent large study [22] found no evidence that this is actually the case. Instead, interruptions are much higher; hence, the e-factor becomes worse in open-plan offices.

Distributed development of software, meaning software teams physically distributed over several locations in potentially several different time zones, is common today. There is a considerable body of work on the potential problems with this working mode. It can have a negative effect on productivity.

Also, the workplace itself has an effect on productivity. There are studies investigating aspects such as if there are windows and natural light or the size of the room and space on a desk. Time fragmentation is related to the e-factor but covers more the aspect of how many different projects and kinds of tasks you have to work on. This results in costly context switches that could be avoided if you could focus on a single project.

Finally, proper telecommunication facilities are important so that you can work from home, work efficiently part-time, or interact efficiently with other team members who are in another physical location.

Finally, there are factors related to the individual project that are not technical in the sense that they come from the technology or programming language. Instead, the people associated with the project influence them.

There are many studies looking into the relationship of team size and productivity. It is well established that larger teams lead to exponentially increasing communication efforts that, in turn, lead to lower productivity. Newer, agile software development processes therefore often recommend team sizes of about seven.

Also, the requirements stability over a project has been the subject of several studies. Highly unstable requirements lead to time, effort, and budget overruns; overall demotivation; decreased efficiency; and the need for post-implementation [20]. Again, agile development processes focus on this problem by reducing development cycles to a few weeks.

Finally, the planned project schedule needs to fit the actual work to be done. Several studies show that schedules that are too tight in effect reduce the productivity.