Nature Made vs. Man Made

7 Sep

Evolutionary Computing: A Complexity Study with Systems Thinking

Abstract. This blog is a sequel to both software evolution and software as complex adaptive system in which I describe how the modern software can be viewed as a complex adaptive system and how software evolution can be placed or mapped in parallel to the Darwinian Evolution Theory of biology. Instead of working toward genetic computational approaches to biology, it studies complex adaptive systems in software as if software is the same among biological populations that abide by evolutionary theories of biology. It explores the relationship between complexity studies as a scientific endeavor, and systems thinking as a problem solving skill while approaching to generic software solutions, known as Computational Intelligence, to any problem of our interests at hand. It argues that skills with systems thinking are critical, and that applying them may add values to software development activities, especially to large-scale complex software aiming for the high quality and rapid productivity.

1 Introduction
Is “software” and “computer programs” exchangeable? My answer is no even if software is composed with many computer programs. During the end of 60s, Donald Knuth differentiated software from programs with “programs to facilitate the writing of other programs [1].” A decade later, Gilb and Weinberg [2] made emphasis on the separation of data and program by saying: “In the world of systems design, programs and data are the scissors blades working together to form the broader class—software. Lacking either blade, computers couldn’t cut through problems—yet for many people, ‘software’ is synonymous with ‘programs’.” These time-stamped insights on software have provided us the flavors of soft-ware evolution. Fast forwarding, most of software today is significantly different from those 40 years ago. I have argued that modern software is a complex adaptive system (CAS) [3] and viewing software as CAS can help us to deal with issues in its development and its usage realistically. Let us look at how study of complexity and systems thinking could benefit the making of software by engineers and the using of software by users/customers.
Both complexity and system thinking are faculties in us enabling our views of the world in depth. These faculties are rooted in our ability to apply abstraction. The study of complexity and systems thinking applies to software systems development in this paper is to the extend from the study of systems engineering, i.e., a layer of abstraction higher to the discipline in which the man-made electrical and mechanical devices are as systems components while clear objectives are expected with optimization and stabilization for the purpose of control. The study of complexity and systems thinking [4] should have no differences with the study of applied mathematics. Both are efforts to enable us to understand our subjects of interests and to help us cope with real problems within the context of systems in reality.
The novel approach to evolutionary computing, a subject of the interest in this paper, lies not in genetic computational approach to biology but in the soft-ware systems as complex adaptive systems as in biological populations. After the use of the software maturity model [5] to gain a better understanding of software maturity process, this paper explores the relationship between complexity study as a scientific endeavor and systems thinking as a problem solving skill, in order to approach to computational solutions, i.e., some kind of generic software solutions to problems of our interests at hand. Starting with a categorization of software next, the rest of the paper is arranged with describing CAS in software in section three and systems thinking as principle applying to software development in section four. Examples used to facilitate discussions are embedded throughout the paper before giving concluding remarks..

2 Categorize software
All knowledge is recognized within context including software and software quality. When one studies quality of software in generic sense, the first thing we want to know is where our generalization comes from. That is, what are possible kinds of software is there for each special purpose that we generalize. We then analyze the methods that are used in developing software in order to achieve certain quality and efficiency. Whether the saying: “not all software was created equal” is a joke or not, the implication is the obvious: 1) the software crisis had led to soft-ware engineering as a discipline forty plus years ago; 2) computing technologies and methodologies had developed exponentially since then; 3) all of computing approaches are invented purposefully with building tools, components, or COTS to be shared in software making; 4) however, because of the massive computing technology development efforts, we cannot help to ask ourselves “what is soft-ware?” Pondering such question, it is to make a better sense in mapping technologies with problems we are facing by means of software as their solutions. The key is to know the type of software that is good at solving certain problems using certain tools and methods, so we can make them effective and efficiently. Let us look at how software has been categorized by researchers and practitioners in software engineering or in software development practice.
In his introduction to software engineering [6], Ian Sommerville introduced software in the context of systems with pointing out that for all possible systems existed in the world, there will be software design and implementation techniques for software development of each system. On the other hand, Mary and Tom Poppendick [7] introduced software through its impacts to business [7] with four levels as follows: 1) strategic business initiative, 2) business feature up-grade, 3) infrastructure upgrade, 4) maintenance. This is in the context of software as the enabling core of a business. Typical examples are software developed in house at companies such as Google and Amazon.com. With viewing software as a product, Poppendicks wrote: “For the sake of simplicity, we use the term product champion, although we recognize that you may not use the word product to refer to your systems. You may be developing 1) software as a product 2) software embedded in a product 3) software enabling a process 4) software under contract (at p38 in [7]).” In case of last two on the list, they noted that software should not be defined by technology but by systems that entail problems by observers.
Poppendicks’ views of software systems and software products are well aligned with Sommerville’s view of software in the context of systems. Indeed, systems, as in applying systems thinking, are the fundamental skill for us to deal with complex problems; and software provides modern solutions to complex problems whether these software solutions are in the context of business initiatives or product developments.
The study by Michael Jackson in Problem Frames [8] has empowered us with the realization of the inevitable gap between problems and software as solutions [8][9]. It signifies the importance of our study in software evolution. The two essential aspects in software evolution are the reduction of the gap between understanding of a problem at hand and coming up with a solution in software and the evolution of the technologies used in making the software as solution to the problem. Studying CAS does help us address our concerns about the software development. Let us look at software as CAS next.

3 Complex Adaptive Systems in Software
Software is pervasive in every corner of our society. The society as the modern industrial world enriches the rapid growth of software. In this section, I will proceed with analyzing a few examples in different industries to make my point on the necessity of understanding CAS in software. Here is the list of examples to be analyzed next. 1) Compiler construction [10] as a solution to computing technology. 2) Chess playing programs, design and implementation, as a solution to the entertainment industry, and 3) a set of software applications as business solutions via Internet. These examples entail the typical and well thought out problems in the prospect of the three Dead Art, coined by Keith Braithwaite in the context of calling attention to software engineering methodology in Agile age, namely, analysis, architecture, and modeling [9]. However, the challenges still exist in the prospect of eliminating gaps between problem frames and solution frames as mentioned in [8][9] due to the nature of software as CAS [3].

3.1 Compiler
In Parnas’ 1996 article [11], he started with a few simple and organized software designs by Wirth [10] and Dijkstra [12]. He calls these examples software Jewels and points out that, in spite of helpful articles and many textbooks on software design, software jewels remind rare. He states: “Most of the software we see or buy is ugly, unreliable, hard to change, and certainly not something that Wirth or Dijkstra would admire.” Following up with his observation, I choose to use his example of the compiler construction, in which a compiler for Obron-0 is developed by Wirth as my first example in studying CAS in software.
“Compiler converts program texts into internal code that bridges between software and hardware. [10]” Invention of compiler is a milestone achievement in computing technology, which has the milestone significance in computer education for students in computer science major, as it was first and foremost pointed out by Wirth in the preface of his book [10]. Let us analyze Wirth’s software to see the reasons we view it as CAS based on the five characters that are defining CAS by Paul Cilliar [13]:
First, a complex system consists of a large number of elements. Compiler are complex is obvious especially when the language it compiles are large and complex, such as Java or C++. 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. The compiler parses the syntax of a program text by a user; it then analyzes semantics to find fault of the text before going through the rest of the paths to get its final translation of users’ code into machine code. In theory, as long as the compiler is not proved to be correct, one can never assume that the machine code is 100% correct. That is to say, errors made by a user unintentionally exist and behaviors of the machine code generated by a compiler is not predictable even though a good compiler does a better job doing its translation and may be called software jewels in Parnas’ expression. Due to the error prone nature of humans’ problem skills through programming, it bounds to have unpredictability inside a compiler. It’s safe to think that the compiler is non-deterministic. 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. Testing of a compiler is as the same as testing any complex software. That is, complete test coverage is not possible. By applying the Information Hiding Principle, compilers are implemented in multipath, and errors propagate between paths. Forth, complex systems have a history and must be viewed both synchronically and diachronically. All software product are improved, over time, from first release to the last minute the software is being supported by software engineers and used by users. Diachronically viewing a compiler we look at different machines that allow compilers produce code to be executed on each machine. Each compiler implementation for that machine is tailored to that specifically designed hardware and they vary even if using the same architecture design. My follow up question is: does diachronically inspecting a compiler help us build a better quality of the compiler? I tend to think so provided the robust compiler for machines would have common characters to share and their test coverage will be reinforced among implementations that run on each machine. Fifth, complexity is the result of a rich interaction of simple elements that only respond to the limited information presented to them. As all software development start with an architecture design, a complex problem is going to be divided into small problems. In a compiler, the typical solutions, same as in many computer system tools, the information hiding principle is applied; as a result, the multipath compiler is implemented. Three paths are usually the minimal in a compiler: scanner, parser, code generator, with or without an optimizer. Each is simple, but together, the compiler gets the code translation done.
What are lessons learned about complexity in compilers then? 1. Compiler is hardware dependent; hardware aging will cause the compiler to retire. 2. Architectures of compiler are hereditary as in the Darwinian evolution theory applied to biological populations. 3. Both synchronically and diachronically viewing a compiler is the same as the popular view of product families. In a compiler with-in its software product family, it is the design to support each computer language on different hardware. 4. As almost all software (let us leave rooms for exceptions) are running on open systems, so is a compiler, which provides users with a generating machine code to execute, i.e., compilers are means not ends.

3.2 Checker, Chess, and Go
Board game playing programs have been an important part of computing technology demonstrator along with the effort in computer hardware development. Playing Checker, Chess, and Go by the computer is increasingly difficult in this order. Modern computers are able to handle all possible moves in Checker program [14] whereas no anticipated computers, yet, to handle all possible chess moves, much less for Go by cataloging moves, heuristically or not.
Chess playing programs such as well-known Deep Blue by IBM had been my inspiration of ITS research in my PhD study [15]. Making the chess program is a task within AI, and the interesting ones may not only include brutal searches, which are algorithms covering cataloged board moves, but also reflect approaches dynamically as close as our real brains at work. Through studying top players (the world champion chess players) one would get clues in how many variations in playing chess and how hard chess playing problems are for computer to handle. Here is a list of descriptions of chess players to provide readers a flavor on chess playing, which shows the decision making behind risky calculations in each move and how system thinking skill is necessary to enable each player to make their moves.
What are lessons learned in this example?
“Chess is an intellectual gymnastics.” — Wilhelm Steinitz
“Chess mastery essentially consists of analyzing chess positions accurately.” — Mikhail Botvinnik
From the analysis of Edward Scimia at About.com, we can safely identify the core ability of all players plus distinctions of each player as follows:
1. Core capabilities in playing chess are 1) be a positional player, 2) capable of finding deep combinations, and 3) adapting to situation if need; all of which re-quire logical thinking in addition to be good at both endgame and opening.
2. Distinctions in each player vary and name a few as listed here:
* Sharp changes from romantic to attacking
* Quickly and accurately judge a position
* Play creative and deep combination with finding complicated position but quiet
* Adept to strategy play (depth knowledge in opening vs. wide variety of systems)
* Energetic style to put maximum pressure on to his opponents (env)
* Insatiable desire to finding winning chances in each game (prep)
* Preferring to gain a slight edge with no chance of defeat (safety)

3.3 Web-based projects
The third example that differentiates the first two is essentially to show the evolutionary nature of programming tools for a specific task category by using published studies of web-based software development projects. Researchers have been theorizing web-based projects along with WWW’s birth and growth [17] [18]. “A web application framework is a software framework that is designed to support the development of dynamic websites, web applications and web services.” [19] An array of tools is developed to support a web-based project development along with the gradual establishment of frameworks. Tools by definition are to boost productivity in project development. In software development practice, such as in web-based projects, it provided only convenience for project management, i.e., software development measurement and control. Altendorf et al [18] had given their insightful analysis of pros and cons in the experience of using J2EE technology in their large web application development. Compared with the earlier web project development with simpler web development tools participated by the author at NASA GSFC [17], large software system development due to restrictions imposed by tools may have had more negative impacts, which have been analyzed in terms of interrelated in the relationship between software requirements and software design [20].

3.4 Discussion
We have introduced three examples above to show complexity in software while each has its own characteristics. Let us compare them and make a further discussion.
Complexity in the compiler design relies on the language that the compiler is to translate and the hardware that the compiler runs on. Complexity in board games is up to the difficulty of the games themselves. With technologies used to improve game playing while each game is sufficiently complex, our challenge in making the software to play the game is in the knowledge of playing the game. Solutions in software rely on the people who understand each game, not only those who know technologies. Complexity, in the web design as in the third ex-ample given above, can be man-made in the sense that how we do to promote productivity with tools and methods. T.K. Landauer has shown us his answer in The trouble with Computers. That is the fact that the computer age has not provided labor productivity growth as we expected (p15 in [21].) One conclusion that may be derived from these examples is that no matter how the complexity in software is, an apparent solution to the problem addressed by the software lies in systems thinking, a critical problem solving skill.

4 A Critical Skill: System Thinking
Let us take close inspection of the terminology, systems thinking, with the retrospection of the author’s software development applying systems thinking. The skill of systems thinking is indeed the skill used to problem solving and acquired through learning how scientists and engineers applying it in their discovering knowledge taught at school. We study via textbook in which we learn not only the content of knowledge but also how such knowledge is derived. Although system thinking is considered skill, it is based on faculty within as generically. To some it requires enforced training to others acquiring it can be self taught. In some the learning process comes naturally, for others it requires intensive training. Eventually, it becomes a habit in scientific endeavor. In either case, it appears to be within us while we are engaging in problem solving. Further, our visions are the results applying this systems thinking skill/faulty, which guide us to an appropriate solution to each problem we are facing.
What are influential factors onto us in order to build up the skill then? This is the immediate concern once we accept the premise in our understanding of the term, systems thinking. Viewing it as a critical skill in problem solving, I argued that it is the core learning in higher education, such as learning scientific knowledge as mandatory for students in a four-year college and beyond. Let us take close inspection of the terminology, systems thinking, with the retrospection of the author’s software development applying systems thinking. The skill of systems thinking is indeed the skill used to problem solving and acquired through learning how scientists and engineers applying it in their discovering knowledge taught at school. We study via textbook in which we learn not only the content of knowledge but also how such knowledge is derived. Although system thinking is considered skill, it is based on faculty within as generically. To some it requires enforced training to others acquiring it can be self taught. In some the learning process comes naturally, for others it requires intensive training. Eventually, it be-comes a habit in scientific endeavor. In either case, it appears to be within us while we are engaging in problem solving. Further, our visions are the results applying this systems thinking skill/faulty, which guide us to an appropriate solution to each problem we are facing.
What are influential factors onto us in order to build up the skill then? This is the immediate concern once we accept the premise in our understanding of the term, systems thinking. Viewing it as a critical skill in problem solving, I argued that it is the core learning in higher education, such as learning scientific knowledge as mandatory for students in a four-year college and beyond.

5. Concluding Remarks
In his Problem Frames [8], Jackson states:
Not only does everyone agree that you should focus on the problem before the solution; almost everyone agrees that you should focus on what the system will do before you focus on how it will do it. What before how is the motto.
He then immediately acknowledges the difficulty in the distinction be-tween what ought to do (problem concerned) and how to get it done (a solution) in software. The openness of the software systems addressing problems by software and solutions to problems. This is the center issue in his Problem Frames. After three hundred pages of discussions in terms of proposals and analyses, Jackson summarizes:
In spite of its 50 year history, software development is a curiously immature affair. To do better we must recognize the great variety in our problems and products, we must think consciously about development risks, we must focus our attention where it matters, we must learn from experience, and we must be masters, not pedants, of development methods.
Jackson has provided us perfect concluding remarks to our issues and concerns expressed and argued in this paper. Indeed, software is CAS and it should be treated as CAS as it is originated in biological populations and modeled by the Darwinian Evolution Theory. The approach in this paper has been exploring the relationship between CAS and systems thinking to study software from the evolutionary view that deserves further scrutiny.

References
1. D. E. Knuth, The Art of Programming I-IV, Addison-Wesley, 1996.
2. T. Gilb and G. M. Weinberg, Humanized Input. Winthrop Publishers, Inc. Cambridge, MA, 1977.
3. B.H. Wu, “A Novel Approach to Evolutionary Computing: an Introduction,” in Proc. of IEEE ICICIP12, Dalian, China. July 15-17, 2012, pp733-738.
4. http://www.systemswiki.org/index.php?title=Main_Page
5. B.H. Wu,“Modeling Software Maturity, a software life cycle management approach,” in Proc. ICIST 2012, Wuhan, China, March 23-25, 2012, p716-720.
6. I. Sommerville, Software Engineering, Addison Wesley; 9 editions, 2010.
7. M.Poppendieck and T. Poppendieck, Leading Lean Software Development: Results Are not the Point, Addison-Wesley Professional; 1 edition, 2009.
8. M. Jackson, Problem Frames, Analyzing and Structuring software development problems. Addison Wesley, 2001.
9. http://www.ndc2011.no/agenda.aspx?cat=1071
10. N. Writh, Compiler Construction (International Computer Science Series) Paper-back., Addison-Wesley, 1996.
11. D.L. Parnas, “Why Software Jewels Are Rare,” IEEE Computer, Feb. 1996, p57-60.
12. E.W. Djikstra, “The Structure of the THE Multiprogramming System,” Comm. ACM. Vol. 11 No. 5, May 1968, p341-346.
13. P. Cilliers. Complexity and Post Modernism. Routledge; 1 edition, 1998.
14. http://webdocs.cs.ualberta.ca/~jonathan/awards/index.html
15. B. H. Wu, Artificial Teaching Assistance: a Framework for Intelligent Tutoring Systems with Abstract Knowledge, UMI dissertation Services, a Bell & Howell company, Ann Arbor, MI, 1998.
16. http://chess.about.com/od/famouschessplayers/a/WorldChampions.htm
17. B.H. Wu, “A framework for WWW query processing,” COMPSAC 2000, p187-188.
18. E.Altendorf, M.Hohman, and R. Zabicki,”Using J2EE on a large, Web-based project,” IEEE Software, Vol.19, #2, 2002, p81-89.
19. http://en.wikipedia.org/wiki/Web_application_framework
20. P.C. Clements, “Rationalize software design,” Chapter 5, Constructing Superior Software (Software Quality Institute Series), Editor, Clements, P.C., MTP, USA, p105-124.
21. T.K. Landauer, The Trouble with Computers: Usefulness, Usability, and Productivity [Paperback], A Bradford Book, 1996.

Advertisements

2 Responses to “Nature Made vs. Man Made”

  1. Panama September 15, 2012 at 11:51 am #

    Systems thinking is the process of understanding how things influence one another within a whole. In nature, systems thinking examples include ecosystems in which various elements such as air, water, movement, plants, and animals work together to survive or perish. In organizations, systems consist of people, structures, and processes that work together to make an organization healthy or unhealthy.

  2. Michael Robert Brown September 16, 2012 at 4:43 am #

    Many thanks for taking this chance to speak about this, Personally i think strongly regarding it and I make use of learning about this subject. When possible, as you gain data, please update this website with new information. I’ve found it extremely useful.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: