Seven Diagrams Every

Software Developer
Should Understand
www.construx.com

Also Known As

How Not to be Surprised in

Software Development

Copyright Notice
These materials are 1996-2014 Construx Software Builders,
Inc.
All Rights Reserved. No part of the contents of this seminar
may be reproduced or transmitted in any form or by any
means without the written permission of Construx Software
Builders, Inc.

Introduction

How Not to Be Surprised in Software Development

My Background

Another 300 books

and articles!

300 books and articles?

600 books and articles!

Another ~1000 papers,

of which only 250
were publishable
<sigh>

Construx
5

I did not work as hard on my next book,

Software Project Survival Guide

Construx
6

A History of
Attempts to Explain
Software
Development

A Long Line of Attempts to Explain

Software Development

Construx
8

Why do we Need to Help People

Understand Software Engineering?

Construx
9

Why do we Need to Help Other People

Understand Software Engineering? (cont.)

We all know we were working under a compressed

time frame to launch this on Oct. 1

they had just two weeks to test the site before all
the pieces from several contractors had to work
together the day of the launch.

Determining many of the problems the system would

have after the various parts were integrated was
difficult until the site actually went online, Bataille
said. It was the agencys responsibility to make sure
all the parts worked together.

According to one specialist, the Web site contains

about 500 million lines of software code. By
comparison, a large banks computer system is
typically about one-fifth that size.

The technology is there to do that. It just

requires foresight.
Construx
10

Latest Attempt to Explain Software Development

Software
Engineering
Essentials
Lecture Series
CxLearn.com
Construx
11

The Goal

Help software professionals develop mental

models and frameworks to understand and

improve their software projects, to understand

the context for current software practices,

and to evaluate new developments in

software engineering.
Construx
12

Talk Roadmap

Roadmap for This Talk

Introduce four core influences

Highlight seven key diagrams
Introduce many other diagrams
that are also informative
Whats the benefit of that?

Candidate

Top 7
Diagram

Construx
14

Four Core Software

Influences

Four Core Influences

SIZE (diseconomy of scale; failure rate; specializations; mix of activities)

UNCERTAINTY (intellectual phases; cone of uncertainty; feature

staircase vs. feature buildup; risk management; effort vs. certainty curve)

DEFECTS (DCI, defect detection lag, defect removal techniques in

series, relationship to process stability)

HUMAN VARIATION (effect on research; effect on selection of

methods (familiar vs. unfamiliar); effect on team composition, team
cohesion, recruiting, and retention; focus on perfect execution vs. perfect
plans; implication for favoring robust methods)
Construx
16

Core Influence:

Size

Which Size Diagrams Are Most Informative?

Productivity

Output

We have many informative diagrams. Which really

explains the essence of Size in Software?

1 ~7

~50
~250-350
Team Size

Construx
18

Diseconomy of Scale (Fred Brooks)

Efficiency is an N2 function of the number of
people on the project due to communication
paths: N*(N-1)/2
1 person =
0 paths

2 people =
1 path

3 people =
3 paths

4 people =
6 paths

5 people =
10 paths

19

50
45
40
35
30
25
20
15
10
5
0

300
250
200
150

100
50

Effort (Staff Months)

Schedule (Months)

Diseconomy of Scale (Larry Putnam)

1.5-3

3-5

5-7

9-11

15-20

Team Size
Schedule

Effort

Adapted from Lawrence H. Putnam and Ware Myers, Five Core Metrics: The Intelligence
Behind Successful Software Management

20

Brooks Diseconomy of Scale Revisited

Efficiency is an N2 function of the number of
people on the project due to communication
paths: N*(N-1)/2
1 person =
0 paths

2 people =
1 path

3 people =
3 paths

4 people =
6 paths

5 people =
10 paths

50 people =
1225 paths

21

Productivity

Diseconomy of Scale: McConnells

Step Function

~7

~50

~250-350

Team Size
22

Productivity

Output

Diseconomy of Scale: McConnells

Step Function, Output

~7

~50

~250-350

Team Size
23

Failure Rates by Size

Project Outcomes by Project Size
100%

90%

Percentage

80%
70%

Early

60%

On Time
Late

50%

Failed

40%
30%
20%
10%
0%
10 FP
500-1000 LOC

Construx

100 FP
5K-10K LOC

1,000 FP
50K-100K LOC

10,000 FP
500K-1M LOC

100,000 FP
5M-10M LOC

Source: Adapted from Applied Software Measurement, 3rd Edition (Jones 2008), Estimating Software Costs (Jones 1998).

24

Error Rate by Size? Productivity by Size?

Error Rate by Size

Notice the High here?

This implies that a 500 MLOC
healthcare.gov would
require at least
100,000 staff-years of effort
(all since 2010!)

120

Defects / KLOC

100
80
Low Error Rate
60

High Error Rate

Average Error Rate

40

Productivity by Size

20
30,000

2-16
KLOC

16-64
KLOC

64-512
KLOC

512+
KLOC

25,000
LOC / Staff Year

<2 KLOC

20,000
High LOC/Staff Year
15,000

Nominal
Low LOC/Staff Year

10,000
5,000
1 KLOC

10
100
1,000 10,000
KLOC KLOC KLOC KLOC

Construx
25

Specializations by Organization Size

Construx
26

Cocomo Factors by
Size

Cocomo IIs View of Software Project

Influences
Product Complexity
Requirements Analyst Capability

Programmer Capability (general)

-27%

74%

-29%

42%

-24%

34%

Time Constraint
Personnel Continuity (turnover)
Multi-Site Development

0%
-19%

29%

-22%

22%

Required Software Reliability

-18%

Extent of Documentation Required

-19%

23%

Applications (Business Area) Experience

-19%

22%

Use of Software Tools

Platform Volatility

26%

-22%

17%

-13%

30%

Storage Constraint

0%

46%

Precedentedness

-19%

15%

Process Maturity

-19%

15%

Language and Tools Experience

Database Size
Platform Experience
Architecture and Risk Resolution
Development Flexibility

-16%

Team Cohesion

20%

-10%

28%

-15%

19%

-18%

14%

-16%

Developed for Reuse

Construx

63%

12%
-5%

-14%

24%
11%

28

Cocomo IIs View of Software Project

Influences

Construx
29

Cocomo IIs View of Software Project

Influences

Construx
30

Why Does This Matter?

(Implications of the Diagram)

Understanding the factors in the Cocomo model

and their relative importances goes a long way
toward explaining software project dynamics
overall
Many dynamics related to project size are implied
by Cocomos scaling factors
Many dynamics related to human variation are
implied in the Cocomo model

Construx
31

Activity Mix by Project

Size

Project Activity Mix by Project Size

Construction
is approx.
2/3

Construction
is approx.
1/3

Construx
33

Why Does This Matter?

(Implications of the Diagram)

Small project success does not prepare

organizations for large project success
Organizations must change focus as their projects
inevitably become larger
Organizations must build different/additional skill
sets as their projects become larger
There are numerous interactions between size,
uncertainty, defects, and human variation

Construx
34

Core Influence:

Uncertainty

Again, We Have Many Wonderful

Uncertainty Diagrams

Construx
36

Effort vs. Knowledge Curve

100%

75%

Knowledge /
Understanding

50%

25%

0%

Effort Expended

37

Feature Build Down

(The Feature Staircase)

Plan

Waste
Release

Construx
38

Feature Build Up

Value /
Functionality
Cost

Opportunity to
Add More
Value

Time
Diminishing returns when functionality is
delivered in priority order
39

Risk Management: Relationship between

Planned and Unplanned Work

Planned Work

Planned
Overhead

Unplanned,
Variable Work

40

Cone of Uncertainty
vs. Cloud of
Uncertainty

Cone of Uncertainty vs. Cloud of Uncertainty

Project scope
(effort, size, features)

Project
schedule

4x

1.6x

2x

1.25x

1.5x

1.15x

1.25x
1.0x
0.8x

1.1x
1.0x
0.9x

0.67x

0.85x

0.5x

0.8x

0.25x

0.6x

Initial
Requirements
Detailed
product
design
definition
Approved
Product
product
design
definition

Product
complete

42

Why Does This Matter?

(Implications of the Diagram)

Explains why perfect estimation on Day 1 of a

project is not possible
Explains why reestimation is necessary if you want
accurate estimates
Explains why actively attacking uncertainty is
essential

Construx
43

Intellectual Phases

Intellectual Phases
Discovery

Invention

Construction

Focus

Schedule
This figure is adapted from Grady Booch, Object Solutions: Managing
the Object-Oriented Project, Reading, Mass: Addison Wesley 1996

45

Intellectual Phases

Cost of Overlap
Discovery

Invention

Construction

Overlap =

Focus

Dependencies
Uncertainty
Risk
Rework
Higher costs
Longer
schedules
Lower quality

Schedule
Construx
46

Intellectual Phases

Degree of Overlap

Discovery

Invention

Construction

Discovery

Invention

Construction

Discovery

Invention

Construction

Focus

Time

Time

Time

Construx
47

Intellectual Phases

Variations in Sources of Project Challenges

Discovery

Invention Construction

Focus

Construx
48

Uncertain

Many project failures are caused

by treating uncertainties as
though they are certain
Additional inefficiencies are
created by treating uncertainties
as if they were certain
Inefficiencies are also created by
treating certainties as if they were
uncertain
Softwares intangibility
exacerbates this phenomenon
Diagram provides a framework
for identifying uncertainty and
planning appropriately

Certain

Project is Treated As

Why Does This Matter?

(implications of the diagram)

Inefficient

Effective

Effective

Risks
Failure

Certain

Uncertain

Project Is

Construx
49

Core Influence:

Defects

Defect Cost Increase (DCI)

Activity in which a
Defect Is
Introduced

Average
Cost to
Correct

Requirements

Architecture
Construction
Requirements

Architecture

Construction

System test

Post-Release

Activity in Which a Defect Is Detected

Construx
51

Fix More Defects Earlier!

Fix Here

Dont Wait
to Fix Here

Activity in which a
Defect Is
Introduced

Average
Cost to
Correct

Requirements
Architecture
Construction
Requirements

Architecture

Construction

System test

Post-Release

Activity in Which a Defect Is Detected

Construx
52

Reduce Defect Cost Increase!

Activity in which a
Defect Is
Introduced

Average
Cost to
Correct

Requirements
Architecture
Construction
Requirements

Architecture

Construction

System test

Post-Release

Activity in Which a Defect Is Detected

Construx
53

Quality is an Accelerator
Quality improvement
motivated primarily by economics
(quality is free)

Quality improvement
motivated by quality, per se
(quality costs more)

Effort/ Cost/
Schedule

Most Orgs
are Here
~95%
Percentage of Defects
Removed Before Release

100%

Construx
54

Gap Between Defect

Insertion and Defect
Detection

Minimize Gap Between Defect

Insertion and Defect Detection

Typical Project

Cumulative
Defects

Well-Run Project
Risk of
Extra Cost

Risk of
Extra Cost

Time

Time
Defect creation

Defect removal

Schedule /
Cost
Savings

Construx
56

Why Does This Matter?

Practices that increase gaps between defect

insertion and defect detection will increase project
costs and project risk
Practices that minimize gaps between defect
insertion and defect detection will reduce project
costs and project risks
Understanding this diagram fully will lead to
basically same conclusions as understanding the
other diagrams

Construx
57

Core Influence:

Human
Variation

Note
This is not just
general humans
develop software.
This is specifically
about variation
across different
humans.

Wednesday May 21 2009

Human Beings Exhibit the Same

Variations in Performance That
Programmers Do!

Construx
59

Cocomo IIs View of Software Project

Influences
Requirements Analyst Capability -29%
Programmer Capability (general)

Construx

42%

-24%

34%

Personnel Continuity (turnover)

-19%

Applications (Business Area) Experience

-19%

-78%

29%

22%

Language and Tools Experience

-16%

20%

Platform Experience

-15%

19%

Team Cohesion

-14%

11%

Cumulative Effect of Personnel Factors

373%
60

Human Variation vs.

Process-or-Practice
Variation

Differences in Productivity

Productivity of Team A

Productivity of Team B

Productivity

Construx
62

Differences in Methods

Productivity
B

Team A Used
Pair Programming
Team B Used
Formal Inspections

Which
method is
better?

Construx
63

Differences in Capability

Team A Had
Star Performers

Team B Had
Average Performers

Productivity

Now
which
method is
better?

Construx
64

Process Variation vs. Human Variation

Typical Variation in
Individual Productivity (20:1) and
Team Productivity (3-10:1)

Productivity

Typical Variation in
Method Productivity (~20%)

Construx
65

Effect of Variations in Human Productivity

Typical Variation in
Individual Productivity (20:1) and
Team Productivity (3-10:1)

Productivity

Typical Variation in
Method Productivity (~20%)

Construx

Is the observed productivity difference between A and B

due to method differences or to differences
in individual capability or team capability?
66

Example:
Chrysler C3 Extreme Programming Project
Range that Kent Beck and
Ron Jeffries would perform using
any methods whatsoever

Kent and Rons performance on

Chrysler C3 project (speculation)

Productivity

Range that average personnel

will perform in, with or without
Extreme Programming
So, what is the effect of
Extreme Programming?

Construx
67

Why Does This Matter?

Academic research on process effectiveness must

account for human variation to be meaningful (and
most does not)
Evaluation of pilot projects in organizations must
account for human variation to evaluate new
methods (and most does not)
The most effective approaches to software
development are capability based rather than
process based

Construx
68

Summary
Size

Defects

Uncertainty

Human
Variation

Four Core Influences

Size

Defects

Uncertainty

Human
Variation

Construx
70

Why Does This Matter?

Each influence is important in itself

Each influence interacts with each other influence,

and the interactions are significant

Goal: Help software professionals develop a mental

model / framework for understanding current
practices and new developments in software
engineering

Construx
71

Latest Attempt to Explain Software Development

Software
Engineering
Essentials
Lecture Series
CxLearn.com

Check it out now!

Construx

72

Construx Software is committed to helping

individuals and organizations improve their
software development practices. For information
about our training and consulting services, contact
stevemcc@construx.com
+1(425)636-0100

10900 NE 8th Street, Suite 1350

Bellevue, WA 98004
+1 (866) 296-6300
www.construx.com

END