The document discusses compound annual growth rates (CAGRs) that were calculated based on software size data from six products described in previous Impact columns over periods ranging from seven to 22 years. The CAGRs for the six products fell within a surprisingly narrow range of 1.11 to 1.29, providing empirical evidence that software growth averages around 15% per year. The findings suggest that claims about software doubling every two years align with observed growth rates.

1. beyond software evolution:
software environmentalism
@girba

2. an E-type system must be
continually adapted or it becomes
progressively less satisfactory
as an E-type system evolves, its
complexity increases unless work is
done to maintain or reduce it
Lehman, Belady 1974

3. 074 0 -74 5 9/12 / $ 31.0 0 © 2 012 I E E E J U LY/AUGU S T 2012 | IE E E S O F T WA R E 19
IMPACT
Editor: Michiel van Genuchten
Open Digital Dentistry
genuchten@ieee.org
Editor: Les Hatton
Kingston University
l.hatton@kingston.ac.uk
IMPACT
Compound Annual
Growth Rate for Software
Michiel van Genuchten and Les Hatton
Six impact columns published over the past three years
and a couple of precisely measured products let us
calculate the compound annual growth rate.
MANY OF US subscribe to the belief
that software is growing. This is gen-
erally fueled by apocryphal stories, rea-
soning that as hardware speeds up, the
software seems to slow down almost in
proportion, and because software can’t
just slow down, there must be more
instructions for it to carry out; there-
fore, it must be growing. But how fast?
Statements such as “software doubles
every two years” are still sufficient for
many audiences due to a lack of empiri-
cal data. There is some data available
from open source products, but size
data from industrial products over a
longer period of time is scarce.
In this installment of the Impact de-
partment, we want to discuss software
growth in more detail, a discussion we
base on the data published in previous
installments that cover products (10
since 2010). Six out of the 10 provide
the software size at a minimum of two
points in time.1–6 This lets us calculate
the approximate growth rate over that
period of time. Table 1 contains the
data as previous-installment authors
have described it.
Note that these products vary in
application;
safety criticality (for instance,
magnetic resonance, oil explora-
tion, and flight management sys-
tems were characterized as safety
critical);
software size (orders of magnitude
difference, both at start and at the
end); and
team size (from a few engineers to
hundreds of them).
The sizing data covers periods rang-
ing from seven to 22 years. Note that
we don’t yet have enough data for de-
tailed statistical analyses, but the val-
ues are quite robust.
A Compound Annual Growth
Rate for Software
The last column of Table 1 states
the compound annual growth rate
(CAGR). CAGR is year-over-year
growth over some number of years. For
example, doubling in five years can be
explained by a CAGR of 1.15 (1.155 =
2.01). CAGR is often used in analysis
reports summarizing the expected fu-
ture growth of markets or revenue. The
CAGR of the six products listed fall
within a surprisingly small range. To be
clear, we didn’t cherry-pick these prod-
ucts based on their CAGRs, nor will we
in the future. The CAGR ranged from
1.11 to 1.29 for the six products listed.
Because software can’t just slow down,
there must be more instructions for it to
carry out; therefore, it must be growing.

4. growth rate over that
Table 1 contains the
-installment authors
e products vary in
ality (for instance,
onance, oil explora-
ht management sys-
aracterized as safety
A Compound Annual Growth
Rate for Software
The last column of Table 1 states
the compound annual growth rate
(CAGR). CAGR is year-over-year
growth over some number of years. For
example, doubling in five years can be
explained by a CAGR of 1.15 (1.155 =
2.01). CAGR is often used in analysis
reports summarizing the expected fu-
ture growth of markets or revenue. The
CAGR of the six products listed fall
within a surprisingly small range. To be
clear, we didn’t cherry-pick these prod-
ucts based on their CAGRs, nor will we
in the future. The CAGR ranged from
1.11 to 1.29 for the six products listed.
growing.

5. May❘ June2000 IT Pro 171520-9202/00/$10.00 © 2000 IEEE
Leveraging
Legacy
System
Dollars for
E-Business
Len Erlikh
A
lthough many firms have rapidly and
enthusiastically adopted distributed
architectures, many more are stuck
with mainframe-based mission-critical
systems that continue to isolate them from their
partner, supplier, and customer systems. Indeed,
IDC estimates there are more than 10,000 large
IBM mainframe sites worldwide with 200 billion
lines of legacy code still in use.
Most companies want to transform their appli-
cations to meet new business
demands, but because legacy
systems tend to be unwieldy,
monolithic, and inflexible,
many firms regard modern-
ization assomewhere between
improbable and impossible.
Reeling from the Y2K deba-
cle and saddled with years of
application backlog,the most
these companies can hope for
is to keep their legacy system
alive.
And keeping it alive is get-
ting more expensive.According to an informal in-
dustry poll, 85 to 90 percent of IS budgets goes to
legacy system operation and maintenance.It is also
becoming harder to find qualified personnel to do
the maintenance. All of this makes it difficult to
add new functionality and keep up with business
requirements.
The ideal solution is to transform legacy systems
to newer,more productive platforms so that com-
panies can exploit faster and cheaper develop-
ment technologies,like Java and XML (Extensible
Markup Language).The focus then shifts to func-
tionality, not the infrastructure, which means a
company can respond more quickly to its chang-
ing business requirements and technology
enhancements.
NOT A TRIVIAL PURSUIT
But this legacy transformation isn’t trivial,
which is why many companies avoid it. The e-
business architecture emphasizes just about
everything foreign to a legacy system—distrib-
uted heterogeneous platforms, component
encapsulation, the merging of standards, open-
ness. The challenge is to preserve the wealth of
captured business knowledge and have the sys-
tem fit into the component world of the new e-
architecture.
RescueWare, legacy transformation software
from Relativity Technologies, breaks business
knowledge into stand-alone pieces, or e-compo-
nents.The e-components are basically collections
of objects that perform specific business services,
have clearly defined application program inter-
faces (APIs),and are accessible through modern
industry-standard protocols.
Because these e-components encapsulate indi-
vidual business processes and because other com-
ponents can freely access them, a company can
more precisely control individual business
processes. This divide-and-conquer approach
allows companies to do rapid concurrent devel-
opment. Each large-scale business process
becomes a self-contained unit of manageable size,
making it easier to deploy in a Web-based envi-
ronment.
Legacy transformation in RescueWare begins
with understanding what parts of the legacy sys-
tem are worth transitioning to the e-business
Legacy Modernization Resources
Hunting forBusiness Rules
Inside
Converting a
monolithic legacy
system to stand-alone
components can turn
this source of business
knowledge into a
competitive edge.

6. A
lthough many firms have rapidly and
enthusiastically adopted distributed
architectures, many more are stuck
with mainframe-based mission-critical
systems that continue to isolate them from their
partner, supplier, and customer systems. Indeed,
IDC estimates there are more than 10,000 large
IBM mainframe sites worldwide with 200 billion
lines of legacy code still in use.
Most companies want to transform their appli-
cations to meet new business
demands, but because legacy
systems tend to be unwieldy,
monolithic, and inflexible,
many firms regard modern-
ization assomewhere between
improbable and impossible.
Reeling from the Y2K deba-
cle and saddled with years of
NOT A TR
But this
which is w
business a
everything
uted hete
encapsula
ness. The c
captured b
tem fit into
architectur
RescueW
from Rela
knowledge
nents.The
of objects t
have clear
faces (API
industry-st
rting a
ithic legacy
to stand-alone
nents can turn
urce of business

7. an E-type system must be
continually adapted or it becomes
progressively less satisfactory
as an E-type system evolves, its
complexity increases unless work is
done to maintain or reduce it
Lehman, Belady 1974

8. @girba

9. moosetechnology.org
@girba

10. moosetechnology.org humane-assessment.com
@girba

11. moosetechnology.org humane-assessment.com
pharo.org
@girba

12. moosetechnology.org humane-assessment.com
pharo.org
gt.moosetechnology.org
@girba

13. moosetechnology.org humane-assessment.com
pharo.org
gt.moosetechnology.org
demodriven.com
@girba

14. moosetechnology.org humane-assessment.com
pharo.org
gt.moosetechnology.org
demodriven.com
feenk.com
@girba

15. I help teams to
not read code
@girba

16. I help teams to
not read code
@girba

18. ...
Description description;
Value
...
Boolean actualValue
BooleanValue
...
...
...Value

19. ...
Description description;
Value
...
Boolean actualValue
BooleanValue
...
...
...Value
Value value;
...
if (value == null) { ... }

20. accept(Visitor)
Description description
Value
accept(Visitor)
Boolean actualValue
BooleanValue
accept(Visitor)
...
...Value
Value value;
...
if (value == null) { ... }

21. accept(Visitor)
Description description
Value
accept(Visitor)
Boolean actualValue
BooleanValue
accept(Visitor)
...
...Value
accept(Visitor)
UndefinedValue
Value value;
...
if (value == null) { ... }

22. accept(Visitor)
boolean isUndefined()
Description description
Value
accept(Visitor)
Boolean actualValue
BooleanValue
accept(Visitor)
...
...Value
accept(Visitor)
boolean isUndefined()
UndefinedValue
Value value;
...
if (value == null) { ... }

23. accept(Visitor)
boolean isUndefined()
Description description
Value
accept(Visitor)
Boolean actualValue
BooleanValue
accept(Visitor)
...
...Value
accept(Visitor)
boolean isUndefined()
UndefinedValue
Value value;
...
if (value.isUndefined()) { ... }

24. Value value;
...
if (value == null) { ... }

25. valueClass := self allModelTypes entityNamed: #'Value'.
valueVariables := valueClass withSubclassHierarchy
flatCollectAsSet: #structuresWithDeclaredType.
valueVariables select: [ :each |
(('*', each name , ' != null*') match:
each belongsTo sourceText) or: [
('*', each name , ' == null*') match:
each belongsTo sourceText ] ]
Value value;
...
if (value == null) { ... }

26. /**
* The method can return null
*/
Value doSomething() {
...
return value;
}

27. valueMethods := valueClass withSubclassHierarchy
flatCollectAsSet: #behavioursWithDeclaredType.
valueMethods select: [:each |
each comments anySatisfy: [:c |
'*null*' match: c sourceText ] ]
/**
* The method can return null
*/
Value doSomething() {
...
return value;
}

38. development

39. development

40. decision
development

54. mcluhan / culkin

57. mcluhan / culkin

59. have the right to build upon
recyclable systems

60. have the right to build upon
recyclable systems
have the responsibility to produce
recyclable systems

61. have the right to build upon
assessable systems
have the responsibility to produce
assessable systems

65. mcluhan / culkin

66. apply
analysis
interpretconfident?
hypothesize

67. existing
analysis?
apply
analysis
interpretconfident?
hypothesize

68. existing
analysis?
apply
analysis
interpretconfident?
craft
analysis
hypothesize

76. decision
development

77. decision
assessment
development
humane-assessment.com

78. have the right to build upon
assessable systems
have the responsibility to produce
assessable systems

79. beyond software evolution:
software environmentalism
@girba

80. @girba