Programming productivity

Programming productivity (also called software productivity or development productivity) describes the degree of the ability of individual programmers or development teams to build and evolve software systems. Productivity traditionally refers to the ratio between the quantity of software produced and the cost spent for it. Here the delicacy lies in finding a reasonable way to define software quantity.

Productivity is an important topic investigated in disciplines as various as manufacturing, organizational psychology, industrial engineering, strategic management, finance, accounting, marketing and economics. Levels of analysis include the individual, the group, divisional, organizational and national levels.^[1] Due to this diversity, there is no clear-cut definition of productivity and its influencing factors, although research has been conducted for more than a century. Like in software engineering, this lack of common agreement on what actually constitutes productivity, is perceived as a major obstacle for a substantiated discussion of productivity.^[2] The following definitions describe the best consensus on the terminology.^[3]

While there is no commonly agreed on definition of productivity, there appears to be an agreement that productivity describes the ratio between output and input:

Productivity = Output / Input

However, across the various disciplines different notions and, particularly, different measurement units for input and output can be found. The manufacturing industry typically uses a straightforward relation between the number of units produced and the number of units consumed.^[4] Non-manufacturing industries usually use man-hours or similar units to enable comparison between outputs and inputs.

One basic agreement is that the meaning of productivity and the means for measuring it vary depending on what context is under evaluation. In a manufacturing company the possible contexts are:^[3]

• the individual machine or manufacturing system;
• the manufacturing function, for example assembly;
• the manufacturing process for a single product or group of related products;
• the factory; and
• the company's entire factory system

As long classical production processes are considered a straightforward metric of productivity is simple: how many units of a product of specified quality is produced by which costs. For intellectual work, productivity is much trickier. How do we measure the productivity of authors, scientists, or engineers? Due to the rising importance of knowledge work (as opposed to manual work),^[5] many researchers tried to develop productivity measurement means that can be applied in a non-manufacturing context. It is commonly agreed that the nature of knowledge work fundamentally differs from manual work and, hence, factors besides the simple output/input ratio need to be taken into account, e.g. quality, timeliness, autonomy, project success, customer satisfaction and innovation. However, the research communities in neither discipline have been able to establish broadly applicable and accepted means for productivity measurement yet.^[1] The same holds for more specific area of programming productivity.

Profitability and performance are closely linked and are, in fact, often confused. However, as profitability is usually defined as the ratio between revenue and cost

Profitability = Revenue / Cost

It has a wider scope than performance, i.e. the number of factors that influence profitability is greater than the number of factors than influence productivity. Particularly, profitability can change without any change to the productivity, e.g. due to external conditions like cost or price inflation. Besides that, the interdependency between productivity and profitability is usually delayed, i.e. gains in productivity are rarely reflected in immediate profitability gains are more likely realized on the long-term.

The term performance is even broader than productivity and profitability and covers a plethora of factors that influence a company's success. Hence, well-known performance controlling instruments like the Balanced Scorecard do include productivity as a factor that is central but not unique. Other relevant factors are e.g. the customers’ or stakeholders’ perception of the company.

Efficiency and effectiveness are terms that provide further confusion as they themselves are often mixed up and, additionally, efficiency is often confused with productivity. The difference between efficiency and effectiveness is usually explained informally as efficiency is doing things right and effectiveness is doing the right things. While there are numerous other definitions,^[3] there is a certain agreement that efficiency refers to the utilisation of resources and mainly influences the required input of the productivity ratio. Effectiveness on the other hand mainly influences the output of the productivity ratio as it usually has direct consequences for the customer. Effectiveness can be defined as "the ability to reach a desired output".

Generally, it is assumed, that efficiency can be quantified, e.g. by utilization rates, considerably more easily than effectiveness.

Tangen states: "Improvements in quality, other than the fact that no-fault products add to output levels, ought not to be included in the concept of productivity."^[3] However, most of the classic literature in non-software disciplines, especially in the manufacturing area, does not explicitly discuss the role of quality of the output in the productivity ratio.^[6] More recent works from non-manufacturing disciplines have a stronger focus on knowledge, office or white-collar work and hence increasingly discuss the role of quality with respect to quality.^{[5][1][7][8][9]}

Drucker stresses the importance of quality for the evaluation of knowledge worker productivity: "Productivity of knowledge work therefore has to aim first at obtaining quality—and not minimum quality but optimum if not maximum quality. Only then can one ask: "What is the volume, the quantity of work?""^[5]

Saari captures the importance of quality with his extended formula for productivity:^[8]

Total productivity = (Output quality and quantity)/(Input quality and quantity)

However, it appears that these efforts to include the quality in the determination of productivity did not lead to an operationalizable concept yet. It currently remains unclear how to quantify the vague terms “Output quality and quantity” as well as “Input quality and quantity”, let alone to calculate the ratio.

In software development things are more complicated than in the production of goods. Software development is an engineering process.

Boehm was one of the first researchers that systematically approached the field of software productivity. His cost estimation model COCOMO - now COCOMO II^[10] - is standard software engineering knowledge. In this model, he defines a set of factors that influence productivity, such as the required reliability or the capability of the analysts. These factors have been widely reused in other similar productivity approaches. The rest of the model is based on function points and finally source lines of code (LOC). The limitations of LOC as a productivity measure are well-known.

Jones is the author of a series of books on software productivity. Besides several theoretical considerations his main contribution is the systematic provision and integration of a large amount of data relevant for productivity analyses. In at least two of his books,^[11][12] he gives a number of productivity factors but also points out that for each project a different set of factors are influential. These factors can form a basis for productivity assessments and for comparison with industrial averages.

This is one such list:

The 20 factors whose quantified impacts on software projects have been determined from historical data are the following:

• Programming language used
• Program size
• The experience of programmers and design personnel
• The novelty of requirements
• The complexity of the program and its data
• The use of structured programming methods
• Program class or the distribution method
• Program type of the application area
• Tools and environmental conditions
• Enhancing existing programs or systems
• Maintaining existing programs or systems
• Reusing existing modules and standard designs
• Program generators
• Fourth-generation languages
• Geographic separation of development locations
• Defect potentials and removal methods
• Existing documentation
• Prototyping before main development begins
• Project teams and organization structures
• Morale and compensation of staff^[12]

Function points were proposed in 1977 by Albrecht as a better size measure for software than LOC. In that it is based on the specification of the software and thereby aims at measuring the size of its functionality rather than the code itself. The reason is that the size of the code not only depends on the size of the functionality but also on the capability of the programmer: better programmers will produce less code for the same functionality. The function points have undergone several redesigns over the years mainly driven by the International Function Point User Group (IFPUG). This group is large with over 1200 companies as member which shows the rather strong acceptance of this measure. However, in many domains it still lacks practical application because it is often conceived as only applicable to business information systems.

Several researchers proposed economic-driven or value-based software engineering as an important paradigm in future software engineering research. Boehm and Huang point out that is it not only important to track the costs in a software project but also the real earned value, i.e. the value for the customer.^[13] They explain that it is important to create the software business case and keep it up to date. In essence, value-based software engineering focuses on the customer value, mainly measured in monetary units.

The famous book Peopleware: Productive Projects and Teams by de Marco and Lister^[14] brought the importance of people-related factors to the attention of a broader audience. They collected in many software projects experiences with good and bad management practice that have an influence on the productivity of the team. They and others showed that these are the decisive issues in software engineering but were only able to describe them anecdotally.

There are probably a large number of factors influencing the programming productivity of individuals and teams. For example, the used software development process probably influences the effectiveness and efficiency of a team.

The personalities of software programmers influence the used coding styles which, in turn, influence the productivity of the programmers.^[15]

In 2007, the xkcd comic popularized the concept of a Ballmer Peak—that a programmer, with just the right amount of inebriation, achieves a high state of productivity. The Ballmer Peak is named after former Microsoft CEO, Steve Ballmer,^[16] and is likely a play on Balmer series of hydrogen spectral lines named for Johann Balmer.^[17]

• Software Cost Estimation with Cocomo II, Barry W. Boehm et al., Prentice Hall, 2000. ISBN 978-0-13-026692-7.
• Developing Products in Half the Time: New Rules, New Tools, Preston G. Smith and Donald G. Reinertsen, Wiley, 1997. ISBN 978-0-471-29252-4.
• Programming Productivity, Capers Jones, Mcgraw-Hill, 1986. ISBN 978-0-07-032811-2.
• Estimating Software Costs, Capers Jones, McGraw-Hill, 2007. ISBN 978-0-07-148300-1.