Download to read offline
![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) { ... }](https://image.slidesharecdn.com/2015-12-benevol-software-environmentalism-160501064747/75/Beyond-software-evolution-Software-environmentalism-25-2048.jpg)
![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;
}](https://image.slidesharecdn.com/2015-12-benevol-software-environmentalism-160501064747/75/Beyond-software-evolution-Software-environmentalism-27-2048.jpg)
Uploaded byTudor Girba
Beyond software evolution: Software environmentalism
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.
More Related Content
Similar to Beyond software evolution: Software environmentalism
Beyond software evolution: Software environmentalism
- 1. beyond software evolution: softwareenvironmentalism @girba
- 2. an E-type systemmust 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 -745 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 overthat 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 ITPro 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 firmshave 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 systemmust 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.
- 9.
- 10.
- 11.
- 12.
- 13.
- 14.
- 15. I help teamsto not read code @girba
- 16. I help teamsto not read code @girba
- 18.
- 19. ... Description description; Value ... Boolean actualValue BooleanValue ... ... ...Value Valuevalue; ... if (value == null) { ... }
- 20. accept(Visitor) Description description Value accept(Visitor) Boolean actualValue BooleanValue accept(Visitor) ... ...Value Valuevalue; ... if (value == null) { ... }
- 21.
- 22. accept(Visitor) boolean isUndefined() Description description Value accept(Visitor) BooleanactualValue BooleanValue accept(Visitor) ... ...Value accept(Visitor) boolean isUndefined() UndefinedValue Value value; ... if (value == null) { ... }
- 23. accept(Visitor) boolean isUndefined() Description description Value accept(Visitor) BooleanactualValue BooleanValue accept(Visitor) ... ...Value accept(Visitor) boolean isUndefined() UndefinedValue Value value; ... if (value.isUndefined()) { ... }
- 24. Value value; ... if (value== null) { ... }
- 25. valueClass := selfallModelTypes 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 methodcan 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.
- 39.
- 40.
- 54.
- 57.
- 59. have the rightto build upon recyclable systems
- 60. have the rightto build upon recyclable systems have the responsibility to produce recyclable systems
- 61. have the rightto build upon assessable systems have the responsibility to produce assessable systems
- 65.
- 66.
- 67.
- 68.
- 76.
- 77.
- 78. have the rightto build upon assessable systems have the responsibility to produce assessable systems
- 79. beyond software evolution: softwareenvironmentalism @girba
- 80.