Resource Allocation and the Law of Diminishing Returns



Similar documents
Parallel Scalable Algorithms- Performance Parameters

Performance metrics for parallel systems

Quiz for Chapter 1 Computer Abstractions and Technology 3.10

How To Model Software Development Life Cycle Models

Agenda. Enterprise Application Performance Factors. Current form of Enterprise Applications. Factors to Application Performance.

Homework #1 Solutions

Procedure for Graphing Polynomial Functions

on an system with an infinite number of processors. Calculate the speedup of

Chapter 4 Technological Progress and Economic Growth

Review of Production and Cost Concepts

Energy Efficient MapReduce

Understanding the Benefits of IBM SPSS Statistics Server

USING SPREADSHEET SOFTWARE TO TEACH THE RECIPROCAL METHOD OF SERVICE DEPARTMENT COST ALLOCATION. By:

FPGA area allocation for parallel C applications

Four Keys to Successful Multicore Optimization for Machine Vision. White Paper

Linear Programming Supplement E

System Models for Distributed and Cloud Computing

1 Discussion of multithreading on Win32 mod_perl

Mathematics 31 Pre-calculus and Limits

Motion Graphs. It is said that a picture is worth a thousand words. The same can be said for a graph.

Big Data 101: Harvest Real Value & Avoid Hollow Hype

Unprecedented Performance and Scalability Demonstrated For Meter Data Management:

Performance metrics for parallelism

ILLIQUID ALTERNATIVE ASSET FUND MODELING. Dean Takahashi Yale University Investments Office. Seth Alexander Yale University Investments office

Integrating Spreadsheet Templates and Data Analysis into Fluid Power Instruction

South Carolina College- and Career-Ready (SCCCR) Probability and Statistics

QLIKVIEW ARCHITECTURE AND SYSTEM RESOURCE USAGE

Architectural Patterns: From Mud to Structure

The Methodology of Application Development for Hybrid Architectures

Introduction to Quadratic Functions

FOUNDATIONS OF A CROSS- DISCIPLINARY PEDAGOGY FOR BIG DATA

Use finite approximations to estimate the area under the graph of the function. f(x) = x 3

Estimating the Average Value of a Function

Revolutionized DB2 Test Data Management

Year 9 set 1 Mathematics notes, to accompany the 9H book.

Performance of Dynamic Load Balancing Algorithms for Unstructured Mesh Calculations

System Copy GT Manual 1.8 Last update: 2015/07/13 Basis Technologies

Tools Page 1 of 13 ON PROGRAM TRANSLATION. A priori, we have two translation mechanisms available:

Six Strategies for Building High Performance SOA Applications

What is a life cycle model?

Instructional systems development

How To Understand Cost Volume Profit Analysis

Software-defined Storage Architecture for Analytics Computing

Rackspace Cloud Databases and Container-based Virtualization

This means there are two equilibrium solutions 0 and K. dx = rx(1 x). x(1 x) dt = r

Lecture 4. Parallel Programming II. Homework & Reading. Page 1. Projects handout On Friday Form teams, groups of two

Chapter 6: The Information Function 129. CHAPTER 7 Test Calibration

Variable Costs. Breakeven Analysis. Examples of Variable Costs. Variable Costs. Mixed

10.2 Series and Convergence

Week 7 - Game Theory and Industrial Organisation

Business and Economics Applications

Big Data Systems CS 5965/6965 FALL 2015

The Document Review Process: Automation of your document review and approval. A White Paper. BP Logix, Inc.

A capacity planning / queueing theory primer or How far can you go on the back of an envelope? Elementary Tutorial CMG 87

Copyright 1

Make Better Decisions with Optimization

Comparison of Cloud vs. Tape Backup Performance and Costs with Oracle Database

Engineering Process Software Qualities Software Architectural Design

Complete a table of values. Graph the values given in a table. Create an equation representing the information in a table or graph.

MPI and Hybrid Programming Models. William Gropp

IMCM: A Flexible Fine-Grained Adaptive Framework for Parallel Mobile Hybrid Cloud Applications

Gamma Distribution Fitting

Battleships Searching Algorithms

How To Understand Engineering

IT White Paper. N + 1 Become Too Many + 1?

ANALYTICS STRATEGY: creating a roadmap for success

CAHSEE on Target UC Davis, School and University Partnerships

Managing batch and business processes in Oracle environments

Software Engineering. What is a system?

Structure of Presentation. The Role of Programming in Informatics Curricula. Concepts of Informatics 2. Concepts of Informatics 1

Design and Development of Virtual Instrument (VI) Modules for an Introductory Digital Logic Course

Life Insurance Modelling: Notes for teachers. Overview

Distributed Dynamic Load Balancing for Iterative-Stencil Applications

Model Based Testing (MBT) J u n e

Managing large clusters resources

Chapter 12: Multiprocessor Architectures. Lesson 01: Performance characteristics of Multiprocessor Architectures and Speedup

The Fastest Way to Parallel Programming for Multicore, Clusters, Supercomputers and the Cloud.

Technology, Production, and Costs

Parallel Algorithm Engineering

White Paper Business Process Modeling and Simulation

Algebra 1 Course Title

Finite Elements Infinite Possibilities. Virtual Simulation and High-Performance Computing

3C05: Unified Software Development Process

MapReduce and Distributed Data Analysis. Sergei Vassilvitskii Google Research

Lectures 5-6: Taylor Series

Summary. Chapter Five. Cost Volume Relations & Break Even Analysis

A Mathematical Programming Solution to the Mars Express Memory Dumping Problem

Transcription:

esource Allocation and the Law of Diminishing eturns Julia and Igor Korsunsky The law of diminishing returns is a well-known topic in economics. The law states that the output attributed to an individual unit of input diminishes with each additional unit of input, hence the term diminishing returns or diminishing returns on investment. Since ancient times people learned that planting too many seeds leads to poor harvesting results, i.e. one cannot indefinitely increase the input to further increase the output. As our life becomes more complex we apply this ancient knowledge to multiple aspects of life. Computer scientist Gene Amdahl has demonstrated applicability of diminishing returns to parallel computing. Amdahl developed a formula to calculate the optimal number of parallel CPUs needed for large calculations. He illustrated that acceleration is constrained by the part of code-execution that runs sequentially, and thus maximum overall time improvement is finite and can be calculated (estimated). Allocation of human resources can be approached in the same way as hardware resources. Adding people to a project will result in time improvement for project s concurrent tasks, but the law of diminishing returns kicks in due to the existence of sequential tasks. This article provides IT Project and esource Managers with a quick rule of thumb in estimating the optimal resource allocation for large projects. We use Amdahl s formula and apply it to a hypothetical project to analyze maximum possible time improvement. We then enhance the formula to take project overhead into account. We illustrate the impact of fixed project overhead to the project s time improvement. We also look into the more realistic scenario of having variable overhead. In doing so, we will illustrate the concept of saturation point - a point after which adding resources to the project becomes counterproductive, decreasing the overall project completion time. Example Let s imagine a large software project to be completed by a single software developer. Let s assume that developer works 00 percent in isolation completing the project within certain time. It may be sensible to add more people to speedup project development. The question is: How many? We all know that project will not be finished proportionally faster to the number of added resources. The overall time improvement will be affected by the existence of tasks that cannot be parallelized. If we ignore other factors (for now), and in a way pretend that people are machines, the overall project development time improvement ) can be calculated using well-known Amdahl s formula: ) P + P In the above formula, P is a fraction of work that can be parallelized; is the total number of resources. In all examples that we showing in this article we are going to assume that 90 percent of all tasks can be parallelized, i.e. P.

) + Table below provides results ) for of our calculations for {5, 0,, 65}: esources () 0 5 0 5 0 5 0 5 0 5 0 5 (I).57.263.250.897.353.692.955.63.333.475.594.696.784 Incremental Time (ΔI).692.987.647.456.339.262.209.70.4.9.02.088 Table. A Classic Case of Diminishing eturns The data in the Table illustrates a classic case of diminishing returns every 5 people (unit of input) has lesser and lesser impact on the Incremental Time s ΔI (unit of output). If, then ΔI 0 as illustrated on a graph bellow (Figure ) 8.000 6.000 (I) Incremental Time (ΔI) 5 0 5 20 25 30 35 40 45 50 55 60 65 Figure. A Classic Case of Diminishing eturns Analysis of the above dataset leads to a conclusion that total time improvement I is a finite number. For example, if 000,

000) 9.9 + 000 In fact, with P when, I 0 as demonstrated in formula below. + 0. + lim lim Above calculations illustrate that regardless of the number of resources added to the project the maximum possible time improvement is 0, given the 90 percent parallel tasks. Example 2 In real life the potential for the s will be smaller than in the Example. The more people are being added to the project, the more new tasks are being introduced to make sure people work cohesively more status meetings, more code sharing and more documentation, coordination and new discussions. Thus, we propose to adjust Amdahl s formula by taking into account the Total Overhead O due to the human factors: O ) ( + O P) + P 0 Let s continue with our example project in which we could parallelize 90 percent of the tasks. In a simplified case let s assume that project s overhead is a fixed number, regardless of the number of resources working on a project. Let s assume that fixed overhead is 0 percent (O 0.). As in a previous example, we are going to calculate ) for {5,0,, 65}: esources () 0 5 0 5 0 5 0 5 0 5 0 5 (I).895.793.23.490.66.783.873.944.000.046.084.6.44 Incremental Time (ΔI).898.438.259.7.22.09.070.056.046.038.032.028 Table 2. The for 000

In addition to the data in Table 2, let s calculate the for 000. Wwe intentionally took such a large number of people to further illustrate the law of diminishing returns. As shown below 000) is equal to 5.475. 0. 000) 5.475 ( + 0. ) + 000 Comparing results with the first example, it is evident that an overhead has an impact on the Total Time ). The maximum improvement for this example is shown below: 0. ( + 0. ) +. 0.2 + lim lim 5.5 6.000 5.000 3.000.000 (I) Incremental Time (ΔI) 5 0 5 20 25 30 35 40 45 50 55 60 65 Figure 2. Negative Effect of Overhead The data set in Table 2 and Figure 2 illustrates that the is negatively impacted by the project s overhead. However, shapes of the above curves (I and ΔI) are not affected by the overhead. Example 3 Let s make our example even more realistic. It is reasonable to presume that a larger team has a larger overhead and that overhead consists of a fixed part not affected by the team s size and a variable part that will grow as the team grows. Note that in real life the variable overhead is even harder to calculate it may grow incrementally, increasing with each new resource or resemble a step-curve. For the purpose of our demonstration we are going to show the case where variable part is proportional to the amount of resources. The overall overhead is a sum of fixed overhead (o) and growing variable part ( k ), where k is a coefficient of overhead per person, O o + k Our modified formula looks as following:

o + k ) ( + o + k P) + P Let s assume a 0 percent fixed overhead o and each person adds 50 basis points to the fixed overhead, i.e. k 0.005. For 5 people the total overhead O 0. 5 0. 025 If we plug in 0 in the above formula, then ) 3.382 (see below) 0. 0 0) 3.382 ( + 0. 0 ) + 0 If we plug in 000 in the above formula, then ).73 (see below) 0. 000 000).73 ( + 0. 000 ) + 000 These results (for 0) and 000)) paint a different picture for the ). In the two prior examples, if < 2 then ) < 2 ). However, this is not the case since we introduced a variable overhead in our current example. We can conclude that a variable portion of the overhead has a significant impact on the total time improvement and thus 0 people achieve better result than 000 people. To generalize this observation, the limit of ) is calculated below: 0. ( + 0. ) +. 0.2 + + lim lim When we plugging in the numbers into our formula with the same P and {5, 0,, 65} we get the following values of I and ΔI: esources () 0 5 0 5 0 5 0 5 0 5 0 5 (I).778.382.507.478.393.289.82.077.978.885.798.78.645 Incremental Time (ΔI).60.3 0.03 0.08 0.0 0. 0.0 0.0 0.09 0.09 0.08 0.07

Table 3. Too Many People Slow a Project Down 3.000.000 -.000 5 0 5 20 25 30 35 40 45 50 55 60 65 Incremental Time Figure 3. The Saturation Point Table 3 and Figure 3 demonstrate something that experienced managers already know too many people will slow a project down rather than speeding it up. Adding people are beneficial only to a certain point after which the overall time improvement decreases we will call this point a saturation point. In the current example the saturation point is reached at 6 (sixteen people). If we continue adding people, incremental time improvement ΔI becomes negative and I decreased. Conclusions Overall time improvement I from all three examples is shown on the in Figure 4. 9.000 8.000 7.000 6.000 5.000 3.000.000 5 0 5 20 25 30 35 40 45 50 55 60 65 (I) 2 (I) 3 (I) Figure 4. Times form All Three Examples The law of diminishing returns applies to projects resource management and Incremental Time ΔI attributed to each additional resource diminishes with each new resource.

tasks. Projects I is always a finite number due to the existence of sequential The upper bound of the total time improvement I can be quickly estimated based on the Amdahl formula. That number can be further refined with our proposed formula that takes project overhead into account. If project overhead grows with the number of project resources, then the overhead has a negative impact on the I. Growing overhead brings a project to a saturation point, a point after which adding resources increases the overall project time rather than decreasing it. About the Authors Julia Korsunsky is a senior technologist with emphasis in database architecture. For over 20 years Julia has consulted clients from start-ups to Fortune 500 companies designing and implementing systems, performing business analysis and project management for financial, utilities, biomedical and pharmaceutical industries. She created and taught IT training courses at Clark University and written articles, manuals and curriculums on a range of technical subjects. She holds two Masters Degrees, in Mathematics (with minor in education) and Computer Science. Julia can be contacted at julia@teamxtra.com Igor Korsunsky is a senior manager with over 20 years of diverse IT experience in finance, banking and healthcare. Igor is experienced in IT planning, budgeting, and technical and business analyses, systems and workflow architecture. Igor holds two Masters Degrees in Manufacturing (minor in automation) and Mechanical Engineering. He can be contacted at igor@teamxtra.com