Programming productivity: Difference between revisions

Revision as of 17:02, 3 March 2014

Latest revision as of 17:49, 24 August 2025

(43 intermediate revisions by 26 users not shown)

Line 1:

'''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.

{{cleanup|reason=The structure does not fit Wikipedia style, and there are inline external links|date=January 2013}}

{{essay}}

'''Programming productivity''' refers to software development issues and methodologies affecting the quantity and quality of code produced by an individual or team. Key topics in productivity discussions have included:

==Terminology==

* Amount of code that can be created or maintained per programmer (often measured in [[source lines of code]] per day'')

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.<ref name="ramirez2004" /> 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.<ref>Neal, A., Hesketh, B., Anderson, N., Ones, D. S., Sinangil, H. K., Viswesvaran, C. (ed.) Handbook of Industrial, Work and Organizational Psychology Productivity in Organizations. Sage Publications Ltd, 2002, 8-24</ref> The following definitions describe the best consensus on the terminology.<ref name="tangen2005">Tangen, S. Demystifying productivity and performance, International Journal of Productivity and Performance, 2005, 54, 34-36</ref>

* Detecting and avoiding errors (through techniques like [[Agile Software Development]], [[six sigma]] management, [[zero defects]] coding, and [[Total Quality Management]])

* Software cost estimation (cost being a direct consequence of productivity)

===Productivity===

The relative importance of programming productivity has waxed and waned along with other industry factors, such as:

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:

* The relative costs of manpower versus machine

* a substantially less expensive global workforce is available via the Internet

** examples:

*** http://www.wired.com/wired/archive/12.02/india.html?pg=7

*** http://www.wired.com/wired/archive/12.02/india.html

* The size and complexity of the systems being built

* Highly publicized projects that suffered from delays or quality problems

* Development of new technologies and methods intended to address productivity issues

* Quality management techniques and standards

* apathy may be a factor (productivity needs to be a goal)

Productivity = Output / Input

A generally accepted working definition of programmer productivity needs to be established and agreed upon. Appropriate metrics need to established. Productivity needs to be viewed over the lifetime of code. Example: Programmer A writes code in a shorter interval than programmer B but programmer A's code is of lower quality and months later requires additional effort to match the quality of programmer B's code; in such a case, it is fair to claim that programmer B was actually more productive.

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.<ref>Chew, B. W. No-Nonsense Guide to Measuring Productivity. Harvard Business Review, 1988, 66, 110-115</ref> Non-manufacturing industries usually use man-hours or similar units to enable comparison between outputs and inputs.

Hardware aspects of programmer productivity

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:<ref name="tangen2005" />

It is unfair to measure programmer productivity without factoring in the software and hardware tools that have been provided to the programmers being measured. Example: a programmer with two displays is likely to be more productive than a programmer with a single display. With solid state drives becoming less expensive, one's hardware can be fine tuned for faster compilation as is required by new development paradigms such as TDD ([[test driven development]]).

* the individual machine or manufacturing system;

An extensive literature exists dealing with such issues as software productivity measurement, defect avoidance and removal, and software cost estimation. The heyday of such work was during the 1960s-1980s, when huge mainframe development projects often ran badly behind schedule and over budget. A potpourri of [[software development methodology|development methodologies]] and [[software development tools]] were promulgated, often championed by independent consultants brought in as troubleshooters on critical projects. The [[U.S. Department of Defense]] was responsible for much research and development in this area, as software productivity directly affected large military procurements.

* 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),<ref name="drucker1999">Drucker, P. F. Knowledge-Worker Productivity: The Biggest Challenge. California Management Review, 1999, 41, 79-94</ref> 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.<ref name="ramirez2004">Ramírez, Y. W., Nembhard, D. A. Measuring knowledge worker productivity: A taxonomy. Journal of Intellectual Capital, 2004, 5, 602-628</ref> The same holds for more specific area of programming productivity.

In those days, large development projects were generally clean-sheet implementation of entire systems, often including their own system-level components (such as data management engines and terminal control systems). As a result, large organizations had enormous data processing staffs, with hundreds or thousands of programmers working in [[assembly language]], [[COBOL]], [[JOVIAL]], [[Ada (programming language)|Ada]], or other tools of the day.

===Profitability===

Modern computer use relies much more heavily on the use of standardized platforms and products, such as the many general-purpose tools available today under Linux and the Microsoft operating systems. Organizations have more off-the-shelf solutions available, and computer use is a basic job requirement for most professionals. Tasks that once would have required a small development team are now tackled by a college intern using [[Microsoft Excel]]. The result has been a trend toward smaller IT staffs and smaller development projects. With larger projects, techniques like [[rapid application development|rapid prototyping]] have shortened development project timelines, placing a priority on quick results with iterative refinement. Traditional programming-in-the-large has thus become rare &ndash; the ___domain of industry giants like [[Microsoft]] and [[IBM]]. As a result, although programming productivity is still considered important, it is viewed more along the lines of engineering [[best practice]]s and general [[quality management]], rather than as a distinct discipline.

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

A need for greater programmer productivity was the impetus for categorical shifts in programming paradigms. These came from

Profitability = Revenue / Cost

* Speed of code generation

* Approach to maintenance

* Emerging technologies

* Learning curve (training required)

* Approach to testing

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.

==References==

* ''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

===Performance===

Internet articles

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.

* "Coding Horror: Joining The Prestigious Three Monitor Club" (December 2006) http://www.codinghorror.com/blog/2006/12/joining-the-prestigious-three-monitor-club.html

===Efficiency and effectiveness===

* "Coding Horror: The Programmer's Bill of Rights" (August 2006) http://www.codinghorror.com/blog/2006/08/the-programmers-bill-of-rights.html

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,<ref name="tangen2005" /> 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".

* "Dual Monitors", Bob Rankin http://askbobrankin.com/dual_monitors.html

{{Quotation|

"... studies I've read come to the same conclusion: having a dual monitor

in a workplace setting can increase productivity by 20 to 50 percent.

If you're a computer programmer, it should be obvious that having your

source code on one side and your program on the other side of a dual monitor display

would be very helpful. Other areas where a dual monitor setup are helpful include customer

service reps, web design, and creation of newsletters or PowerPoint presentations."

}}

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

===Quality===

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."<ref name="tangen2005" /> 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.<ref>Thomas, B. E. & Baron, J. P. Evaluating Knowledge Worker Productivity: Literature Review Construction Engineering Research Lab (USACERL), 1994</ref> 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.<ref name="drucker1999" /><ref name="ramirez2004" /><ref>Al-Darrab, I. A. Relationships between productivity, efficiency, utilization, and quality. Work Study, 2000, 49, 97-104</ref><ref name="saari2006">Saari, S. Productivity: Theory and Measurement. In Business Proc. of the European Productivity Conference (EPC), 2006</ref><ref>Ray, P., Sahu, S. The Measurement and Evaluation of White-collar Productivity. International Journal of Operations & Production Management, 1989, 9, 28-47</ref>

[[Category:Production economics]]

[[Category:Software project management]]

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?""<ref name="drucker1999" />

Saari captures the importance of quality with his extended formula for productivity:<ref name="saari2006" />

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.

==State of the art==

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

===COCOMO II===

Boehm was one of the first researchers that systematically approached the field of software productivity. His cost estimation model [[COCOMO]] - now COCOMO II<ref>Boehm et al. Software Cost Estimation with COCOMO II, 2000</ref> - 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's software productivity===

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,<ref>{{Cite book |last=Jones |first=Casper |year=2000 |title=Software Assessments, Benchmarks, and Best Practices |___location=Boston, Mass. |publisher=Addison-Wesley}}</ref><ref name=jones>{{Cite book |last=Jones |first=Casper |year=1986 |title=Programming Productivity |url=https://archive.org/details/programmingprodu0000jone |url-access=registration |___location=New York |publisher=McGraw-Hill Book Company |page=[https://archive.org/details/programmingprodu0000jone/page/85 85]–86 |isbn=9780070328112 |oclc=611260287 |access-date=14 April 2020}}</ref> 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:

<blockquote>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<ref name=jones/>

</blockquote>

===Function points===

[[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.

===Value-based software engineering===

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.<ref>Barry Boehm, Li Guo Huang. Value-Based Software Engineering: A Case Study. IEEE Software, 2003</ref> 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.

===Peopleware===

The famous book [[Peopleware: Productive Projects and Teams]] by de Marco and Lister<ref>Tom DeMarco, Timothy Lister. Peopleware: Productive Projects and Teams, 1987</ref> 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.

== Factors influencing programming productivity ==

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.<ref>{{Cite journal|title = Links between the personalities, styles and performance in computer programming|url = http://elib.uni-stuttgart.de/opus/volltexte/2015/10315/|journal = Journal of Systems and Software|date = 2016|pages = 228–241|volume = 111|doi = 10.1016/j.jss.2015.09.011|first1 = Zahra|last1 = Karimi|first2 = Ahmad|last2 = Baraani-Dastjerdi|first3 = Nasser|last3 = Ghasem-Aghaee|first4 = Stefan|last4 = Wagner|arxiv = 1611.10169|s2cid = 400518}}</ref>

== In popular culture ==

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]],<ref>{{Cite web |title=Ballmer Peak |url=https://xkcd.com/323/ |access-date=2023-10-07 |website=xkcd}}</ref> and is likely a play on [[Balmer series]] of hydrogen spectral lines named for [[Johann Balmer]].<ref>{{Cite web |title=323: Ballmer Peak - explain xkcd |url=https://www.explainxkcd.com/wiki/index.php/323:_Ballmer_Peak |access-date=2023-10-07 |website=www.explainxkcd.com}}</ref>

== References ==

{{reflist}}

==Further reading==

* ''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}}.

[[Category:Productivity]]

[[Category:Software engineering costs]]

[[Category:Software project management]]