The programming productivity of individuals working in an organisation is affected by a number of factors. Some of the most important of these are summarised in Figure 1. However, individual differences in ability are usually more significant than any of these factors. In an early assessment of productivity, Sackman et al.(Sackman, Erikson et al. 1968) found that some programmers were more than 10 times more productive than others. My experience is that this is still true. Large teams are likely to have a mix of abilities and experience so will have ‘average’ productivity. In small teams, however, overall productivity is mostly dependent on individual aptitudes and abilities.
Software development productivity varies dramatically across application domains and organisations. For large, complex, embedded systems, productivity has been estimated to be as low as 30 LOC/pm. For straightforward, well-understood application systems, written in a language such as Java, it may be as high as 900 LOC/pm. When measured in terms of object points, Boehm et al.(Boehm, Clark et al. 1995) suggest that productivity varies from 4 object points per month to 50 object points per month, depending on the type of application, tool support and developer capability.
Factors affecting individual productivity
| Factor | Description | |
|---|---|---|
| Application domain experience | Knowledge of the application domain is essential for effective software development. Engineers who already understand a domain are likely to be the most productive. | |
| Process quality | The development process used can have a significant effect on productivity. This is covered in Chapter 24. | |
| Project size | The larger a project the more time required for team communications. Less time is available for development so individual productivity is reduced. | |
| Technology support | Good support technology such as CASE tools and configuration management systems can improve productivity. | |
| Working environment | As I discussed in Chapter 22 a quiet working environment with private work areas contributes to improved productivity. |
The problem with measures that rely on the amount produced in a given time period is that they take no account of quality characteristics such as reliability and maintainability. They imply that more always means better. Beck (Beck 2000), in his discussion of extreme programming, makes an excellent point about estimation. If your approach is based on continuous code simplification and improvement, then counting lines of code doesn’t mean much. These measures also do not take into account the possibility of reusing the software produced, using code generators and other tools that help create the software. What we really want to estimate is the cost of deriving a particular system with given functionality, quality, performance, maintainability and so on. This is only indirectly related to tangible measures such as the system size.
References
Beck, K. (2000). extreme Programming explained. Reading, Mass., Addison Wesley Longman.
Boehm, B., B. Clark, et al. (1995). “Cost models for future life cycle processes: COCOMO 2.” Annals of Software Engineering, 1: 57-94.
Sackman, H., W. J. Erikson, et al. (1968). “Exploratory experimentation studies comparing on-line and off line programming performance.”, Comm. ACM. 11(1): 3-11.