Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Software environmentalism - Tudor Girba - Codemotion Amsterdam 2016

279 views

Published on

We produce software systems at an ever increasing rate, but our ability to get cleanup after older systems does not keep up with that pace. An IDC study showed that there are some 10k mainframe systems in use containing some 200B LOC. This shows that software is not that soft, and that once let loose systems produce long lasting consequences. Because of the impact of our industry, we need to look at software development as a problem of environmental proportions. We must build our systems with recycling in mind. As builders of the future world, we have to take this responsibility seriously.

Published in: Technology
  • Be the first to comment

Software environmentalism - Tudor Girba - Codemotion Amsterdam 2016

  1. 1. software environmentalism @girba
  2. 2. 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.
  3. 3. 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.
  4. 4. 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.
  5. 5. 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
  6. 6. @girba
  7. 7. moosetechnology.org @girba
  8. 8. moosetechnology.org humane-assessment.com @girba
  9. 9. moosetechnology.org humane-assessment.com pharo.org @girba
  10. 10. moosetechnology.org humane-assessment.com pharo.org gtoolkit.org @girba
  11. 11. moosetechnology.org humane-assessment.com pharo.org gtoolkit.org @girba aito.org
  12. 12. moosetechnology.org humane-assessment.com pharo.org gtoolkit.org @girba aito.org demodriven.com
  13. 13. moosetechnology.org humane-assessment.com pharo.org gtoolkit.org @girba aito.org demodriven.com feenk.com
  14. 14. I help teams to not read code @girba
  15. 15. development
  16. 16. development
  17. 17. decision development
  18. 18. development decision assessment humane-assessment.com
  19. 19. context matters
  20. 20. only constraining functionality is not enough
  21. 21. software systems have emergent structures
  22. 22. have the right to build upon recyclable systems
  23. 23. have the right to build upon recyclable systems have the responsibility to produce recyclable systems
  24. 24. have the right to build upon assessable systems have the responsibility to produce assessable systems
  25. 25. mcluhan / culkin
  26. 26. query data navigation
  27. 27. code navigation
  28. 28. mcluhan / culkin
  29. 29. WidgetB WidgetA Widget Theme
  30. 30. WidgetB WidgetA Widget Theme
  31. 31. have the right to build upon assessable systems have the responsibility to produce assessable systems
  32. 32. @girba

×