Archive | March, 2012

Software Evolution: An Introduction

16 Mar

I. Introduction

Studying software evolution has been ongoing since 70s. The fundamental characters in software design methodology, the nature of uncertainty in software application, and software changes were studied as the consequence of software evolution research. These efforts continued with software development process modeling for process control and process improvement while software evolution laws were contemplated [1]. In the paper “The Role and Impact of Assumptions in Software Development, Maintenance and Evolution” [2] M.M. Lehman has summarized his endeavor in software evolution study over 35 years. As it has explicitly given in the title of the article, “assumptions” is the key in the life of software:

“The presence and impact of assumptions on systems in general, computing systems in particular and software most especially has gone largely unrecognized over the past fifty or so years. It is now apparent, with hindsight self-evident, that assumptions, explicit or implicit, that have become invalid as a consequence of changes in an application or its operational domains, and the properties of those assumptions previously ignored that have now become relevant, are in large measure responsible for the need to continually upgrade and evolve software. [2]”

In Lehman’s view, software evolution implies “to widen the scope of the software, adapting or extending the domains over which it can be expected to execute satisfactorily [2].”

Recognized that studies in software engineering were inadequate just by following traditional engineering methodology, researchers in software engineering initiated the exploration of studies in complex systems and made the efforts to extend software evolution studies analogous to evolutionary theories of biology. Believed that software being diverse in nature, varying from abstract machine code and assembly language to more formal programming languages, applications, user-created macros, and scripts, Kitchin and Dodge describe a set of hierarchically organized entities of increasing complexity parallel with that of organic entities shown in figure 1 [3]. This figure portrays a conceptualized view of different scales of software.

 

Figure 1. A conceptualization of software compared with biological entities/populations at programming language level [3]

Another view portrayed in figure 2, a courtesy of the blog host at softwarecreation.org [4] , is showing a software evolution cycle at process level regarding software development life cycle management.

Figure 2. A conceptualization of software evolution in terms software life cycle management [4]

Comparing software evolution with “generic theories of evolution, particularly with Dawkins’ concept of replicator” [5] a richer study of software evolution has trail blazed. Similarly, Nehaniv et al [6] have been “studying identified properties that give biological and artifact evolution the capacity to produce complex adaptive variation.” The study attempts to shed light on “how to enhance the evolvability of software systems in general and of evolutionary computation in particular. [6]”

Through reading both Steve J. Gould’s The Structure of Evolutionary Theory [7] and Richard Dawkins’ The Selfish Gene [8], The intention of this blog is to explore how Darwinian’s evolution theory and its new enhanced views could benefit the continuation of software evolution studies. Viewing software as complex adaptive systems (https://he98anything.wordpress.com/2012/03/15/software-as-complex-adaptive-system/?preview=true&preview_id=9&preview_nonce=797878b848)

may shed light on how software resembles the biological ones as well as on how we can take advantages of Darwinian’s evolution theory and make use of it in software engineering.

II. Evolution Approach to Software Development

An evolution approach described here is directly inspired through reading S.J. Gould’s The structure of Evolution Theory [7]. As Gould emphasized in this huge volume book, Darwin’s evolution theory had three principles of central logic that define “the themes of the deepest and most persistent debate – as, in a sense, they must because they constitute the most interesting intellectual questions that are theory for causes of descent with modification must address.”

A. Darwinian’s evolution theory according to S.J. Gould

Darwinian’s three principles are best exemplified under the three general categories: agency, efficacy, and scope.

Agency—Organisms act as the locus of selection and all higher order emerging by the analog of Adam Smith’s invisible hand, from the unconscious “struggles” of organisms for their own personal advantages as expressed in differential reproductive success.

Efficacy—The true cause in natural selection is admittedly weak and negative force and could under certain assumptions about the nature of variation, act as the positive mechanism of evolutionary novelty, that is , could “create the fit” as well as eliminate the unfit by slowly accumulating the positive effects of favorable variations through innumerable generations.

Scope—the full sufficiency in extrapolation from building up small changes, microevolutionary process, to the extend through the immensity of geological time capable of generating the entire pageant of life’s history, both in anatomical complexity and taxonomic diversity without further causal principles required.

In The structure of Evolution Theory Gould made his unique contribution to evolutionary theories “by advocating an independent set of macroevolutionary principles that expand, reformulate, operate in harmony with, or work orthogonally as additions to, the extrapolated, and persistently relevant (but not exclusive, or even dominant) forces of Darwinian microevolution.” It is the Gould’s macroevolutionary thinking that has inspired this research to apply and propose the evolution approach to software development.

B. Evolution approach to software development

“Evolution” in evolution approach to software development, has two kinds of implications. Literally, as defined in the online resource: dictionary.com [9] with two slightly different connotations: One is interpreted as any process of formation or growth, or development as in the evolution of a language; the other is interpreted as a process of gradual, peaceful, progressive change or development, as in social or economic structure or institutions. The two closely related to the meanings of Lehman’s software evolution research [1,2].

On the other hand, biologically, “evolution” means change in the gene pool of a population from generation to generation by such processes as mutation, natural selection, and genetic drift. Clearly, this has been the popular interpretation of Darwinian’s evolution theory. Gould has keenly observed [7] that “no evolutionary assertion has been more commonly advanced in textbooks, or more superficially (and almost nonchalantly) proclaimed by fiat, than the claim that adaptation by natural selection must be fully sufficient to render life’s entire history.”

Questioning the power of a well-formulated theory to explain the origin of multicellularity, the rise of mammals, and the eventual emergence of human intelligence, S.J. Gould made the suggestion of using a grand analogy as a speciational basis for macroevolution.

Gould then explains with punctuated equilibrium that is the essence to validate the macroevolutionary theory, in which the empirical pattern of stasis and abrupt geological appearance remain the standard testimony. By individuating species (and thereby establishing the basis for an independent theoretical domain of macroevolution) Punctuated Equilibrium ratifies an effective realm of macroevolutionary mechanics based on recognizing species as Darwinian individuals.

Followed with the speciational reformulation of macroevolution, Gould used the “life’s little joke,” as the counter example, in which “man [all of us] is the measure of all things.” As it has been the cardinal example, concepts of human evolution long labored under the restrictive purview (now known to be empirically false) of the so-called “single species hypothesis.”

Speciation reformulation has been summarized with the analogy by Gould as “the species as the macroevolutionary analog of the organism as the atom of microevolution.” (p893 in [7]) Acknowledging to his inspirational source from Ernst Mayr (1992 p48) Gould quoted “speciational evolution is Darwinian evolution at a higher hierarchical level. The importance of this insight can hardly be exaggerated.” (p895 in [7])

Lastly, as in the title of chapter 11 of his book, The integration of Constraint and adaptation (structure and function) in Ontogeny and Phylogeny: Structural Constraints, Spandrels, and the Centrality of Exaptation in Macroevolution, Gould argued that species must exapt the rich potentials supplied by structural and historical constraints of spandrels and other Miltonic “things” emplaced into the exaptive pool against (or orthogonally to ) these restricting tendencies of natural selection, where terms such as “evolvability”, “higher Darwinism”, and “this view of life” come to being. This is Gould’s resolution to deal with macroevolutionary paradox, i.e., “constraint ensures flexibility whereas selection crafts restriction.”

Mapping Gould’s macroevolutionary theory on to software development we get a list of the three as follows:
1. Punctuated equilibrium describes software architecture generational changes,
2. Species reformulation describes software product’s changes upon its environmental changes that may be considered as software product generational changes,
3. Exaptation describes architecture minor changes.

On the other hand, mapping Darwinian’s evolution theory at microevolutionary scale, we also get a list of the three as follows:
1. Design choices (including development tools) are considered as natural selection,
2. Different team solutions are considered as mutations/variations (including development methodologies),
3. Same domain problem may share optimally designed algorithms to implement since these algorithms may be eternally useful and heritable as long as problems addressable by these algorithms exist.

C. Discussion

A couple of points will be addressed here. First, the division in the analytical thinking, macro-level analyses versus micro-level analyses, has been ongoing in almost all scientific endeavors. An example can be found in my recent software architecture paper [10], which enhance software evolution study presented here.

If we compare design choices in software development as the natural selection in Darwinian’s evolution theory of biology, it must be true in the sense that only masterpiece designs would be remembered (appreciated, enjoyed, passed on) for generations to come. The fact that software creation was viewed as an art more than a science [11] seems more so now than that when it was said by Donald Knuth in his Turing Award speech 37 years ago.

Obviously, it is much easier to invalidate any theory than to build one. One counter example will do to expose the weakness of a theory. When one is trying to build one, many examples must be presented to support, even though the process itself is evolutionary. The plausible exists in other software practitioners who have similar experience with the originators, and who resonate with the essence given in the theory by means of understanding what have built up through persuasion. That’s what I am trying to do in this writing. I am distilling a theory from my years of working as a software developer.

To quote Richard Dawkins’ words in his The Selfish Gene to end my presentation in this writing,

“I am an enthusiastic Darwinian, but I think Darwinism is too big a theory to be confined to the narrow context of the gene. The gene will enter my thesis as an analogy, nothing more.” (P191 in [8])

My macro-level thinking with Steve J. Gould’s macroevolutionary theory in Darwinian’s Evolutionary Theory of biology applying to the software evolution is no more than using analogy to bring about a better understanding of software development through understanding software being the inevitable artifact created by its originators and forced upon the world we live.

References

[1]M. M. Lehman, D. E. Perry, and J. F. Ramil, “Implications of evolution metrics on software maintenance,” in Proc. of the 1998 IEEE Intl. Conference on Software Maintenance Bethesda, Maryland, November 1998.
[2]M. M. Lehman, “The Role and Impact of Assumptions in Software Development Maintenance and Evolution,” in Proc. Intl. IEEE Workshop on Software Evolvability 2006, 3-14, IEEE Computer Society Press.
[3]M. Dodge and R. Kitchin. Code/space : software and everyday life. Cambridge, Mass. : MIT Press, c2011.
[4] http://softwarecreation.org/2008/what-software-development-can-learn-from-biological-evolution

[5]S. Cook, R. Harrison, M.M. Lehman, and P. Wernick, “Evolution in Software Systems: Foundations of the SPE Classification Scheme,” J. Softw., Maint., and Evol., Res. Pract. 2006, Vol18, p1-35.
[6]C.L. Nehaniv, J. Hewitt, B.Christiansen, and P.Wernick, “What Software Evolution and Biological Evolution Don’t Have in Common,” Second International IEEE Workshop on Software Evolvability, 24-24 Sept. 2006, P58-65, doi: 10.1109/SOFTWARE-EVOLVABILITY.2006.18.
[7]Gould, Steve Jay. The Structure of Evolution Theory. Belknap Press of Harvard University Press; 1ST edition, March 21, 2002.
[8]Dawkins, Richard. The Selfish Gene: 30th Anniversary Edition. Oxford University Press, USA; 30th Anniversary edition, May 25, 2006.
[9] http://dictionary.reference.com/browse/evolution

[10]B.H. Wu, “Let’s Enforce a Simple Visualization Rule in Software Architecture,” Nanjing, China ICIST 2011, an IEEE conference, March 26-27, 2011, p427-433. Doi: 10.1109/ICIST.2011.5765283.
[11]Knuth, Donald E. Literate Programming (Center for the Study of Language and Information – Lecture Notes) .Center for the study of Language and Information; 1 edition, June 1, 1992.

Software as Complex Adaptive System

15 Mar

Abstract

An Evolution View of Software as Complex Adaptive Systems enriches the current study on software evolution. This blog attempts to analyze modern software viewed as a complex adaptive system (CAS) by going through Paul Cilliers’ characteristics of CAS. By comparing software populations with biological populations, an evolution approach to software development emerges. The benefit of the approach is rather practical targeting to promote the understanding of modern software analogous to biological complexity and to guide the progress in software development in order to improve software quality and software development productivity. The writing will be composed in two parts. The first part will be titled as Software as Complex Adaptive Systems and the second part is called An Introduction to Software Evolution

I.  Software as Complex Adaptive Systems

A. Software


Software is a digital form of solving problems that we encounter in our daily living. As the subject of software engineering, software systems have been studied for more than forty years. How software life cycle management should be carried out has been contemplated. An effort to model software maturity analogous to the maturity process of human beings has enabled us with a novel understanding: what software is and how to achieve effective and efficient software development through its guidance [1]. The study of software evolution can add another dimension to this maturity model and may be further empowering software engineers in the pursuit of excellence in software development. Introducing the view of software being complex adaptive systems under the study of complexity science is one approach to the software evolution study. Therefore let us define complex systems.

B. Complex systems


Paul Cilliers [2] offers the following five essential characteristics of complex systems:
1. A complex system consists of a large number of elements.
2. These elements interact dynamically via information exchanges non-deterministically. The interactions may be described technically as fairly rich, non-linear, short ranged, and recurring.
3. A complex system interacts with its environment openly. The scope of the system is usually determined by the purpose of the system description, thus it is often influenced by the position of the observer, i.e., how the observer is framed.
4. Complex systems have a history and must be viewed both synchronically and diachronically.
5. Complexity is the result of a rich interaction of simple elements that only response to the limited information presented to them.
Looking at this list, dealing with complex systems clearly requests our continuous efforts to comprehend such systems externally. On the other hand, the nature of the system may be interpreted as adaptive internally. This leads us to define Complex Adaptive Systems next.

C. Complex Adaptive Systems (CAS)


Given by Wikipedia CAS page [3] , the ideas and models of CAS are essentially evolutionary, grounded in modern chemistry and biological views on adaptation and exaptation, as well as the models simulating the economics and social systems. Typical examples are the stock market, the political parties at national, state, or local levels, social animals such as ant colonies, the brain and the immune system of animals, to name a few. Here I argue that the simulation programs to model either the biological or the social and economic systems are complex adaptive software systems. According to Wikipedia page [3], John Holland has provided the definition of CAS as the follows:

“Complex adaptive systems are systems that have a large numbers of components, often called agents, which interact and adapt or learn.”

Assume this is true, the words “adapt” and “learn” have to be exchangeable. In this sense, studying CAS is recognized as studying machine intelligence and it is beyond this blog to address.
Let us keep our focus on software as CAS and let us find out how software systems can be mapped using five characteristics of complex systems given by Cilliers in the above list.

D. Software as complex adaptive system


First, a complex system consists of a large number of elements.

This character is manifested by the state of the art of computer on which software is executed. Stated famously by F.P. Brooks 25 years ago [4]:

“Digital computers are themselves more complex than most things people build: They have very large numbers of states. This makes conceiving, describing, and testing them hard. Software systems have orders-of-magnitude more states than computers do.”

Indeed, computers are the most complex machines in human creative history. The fact that software is the responsible part for such complex machines to work qualifies software being a complex system. Software instructs computer hardware about what to do by means of lines of code, instructions and algorithms, i.e., the executable routines and programs capable to complex digital functions. Nowadays, it is common that a PC or a laptop has a dual-core and that a desktop has a multicore, much less about servers in the cloud computing. Each core is the equivalent to a supercomputer in Brooks’ time 25 years ago. The complexity of digital computers in Brooks’ term has two levels of implications: in the multi-core chips at the macro-level and in ever thinner (45-16nm from current to foreseeable future) transistors/IC at the micro-level. As it has explicitly stated by Brooks, this complexity in hardware had made conceiving, describing, and testing hard. Along with the hardware complexity growth, software complexity grows even faster.

Second, these elements interact dynamically via information exchanges non-deterministically. The interactions may be described technically as fairly rich, non-linear, short ranged, and recurring.


This character is manifested by the state of the art of computing technology. For any particular software product, there are many different computer platforms, programing languages, software development technologies (tools and frameworks) and methodologies (software development processes), which may be selected for its development. It is practically impossible to test a modern software system end to end fully. This is the root cause for software to be non-deterministic and possibly recurring.

Third, a complex system interacts with its environment openly. The scope of the system is usually determined by the purpose of the system description, thus it is often influenced by the position of the observer, i.e., how the observer is framed.


The end users of software systems are people. People as part of the software running environment make the interaction between software and its operational environment open. To illustrate this characteristic in software, let us quote Chun’s lucid description in her software study: Programmed Visions [5]. “Software is extremely difficult to comprehend. Who really knows what lurks behind our smiling interfaces, behind the objects we click and manipulate? Who completely understands what one’s computer is actually doing at any given moment? Software as metaphor for metaphor troubles the usual functioning of metaphor, that is, the clarification of an unknown concept through a known one.” This sensible description of wanting to understand the complexity of software, but incapable of doing so from a user point of view has captured exactly why we can categorize software being “a complex system interacts with it environment openly.” When a user’s understanding of the system is ambiguous, the user’s interactions with the systems are bounded to be unpredictable.

Forth, complex systems have a history and must be viewed both synchronically and diachronically.


This character is manifested by software being a product or a product family serving users. To understand it and to select an appropriate one requires our inquiry to its history and its peer/competitive products. That is, we want to look at the depth and breadth of a software product and its product family. This character is the driven force for researchers and developers to take the evolutionary view of software.

Fifth, complexity is the result of a rich interaction of simple elements that only response to the limited information presented to them.


This characteristic reflects the fact that how software is developed, i.e., one component at time. Each component can be implemented through applying appropriate software development methodologies that depends on what programming technologies are being used.

This mapping is to prepare us to look at how comparison between biological entities (populations) and software systems in order to take advantages of biological evolutionary theories to serve software evolution study. It will be given in next blog.

[1] B.H. Wu, “Modeling Software Maturity: a Software Life Cycle Management Approach”, to appear in the proceedings of  ICIST 2012, an IEEE conference,  Wushan, China, March 23-25, 2012, in press.

[2] P. Cilliers, Complexity and Post Modernism. http://www.amazon.com/Complexity-Postmodernism-Understanding-Complex-Systems/dp/0415152879

[3] http://en.wikipedia.org/wiki/Complex_adaptive_systems

[4]. Frederick P. Brooks, Jr, “No Silver Bullet-Essence and Accident in Software Engineering,” Proceedings of the IFfP Tenth World Computing Conference, H. -J. Kugler, ed., Elsevier Science B.V.,Amsterdam, NL(1986) pp. 1069-76.

[5] W.H.Y. Chun, Programmed Visions. Cambridge, Mass. : MIT Press, c2011.

Nature vs. Nurture

14 Mar

It is not too far off if we run the analogy between a life of a human beings maturity process and that of software. Arguably, human lives start from their conceptions. A life goes through the pregnancy, the birth, the nursing of a baby, kindergarten, the twelve grades, college or technical schooling, the entry to the workforce, the prime of being an expert in whatever field, and the re-education naturally as desirable or as needed; each individual is scientifically developed and matured to reach our expected longevity while everyone of us being useful and enjoying our lives.

To a logic mind, it is remarkable how similar between a successful individual life and a successful software product. Let us continue this analogy to illuminate what software is and how to ensure software quality.

A.        The conception

How similar and interesting it is to see our broad range of reasoning used to conceive a life or an idea of creating software!  Without doubt, the forefront reason is the result of our passion and our love. It could also be an accidental or deliberated act strategically or tactically. One strategic software project that immediately jumped to my mind was the one D. L. Parnas wrote in his paper [1]. He voiced his concerns about the health of that project vociferously. Indeed, in the hindsight, one can see that the primary purpose of the project was strategically aligned with the national interests; it was ended with success because of the collapse of USSR. Meanwhile, there were plenty practical software products continued being useful with longevity. An immediate example would be the office automation products/suites. 

B.         The pregnancy

It is rather accurate to think of the software requirement development as the pregnancy stage of a human life. The process should be carried out by a responsible individual who is bringing such a life in the world. Although the stakeholders of a software system seemed much more and much diverse, the final decision for bringing about a particular software product ought to end with one who is responsible for it. Among evidences supporting such analysis can be found in the AIR JAM report [2]. Eventually, the requirement specification induced failure with  its skyrocketing cost as the symptom.

However, not all software projects can be associated with an individual’s responsibility. The requirements of those projects were part of the circumstances discussed by Neil Maiden in “Trust Me, I am an Analyst [3].” In his analysis, trust has been the highest importance. Although it makes some sense, arguably, the responsibility should be emphasized the most; specifically, what is desirable and what is feasible should be differentiated clearly in engineering sense under the responsibility of its software architect(s). 

Being a software development professional and specialized in software requirement engineering, one should not just be able to listen, but one should be able to participate, as those movie actors or investigating reporters, who actually are taking active roles in the subject they play or investigate, learning what are the needs by participating, such as a finical system running by bankers or an air traffic control system scheduling airplanes landing and taking off. Good actors can quickly make sense in the roles they play. Good software engineers can do the same as well.  It is for software engineers to do so because we understand the technologies used to create the software and we can bridge the gap between what are the desirable and what are the feasible.

 

C.         The education

As human beings, whether one is useful and influential or not, one is judged by their knowledge and their capability. Software product is the same in the ways it is built with efficient knowledge structures for problems they can address. The key to the efficient knowledge structures is the subject of studies in software architecture. A good software product with longevity must have excellent software architecture. Just as people in their work places, knowledgeable workers are resulted from their excellent educations, good software products come from good design and development. Architectural analysis is most important in software design. Good architecture is sustainable to software systems with continuously learning and continuously improving. 

D.        Entering workforce

If the commencement at the end of schooling is his entry into the workforce, the same is true for a software release to the real world. The software product then can be tested in the real world and used by its end users or placed on the market ready for use.  Arguably, the most important growth of a software product starts at this stage unlike the following descriptions of the software project management life cycle of the past:

We built what we were told to build, managing it the best we could; and after it was over, we breathed a sigh of relief (or despair) and moved on to the next project [4].

Here, Favaro’s word “over” is not the end of software life cycle management but the project delivery to the operational people and maintenance engineers. It signifies the ending of software development and the beginning of the software maintenance in the traditional software life cycle management sense. This might be applicable 30 years ago, but with modern software, the difference is that software matures through its use. The more its customers use it, the more feedback it can get for improvement. It is very important for college graduates to learn by doing in their work and to accumulate the real world knowledge during their working. The same is true whether a software product is popular or not at its entry point. We should judge how it grows and how its customers react to it. It is often the case that if its design is good it can grow better and serve better. 

Defects in software are inevitable just as the imperfection in teenagers; defects can be fixed while maturing within its life cycle. As a person learns and corrects their bad habits to become better fitting in the society; software defects may be fixed whatever and wherever surfaced while the software is being used.  This is all natural in the software maturing process.

Even though we don’t call a college graduate “version 2,” the graduate becomes a better “version” compared with the “version” at his high school commencement ceremony. He has learned more comprehensive knowledge as well as special knowledge in addition to his being trained for critical thinking through learning the knowledge at college. He is more capable of doing complex tasks and capable of serving the society better.

 Judging software is like judging people, we want to see how one is educated and capable.  In software, defects can be removed not only when it was found while being tested before entering the market, but also when it is found while being used. An HP study has shown that many defects of a software product may never have the chance to be exposed during its service. It depends on how its customers use of it [5]. Both code reviews and extra effort spent for defect removal advocated by experts of software development in the past [6] [7] may or may not be an efficient uses of developers time if the software is a commercial product or a freeware, which is typically developed in an Agile development environment, rather than those mission critical with potentially catastrophic effect [8] if anything goes wrong.

The author has proposed a model of software defects to address software product quality issues [9], which is also part of solutions under the software maturity modeling approach introduced here.

E.         Maturing with lifelong learning

At the prime of one’s professional career, this stage is most productive and motivational in one’s learning driven by unknowns provided that the more one learns, the more one may realize that what one did not know and wants to know.  The similar happens in software products. If a software product is useful, it promotes the needs to make the product even more useful. Improving a software product can be challenging but it is feasible. Demands for software changes can be given in two forms:

1.         A problem addressed by software may change when the environment that defines it has changed;

2.         The solution to the problem addressed by the software is improving.

To implement these changes, architectural changes may be necessary, and the cost of changes may be evaluated.

In describing software aging caused by those preventable changes, Parnas wrote:

Changes made by people who do not understand the original design concept almost always cause the structure of the program to degrade. Under those circumstances, changes will be inconsistent with the original concept; in fact, they will invalidate the original concept. Sometimes the damage is small, but often it is quite severe. After those changes, one must know both the original design rules and the newly introduced exceptions to the rules, to understand the product. After many such changes, the original designers no longer understand the product. Those who made the changes never did [10].

 This description is truly reflecting the reality in many legacy systems, but it does not have to be this way, if the responsibility of design is tied with individuals. A close analogy between software designers and architects of landmark buildings may be appropriate. Individual responsibility should be tied with the fame or the shame of the software systems, especially those important ones.   Many failures in Robert Charette’s survey article [2] can be avoid as the consequence of applying the software maturity model. In fact, tying the responsibility with the architects of the software system could be a two way street. It can be used as licensing approach for evaluating software architects if desirable, not for life but for a particular software system which is listened for the architect to build. This goes nicely with the suggestion made by Maiden saying that requirements analyst should show their previously successful work.

Another close analogy runs with how FAA issues licenses to pilots, where flying hours and the types of airplanes they operate are the primary indications of pilot’s skills. In fact, that is how pilots get rated. 

In her Quality Time column piece in IEEE Software, S.L. Pfleeger introduced Manny Lehman’s notion of programs (programs, Life Cycles and the Laws of Software Evolution, Proc. IEEE, IEEE, Piscataway, NJ Vol. 68, No. 9, Sept. 1980, pp1060-1076) to describe a system in terms of the way it relates to the environment in which it operates. She pointed out: “Unlike programs handled in the abstract, the real world contains uncertainties and concepts we do not understand completely.” In my analysis, the uncertainties are results of our not being able to test how our system is going to behave with certain input. The system behavior in response to untested situations may seem odd to users but it should not be seen as odd to developers when such is happening. She continued: “The more dependent a system is on the real world for its requirements, the more likely it is to change [11].” This is exactly the reason motivated me to write this blog, modeling software maturity as a life cycle management approach. In her article, Pfleeger summarized five laws of program evolution observed by Lehman: continuing change, increasing complexity, fundamental law of program evolution, and conservation of organizational stability (invariant work rate).  The first two of these five are what may be relevant now when we look at them twenty years later.  My detailed analysis to be written in another blog soon.

F.         Retiring

Similar to the story of Compact Disc, when the CDs came along, recording music on cassette was obviously inferior in terms of the sound quality, ease of retrieving, and  its storage capacity. Software products are retired due to its quality as well.  However, the differences between software and hardware change the dynamics in reality. The flexibility in software allows its quality to be improved infinitely, in theory. The same is true in software engineers, as long as one keeps learning. The fact that software engineers are good at learning is natural with being curious and wanting to learn. If computer hardware is to human bodies, then computer software is to human brains. Many religions honor human soul as eternal; it couldn’t be more appropriate analogy with computer software. While hardware is upgraded, the essential in software lives forever.  Arguably, one should never retire a high quality software product. The apparent high cost to “maintain” usually can be exchanged with technology transfers. 

 

[1]        D.L. Parnas. Software Aspects of Strategic Defense Systems, and SDI: A Violation of Professional Responsibility, In Chapters 26 and 27 of Software Fundamentals, Collected Papers by David L. Pamas, Edited by Hoffman and Weiss, Addison-Wesley, 2001 .

[2]        R.N. Charette,”Why software fails”, IEEE Spectrum,Vol.42 No.9, p42-49, Doi:10.1109/MSPEC.2005.1502528.

[3]        N. Maiden, “Trust Me, I’m an Analyst”, Software, IEEE, vol. 27, no. 3, June, 2010, p46-47, doi: 10.1109/MS.2010.22 .

[4]        J. Favaro, “Guest Editor’s Introduction: Renewing the Software Project Management Life Cycle”, Software, IEEE, vol. 27, no. 3, June, 2010, p17-19, doi:  10.1109/MS.2010.9.

[5]        A.P. Wood, “Software reliability from the customer view”, Computer, vol. 36, no. 8, Aug. 2003, p37-42, doi:10.1109/MC.2003.1220580.

[6]        R.L. Glass, Facts and Fallacies of Software Engineering, Addison-Wesley, c2003.

[7]        A.M. Davis, 201 Principles of Software Development, McGrow Hill, Inc, 1995.

[8]        G. Le Lann, “An analysis of the Ariane 5 flight 501 failure-a system engineering perspective”, in Proceedings., International Conference on Engineering of Computer-Based Systems, Mar 24-28, 1997, p339-346, doi: 10.1109/ECBS.1997.581900

[9]        B.H. Wu, “Modeling Defects in Software Systems”, IEEE International Conference on Granular Computing (GrC2011), Kaohsiung, Taiwan, November 8-10, 2011,  p739-744, doi: 10.1109/GRC.2011.6122690.

[10]      D.L. Parnas, Software Aging, In Chapter 29 of Software Fundamentals, Collected Papers by David L. Pamas, Edited by Hoffman and Weiss, Addison-Wesley, 2001.

[11]      S.L. Pfleeger, “The nature of system change”, Software, IEEE, vol. 15, No.3, 1998, p87-90, doi:10.1109/52.676964 .