Lehman’s Laws
and the
Productivity of
Increments
Ramin Moazeni, Daniel Link
10/23/13
•
Incremental development is the most common
development paradigm these days
•
Reduces risks by allowing flexibility per increment
•
Incremental Development Productivity Decline (IDPD)
 Based on our logical considerations and industry data, we
believe there is generally a decrease in productivity between
increments
 The decline is due to factors such as previous-increment
breakage and usage feedback, increased integration and
testing effort.
•
Lehman categorizes all software systems to fit one of
three types: S, P or E.
Copyright © USC-CSSE
Introduction
2
Any development effort with:
 More than one step
 More than one released build
 Each steps build on previous ones and would not be able to
stand alone without the steps that came before it
 Increments have to
 Contribute a significant amount of new functionality
 Add a significant amount of size (not less than 1/10th of the
previous one)
 Not just a bug fix of the previous one (otherwise counted as part of
that one)
Copyright © USC-CSSE
•
10/23/13
Incremental Development Definition
3
•
10/23/13
Lehman’s Laws of Software
Evolution
S-type
 S-type or static-type systems are formal and verifiable set of
specifications with easy to understand solutions (their
specifications do not change)
•
P-Type
•
E-type
 E-types, or embedded-types, defined as all programs that
‘operate in or address a problem or activity of the real world’.
 we will restrict our focus to E-type systems, which constitute
most of the world’s software.
Copyright © USC-CSSE
 P-type systems, or practical-type systems, defined precisely
and formally . The solution is not immediately apparent to
the user.
4
•
Model relating productivity decline to
number of builds needed to reach 8M
SLOC Full Operational Capability
•
Assume Build 1 production of 2M
SLOC @100 SLOC/PM
10/23/13
Effects of IDPD on
Number of Increments
Copyright © USC-CSSE
 20000 PM/24mo. = 833 developers
 Constant Staff size for all builds
5
10/23/13
Exploration of IDPD factor
Copyright © USC-CSSE
 Based on experience on several projects, the following sources
of variations have been identified:
6
10/23/13
IDPD type characteristics
Software
Category
Impact on IDPD Factor
Infrastructure
Software
Often the most difficult software.
Developed early on in the program.
IDPD factor likely to be the highest.
Application
Software
Builds upon Infrastructure software.
Productivity can be increasing, or at
least “flat”
Platform
Software
Developed by HW manufacturers. Single
vendor, experienced staff in a single
controlled environment. Integration effort
is primarily with HW.
IDPD will be lower due to the benefits
mentioned above.
Firmware
(Single Build)
IDPD factor not applicable. Single build
increment.
Copyright © USC-CSSE
Non-Deployable Throw-away code. Low Build-Build
integration. High reuse. IDPD factor
lowest than any type of
deployable/operational software
7
10/23/13
Research Hypotheses
•
1) There is a decline in productivity over increments
 For typical cases
 Floor may be reached, after which it rises again
 Methods to prove
 Mathematically
 Data from experience/history
•
2) Decline not constant across across increments
•
3) Decline varies by domain
 Can be proven by statistics (ANOVA)
Copyright © USC-CSSE
 Controlled experiments
8
10/23/13
•
Project 1 and 2 from “Balancing Agility and Discipline”
•
Quality Management Project
Copyright © USC-CSSE
Case studies
9
10/23/13
Projects 1 and 2
•
Two web based client–sever systems developed in Java
•
Data mining systems
•
Agile process similar to XP with several short iteration
cycles and customer-supplied stories
•
Productivity as new SLOC per user story
Copyright © USC-CSSE
 Assumption: Every user story takes the same time to
implement.
10
10/23/13
Polynomial trend line
New Development Effort of Project 1
1.00
0.90
0.85
0.82
0.80
0.77
0.70
0.60
0.57
0.50
Project 1
0.49
0.36
0.30
y = -0.023x5 + 0.3966x4 - 2.5291x3 + 7.321x2 - 9.5311x + 5.2174
R² = 1
0.20
0.10
0.00
1
2
3
4
5
Copyright © USC-CSSE
Poly. (Project 1)
0.40
6
11
10/23/13
Polynomial trend line
(continued)
New Development Effort of Project 1
2.00
1.00
0.85
0.82
0.77
0.57
0.49
0.36
0.00
1
2
3
4
5
6
-1.00
Project 1
-3.00
y = -0.023x5 + 0.3966x4 - 2.5291x3 + 7.321x2 - 9.5311x + 5.2174
R² = 1
Copyright © USC-CSSE
Poly. (Project 1)
-2.00
-4.00
7
-5.00
12
10/23/13
Comparison of trend lines
New Development Efforts of Project 1
1.00
0.90
0.85
0.82
0.80
0.77
0.70
0.60
0.57
0.50
Project 1
Log. (Project 1)
0.49
Power (Project 1)
0.36
0.30
y = -0.233ln(x) + 0.8975
R² = 0.6012
0.20
0.10
y = 0.9141x-0.364
R² = 0.4982
0.00
y = 0.9445e-0.124x
R² = 0.4563
1
2
3
4
5
Copyright © USC-CSSE
Expon. (Project 1)
0.40
6
13
10/23/13
Comparison of trend lines
(continued)
New Development Efforts of Project 2
1.40
y = -0.392ln(x) + 1.0218
R² = 0.7731
1.20
1.00
0.80
y = 1.175x-0.782
R² = 0.5687
0.78
Project 2
Log. (Project 2)
0.67
Power (Project 2)
0.60
0.53
Expon. (Project 2)
0.46
0.40
0.21
0.20
0.14
0.00
1
2
3
4
5
6
Copyright © USC-CSSE
1.00
y = 1.2393e-0.251x
R² = 0.585
7
14
QMP Project Information:
 Web-based application
 System is to facilitate the process improvement
initiatives in many small and medium software
organizations
 6 builds, 6 years, different increment duration
 Size after 6th build: 548 KSLOC mostly in Java
 Average staff on project: ~20
Copyright © USC-CSSE
•
10/23/13
Quality Management Platform
(QMP) Project
15
10/23/13
Comparison of trend lines
(continued)
QMP
250.00
y = 27.851ln(x) + 46.68
R² = 0.0772
200.00
y = 40.124e0.1125x
R² = 0.0722
150.00
QMP
Log. (QMP)
Expon. (QMP)
50.00
y = 49.111x0.1749
R² = 0.0219
0.00
1
2
3
4
5
Copyright © USC-CSSE
Power (QMP)
100.00
6
16
6/27/2016
•
Logarithmic is best fit in most observed real-world cases
•
Trend line alone is not enough for reasonably precise
prediction of effort for next increment
•
=> Additional predictors needed
•
Additionally, we have 22 COCOMO II cost drivers that
all can influence the decline for the next given
increment. Examples: Complexity (CPLX), Personnel
Continuity (PCON), Reliability (RELY), Architectural
Resolution (RESL).
Copyright © USC-CSSE
Trend line summary
17
6/27/2016
Trend line summary
Normalized Productivity Trendlines
1.20
Cisco streaming
Cisco unnamed
1.00
XP 1
XP 2
QMP
System of Systems
0.60
ODA
Vu 5
0.40
Linear (Cisco streaming)
Linear (Cisco unnamed)
Linear (XP 1)
0.20
Linear (XP 2)
Linear (QMP)
0.00
1
-0.20
2
3
4
5
6
7
8
Linear (System of Systems)
Linear (ODA)
Copyright © USC-CSSE
Productivity
0.80
18
10/23/13
Lehman’s Laws and IDPD -1
•
1st Law: Continuing Change
 Description
 Continuing Change or loss of quality/usefulness
 Application to IDPD
 Maintenance necessary to keep up quality/usefulness
2nd Law: Increasing Complexity
 Description
 Increasing complexity unless effort applied to reduction
 Application to IDPD
 Integration work needs to be done in terms of integration,
documentation, adaptation
Copyright © USC-CSSE
•
19
10/23/13
Lehman’s Laws and IDPD -2
•
3rd Law: Fundamental Law of Program Evolution
 Description
 Evolutionary dynamics are self-regulating
 Application to IDPD
 Similar parameters should yield similar results
 Cover cannot get pulled in several directions at the same time
4th Law: Conservation of Organizational Stability
 Description
 Global activity rate is statistically invariant
 Application to IDPD
 Beyond a certain upper limit, adding more resources cannot benefit
system, therefore no escaping IDPD by committing them.
Copyright © USC-CSSE
•
20
10/23/13
Lehman’s Laws and IDPD -3
•
5th Law: Conservation of Familiarity
 Description
 Mental maintenance has to be performed
 Application to IDPD
 Mastery of the system will have to keep up with the increments
and there is an upper bound to the beneficial effort (4th law), so
training will reduce productivity
6th Law: Continuing Growth
 Description
 Functionality must continually increase to maintain user
satisfaction
 Application to IDPD
 Existing older increments must increase functionality to the
detriment of newer ones, taking away productivity
Copyright © USC-CSSE
•
21
10/23/13
Lehman’s Laws and IDPD -4
•
7th Law: Declining Quality
 Description
 System quality will appear to be declining without rigorous
maintenance, adaptation to environmental changes
 Application to IDPD
 Same as continuing change
8th Law: Feedback System
 Description
 Evolution processes are multi-level, multi-loop, multi-agent
feedback systems
 Application to IDPD
 Parameters of all increments are relevant within the increments
and to other increments
Copyright © USC-CSSE
•
22
10/23/13
•
Evaluate whether other sets of Software Engineering
laws suggest that IDPD exists.
•
Collect data in order to verify if the laws are supported
in actual incremental projects.
•
Map the extent of the relevance of individual laws to a
given incrementally developed system to parametric cost
drivers in order to predict the IDPD factor applying to
that project.
•
Research whether different types of incrementally
developed systems, such as applications versus
infrastructure software, have significantly different
characteristics regarding how much the individual laws
apply to them.
Copyright © USC-CSSE
Outlook
23
10/23/13
•
CSSE’s tool for cost estimation
•
Active development and support
•
Adaptation to IDPD in multiple steps
•
First step is to have same level of productivity decline
for all increments
•
Later, levels can be set per increment
Copyright © USC-CSSE
Outlook for COINCOMO
24
10/23/13
Conclusion
When reviewing data collected from incrementally
developed software and systems, a more detailed picture
emerges:
 Laws 1, 2, and 6 are generally compatible with the overall
trends in the IDPD data.
 Laws 3-5 imply that IDPD quantities are relatively constant
from increment to increment. However, our IDPD data
rejects such a hypothesis.
 Laws 7-8 are external to the phenomenon involved in our
IDPD data.
Copyright © USC-CSSE
•
25
10/23/13
Hofstadter's law
•
Hofstadter's Law: It always takes longer than you
expect, even when you take into account Hofstadter's
Law.
Copyright © USC-CSSE
— Douglas Hofstadter
26
Copyright © USC-CSSE
Questions?
27
10/23/13