To someone who cannot let go of the physical world, ontology is an odd subject. It is the philosophical study within the branch of metaphysics that deals with the nature of being. Or as Wikipedia says, "Ontology is the philosophical study of the nature of being, becoming, existence, or reality, as well as the basic categories of being and their relations." But for my purposes I will go no further than to talk about objects and their existence.
For anyone immersed in the objects relations school of computer programming objects is a weighted term. And it is exactly that overtone I wish to look at. But let me take one step back for a moment and observe that until one has successfully strung together a file of symbols that will pass a Java compiler, there is not yet a software module. The moment the compiler first accepts that text file and generates a byte code file, a new module is brought into existence in that file namespace. It has been summoned into existence.
The object-relations school of thought looks at a software module as an object that possesses attributes and behaviors. The byte code object can be copied, moved, executed and deleted (destroyed). Yet does the byte code file have any behaviors? Does any purely descriptive object be said to exhibit any behavior? I am going to say no. But of course the purpose of a byte code file is not to merely exist like some artifact lost in the desert of a file system. It is the essence that imparts some special magic into the machine with a Java Virtual Machine (JVM) running on it which will take that descriptive text and use it to create objects within the memory of that computer. And the original intent of the creator was that this object in the machines memory takes over the capabilities of this machine in a virus like way and bends it to the hidden will of the creator. It transmits the design of a virtual machine to this physical machine and then
Computer Science is no more about computer than Astrophysics is about telescopes (E.W. Dijkstra)
Ontology is one of the prime areas of metaphysics. How did I end up reading about metaphysics when I intended to understand what makes programs readable? I am here because while we blithely talk about instantiating objects in a Java program, I am taking it in a more literal sense and finding that the language of ontology and then the later issues of sense and reference applicable to these. It cannot be mere coincidence that the two fields overlap in this way.
I am not alone of course. There is this post which directly asks the same question and gives a rather good answer. I found in in June 2018. http://www.mathema.com/philosophy/metafisica/is-metaphysics-relevant-to-computer-science/
But let me race on to the thought that sparked this entry, the famous sentence in philosophy about the bald king of France. Is this true or false?
in Java terms, we have two predicates. One would answer the question of whether x is the King of France. The other would answer the question of being bald. The first predicate could never be answered, could never be true, since there is no such person. This gives a null referent for the second predicate. And null referents defy the precondition of any predicate giving an indeterminate response. So in programming terms we exactly see the philosophical notion of the presumed referent.
When listening to the lectures on the philosophy of language and specifically the discussions of fiction that I came to what I think may be a metaphysics different from Searle's. I need to read more about this to see if it is a distinct metaphysics and if so, learn to describe it.
References:
Ontologies: Principles Methods and Application, Mike Uschold Michael Gruninge, 1996, The University of Edinburgh
http://www.aiai.ed.ac.uk/publications/documents/1996/96-ker-intro-ontologies.pdf
https://www.springer.com/cda/content/document/cda_downloaddocument/9780387370194-c1.pdf?SGWID=0-0-45-495101-p173670217
https://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-871-knowledge-based-applications-systems-spring-2005/lecture-notes/lect22_ontolog.pdf
https://plato.stanford.edu/entries/computer-science/
Saturday, June 9, 2018
Friday, June 1, 2018
Charles Sanders Peirce - philosopher, logician, mathematician
For anyone who has studied formal logic, Peirce (pronounced like "purse"), is remembered for his binary operator, the Peirce arrow which, as it turns out, is functionally sufficient to derive all the other logical operators. This math fact gives us the ability to construct entire computers using only a single logic gate.
Charles Sanders Peirce (/pɜːrs/,[9] like "purse"; 10 September 1839 – 19 April 1914) was an American philosopher, logician, mathematician, and scientist who is sometimes known as "the father of pragmatism". He was educated as a chemist and employed as a scientist for 30 years. Today he is appreciated largely for his contributions to logic, mathematics, philosophy, scientific methodology, and semiotics, and for his founding of pragmatism.
Charles Sanders Peirce (/pɜːrs/,[9] like "purse"; 10 September 1839 – 19 April 1914) was an American philosopher, logician, mathematician, and scientist who is sometimes known as "the father of pragmatism". He was educated as a chemist and employed as a scientist for 30 years. Today he is appreciated largely for his contributions to logic, mathematics, philosophy, scientific methodology, and semiotics, and for his founding of pragmatism.
Peirce's most important work in pure mathematics was in logical and foundational areas. He also worked on linear algebra, matrices, various geometries, topology and Listing numbers, Bell numbers, graphs, the four-color problem, and the nature of continuity.
He worked on applied mathematics in economics, engineering, and map projections (such as the Peirce quincuncial projection), and was especially active in probability and statistics.[79]
- Discoveries
Peirce made a number of striking discoveries in formal logic and foundational mathematics, nearly all of which came to be appreciated only long after he died:
In 1860[80] he suggested a cardinal arithmetic for infinite numbers, years before any work by Georg Cantor(who completed his dissertation in 1867) and without access to Bernard Bolzano's 1851 (posthumous) Paradoxien des Unendlichen.
↓
The Peirce arrow,
symbol for "(neither) ... nor ...", also called the Quine dagger.
symbol for "(neither) ... nor ...", also called the Quine dagger.
In 1880–1981[81] he showed how Boolean algebra could be done via a repeated sufficient single binary operation (logical NOR), anticipating Henry M. Sheffer by 33 years. (See also De Morgan's Laws.)
https://en.wikipedia.org/wiki/Charles_Sanders_Peirce
W Ross Ashby
One of the new names that popped up in my research is W Ross Ashby.
W. Ross Ashby (6 September 1903 in London – 15 November 1972) was an English psychiatrist and a pioneer in cybernetics, the study of the science of communications and automatic control systems in both machines and living things. His first name was not used: he was known as Ross Ashby.Despite being widely influential within cybernetics, systems theory and, more recently, complex systems, Ashby is not as well known as many of the notable scientists his work influenced, including Herbert A. Simon, Norbert Wiener, Ludwig von Bertalanffy, Stafford Beer, Stanley Milgram, Kevin Warwick, and Stuart Kauffman.[5]
https://en.wikipedia.org/wiki/W._Ross_Ashby
W. Ross Ashby (6 September 1903 in London – 15 November 1972) was an English psychiatrist and a pioneer in cybernetics, the study of the science of communications and automatic control systems in both machines and living things. His first name was not used: he was known as Ross Ashby.Despite being widely influential within cybernetics, systems theory and, more recently, complex systems, Ashby is not as well known as many of the notable scientists his work influenced, including Herbert A. Simon, Norbert Wiener, Ludwig von Bertalanffy, Stafford Beer, Stanley Milgram, Kevin Warwick, and Stuart Kauffman.[5]
https://en.wikipedia.org/wiki/W._Ross_Ashby
It has been a few years since I used this blog. I had started posting things to Facebook but I am going into a deep dive on a topic and I want to try to gather some posts on that topic. I am currently interested in trying to establish a foundation in how language is used when dealing with computers and how it is used when computers interact. I am going to make a series of posts on influential thinkers as a form of annotated bibliography although the posts are about the people and not their works per se. I may go back and fill in the appropriate writings that I need but for now their brief bios will meet my needs.
Saturday, May 4, 2013
An Outline for a New GE Course in Computer Science
I have just completed teaching a course at a community college for the second time. Before all the volatile thoughts I had are completely lost, I want to sketch out the unique ideas I have about how a course like this should be taught. What I find generally lacking is a narrative thread that connects the disparate arcana that must be covered into a motivating course.
I. Introduction
Is this course really about "computer science"? If so, what is "information technology"? "management information science"? And why is it focused on "computation"? What I teach is really information technology and the central role of information to individuals, groups, organizations and society. While the motivation for most of the innovations through history have been focused on computation or communications, we are finding that we are looking toward and information convergence where all forms of information will be handled with the same technology. To be an educated and productive member of our society you must gain certain basic understandings of this technology, how it is used and the various ways you can approach it in your academic studies.
Show some entertaining Rube Goldberg machines and discuss causality and the design of mechanisms to achieve some end. Emphasize that computers are machines. While details may be daunting, there is nothing going on that a motivated person cannot understand.
I like to present computers in a continuum of mechanized development. The tie between Jacquard and information processing is well known, I think the tie between continued development and the industrial age is not fully explored. I think this is important simply because those students who have mechanical aptitude will find the mechanistic aspect of computers easy to grasp and dwelling on the more mechanical nature of the machines avoids alienating those students who lack this intuitive grasp of machines.
II. History
What is information? Is there information without humans? Does it server human needs? If so, which ones? Who historically funded the innovations in information technology and communications? commerce, military, government, religion. Eventually we see entertainment. Taking commerce as a starting point, you must understand the basics of numbers and numeric representation. This motivates an algebraic understanding of our positional number system and its variants in different bases. Depending on the depth possible in the course, negative numbers and real numbers can be covered in binary notation. Even more interesting is the notion of the digitization of numbers in even real representation and the inherently limited size of machine memory. No physical memory is unlimited and therefore has inherent limits on the size of the number that it can represent. An interesting philosophical point is the innovation of zero and the difficulty of representing nothing. This comes up again with null sets, representing a space and other places in the curriculum.
The basic arithmetic algorithms for the conversion of one base to another versus the conceptual understanding of those representations. The algorithm for long division. The concept of an algorithm as a series of steps that are executed to achieve some result. Summarize rules of binary addition into table.
Introduce the concept of mathematical series to calculate irrational numbers. Present enough to convince students that this work becomes tedious. Conclude with the method of calculating polynomial expressions using a series of differences.
Jump to text and some of the innovations. Transition from oral society to literate society. The first representation of spoken words through writing. Code of Hamirabi. Pictographic representation of thoughts. Development of phonetic alphabet. The limited growth of literacy. Look at literacy rates of 18th century France for grounding.
Use Greeks to discuss discourse and rhetoric. Codification of the laws of argumentation and thinking. The introduction of deductive logic. Cover basic forms of AND, OR (both inclusive and exclusive), NOT. Introduce truth tables. Nesting of expressions.
I like to cover the reality of the Medieval period of Europe and the growth of the Islamic world since major innovations occurred outside Europe and were introduced in the Renaissance like Arabic numerals, zero, algebra and double entry bookkeeping. It was the growth of trade that made this bookkeeping needed and also provided the explosive growth that led to the middle class and the growth of literacy, the reformation and the importance of the moveable type press. lower case, typesetting, italic, serifs. These are all needed to understand web technologies and word processors.
Cover the concept of variable in algebra if needed. The unknown which becomes a container for a value to be determined. If possible and necessary, cover rules of algebra like commutative, associative and distributive.
Discuss early attempts at mechanical computation like abacus used for commerce and still popular and the Pascal calculator. Show how innovations in timekeeping and metallurgy made this possible. Discuss decade counter (carry), odometer. If desired, discuss how negative is represented using an odometer (-1 = 9999) and tie back to the concept of ones complement.
Communication innovations. Lanterns in towers, flags. All depended on some system of alphabetic or message encoding. Discuss difference and give examples. motivates ASCII code later on. Military applications and encoding for secrecy. Discuss bandwidth, parallel, serial, representing null messages, secrecy and ways of encrypting messages.
Introduce Enlightenment and Industrial Revolution. Discuss basic electromagnetism if needed. Discuss need for communication to achieve coordination and the parallel growth of railroads and communication. Morse code, mechanics of receive and forward of discrete messages throughout a telegraph network. Do this in a way that motivate the packet switched network and introduce basic concepts like point-to-point, broadcast, routing. The growth in the publishing of books of transcendental equations for engineers and scientists.
Cover more logic. Boolean algebra. discuss how rules of Boolean algebra can be accomplished using simple mechanical devices. Introduce notion of binary addition as identical to simple Boolean expressions.
Talk about the tedium of looming, especially complex Jacquard fabrics. Describe the method of weaving them prior to mechanical loom. Discuss how the use of cards was used to control the needles and could be looped together to repeat the pattern. This allowed one loom to create many different patterns by changing the cards. The master weaver could then create many card decks for the various patterns.
Discuss Babbage first creation which mechanized the solving of polynomial equations with a geared machine. Input was via dials and levers. Discuss how he used Jacquard innovation to make machine setup easier. Ada describing cards that would solve a problem. Hollerith and 1890 census and success of punched cards to hold information.
Introduce typewriter as an innovation of moveable type press. Show how combination of telegraph and typewriter lead to teletype. Discuss difficulty of having national codes when communication goes global. Cover Baudot code if time allows. ASCII code. Multiplexing to compress/decompress signals.
Telephone. Analog versus digital. Waveform. How to digitize? PCM. How do you represent digital using analog? modem. can cover circuit switching if desired. Emphasize bandwidth. If desired, cover carrier and its encoding. Explain this as mechanism for most DSL.
There is a great deal of history on non-contemporary computer architecture. I skip it and jump ahead to the concept of gates. I like to emphasize that a gate can be implemented with very simple switches. Progress through innovations to speed switching; relays, tubes, transistors.
Revisit logic and introduce NAND, NOR and then describe half-adder circuit. Make tie between logic and arithmetic explicit. Motivate need for speed by discussion of military uses; munitions that could fire beyond horizon making visual correction impossible, the element of surprise that is lost if first shell does not land on target. the widespread use of "computers" (people) to do many complex algebraic computations. This leads to the rush to create a machine to perform the theoretical calculations needed to create the A-bomb and later the H-bomb.
The red scare and the race for space spurred new innovations like the integrated circuit. Moore's law.
privacy (anonymity) versus secrecy
**********************************
Addendum. I am reconsidering this approach in that more math must be introduced earlier. I still believe that it is better to introduce language and its various representations before math, it should still be introduced almost immediately in the form of numeric representation. I think the leap from addition and subtraction to multiplication and division would be good, particularly at the community college level since long division offers a good introductory algorithm that is not beyond their mathematical maturity. This ties in nicely with the transition from clocks to calculators as they grappled with these operations using gears.
I. Introduction
Is this course really about "computer science"? If so, what is "information technology"? "management information science"? And why is it focused on "computation"? What I teach is really information technology and the central role of information to individuals, groups, organizations and society. While the motivation for most of the innovations through history have been focused on computation or communications, we are finding that we are looking toward and information convergence where all forms of information will be handled with the same technology. To be an educated and productive member of our society you must gain certain basic understandings of this technology, how it is used and the various ways you can approach it in your academic studies.
Show some entertaining Rube Goldberg machines and discuss causality and the design of mechanisms to achieve some end. Emphasize that computers are machines. While details may be daunting, there is nothing going on that a motivated person cannot understand.
I like to present computers in a continuum of mechanized development. The tie between Jacquard and information processing is well known, I think the tie between continued development and the industrial age is not fully explored. I think this is important simply because those students who have mechanical aptitude will find the mechanistic aspect of computers easy to grasp and dwelling on the more mechanical nature of the machines avoids alienating those students who lack this intuitive grasp of machines.
II. History
What is information? Is there information without humans? Does it server human needs? If so, which ones? Who historically funded the innovations in information technology and communications? commerce, military, government, religion. Eventually we see entertainment. Taking commerce as a starting point, you must understand the basics of numbers and numeric representation. This motivates an algebraic understanding of our positional number system and its variants in different bases. Depending on the depth possible in the course, negative numbers and real numbers can be covered in binary notation. Even more interesting is the notion of the digitization of numbers in even real representation and the inherently limited size of machine memory. No physical memory is unlimited and therefore has inherent limits on the size of the number that it can represent. An interesting philosophical point is the innovation of zero and the difficulty of representing nothing. This comes up again with null sets, representing a space and other places in the curriculum.
The basic arithmetic algorithms for the conversion of one base to another versus the conceptual understanding of those representations. The algorithm for long division. The concept of an algorithm as a series of steps that are executed to achieve some result. Summarize rules of binary addition into table.
Introduce the concept of mathematical series to calculate irrational numbers. Present enough to convince students that this work becomes tedious. Conclude with the method of calculating polynomial expressions using a series of differences.
Jump to text and some of the innovations. Transition from oral society to literate society. The first representation of spoken words through writing. Code of Hamirabi. Pictographic representation of thoughts. Development of phonetic alphabet. The limited growth of literacy. Look at literacy rates of 18th century France for grounding.
Use Greeks to discuss discourse and rhetoric. Codification of the laws of argumentation and thinking. The introduction of deductive logic. Cover basic forms of AND, OR (both inclusive and exclusive), NOT. Introduce truth tables. Nesting of expressions.
I like to cover the reality of the Medieval period of Europe and the growth of the Islamic world since major innovations occurred outside Europe and were introduced in the Renaissance like Arabic numerals, zero, algebra and double entry bookkeeping. It was the growth of trade that made this bookkeeping needed and also provided the explosive growth that led to the middle class and the growth of literacy, the reformation and the importance of the moveable type press. lower case, typesetting, italic, serifs. These are all needed to understand web technologies and word processors.
Cover the concept of variable in algebra if needed. The unknown which becomes a container for a value to be determined. If possible and necessary, cover rules of algebra like commutative, associative and distributive.
Discuss early attempts at mechanical computation like abacus used for commerce and still popular and the Pascal calculator. Show how innovations in timekeeping and metallurgy made this possible. Discuss decade counter (carry), odometer. If desired, discuss how negative is represented using an odometer (-1 = 9999) and tie back to the concept of ones complement.
Communication innovations. Lanterns in towers, flags. All depended on some system of alphabetic or message encoding. Discuss difference and give examples. motivates ASCII code later on. Military applications and encoding for secrecy. Discuss bandwidth, parallel, serial, representing null messages, secrecy and ways of encrypting messages.
Introduce Enlightenment and Industrial Revolution. Discuss basic electromagnetism if needed. Discuss need for communication to achieve coordination and the parallel growth of railroads and communication. Morse code, mechanics of receive and forward of discrete messages throughout a telegraph network. Do this in a way that motivate the packet switched network and introduce basic concepts like point-to-point, broadcast, routing. The growth in the publishing of books of transcendental equations for engineers and scientists.
Cover more logic. Boolean algebra. discuss how rules of Boolean algebra can be accomplished using simple mechanical devices. Introduce notion of binary addition as identical to simple Boolean expressions.
Talk about the tedium of looming, especially complex Jacquard fabrics. Describe the method of weaving them prior to mechanical loom. Discuss how the use of cards was used to control the needles and could be looped together to repeat the pattern. This allowed one loom to create many different patterns by changing the cards. The master weaver could then create many card decks for the various patterns.
Discuss Babbage first creation which mechanized the solving of polynomial equations with a geared machine. Input was via dials and levers. Discuss how he used Jacquard innovation to make machine setup easier. Ada describing cards that would solve a problem. Hollerith and 1890 census and success of punched cards to hold information.
Introduce typewriter as an innovation of moveable type press. Show how combination of telegraph and typewriter lead to teletype. Discuss difficulty of having national codes when communication goes global. Cover Baudot code if time allows. ASCII code. Multiplexing to compress/decompress signals.
Telephone. Analog versus digital. Waveform. How to digitize? PCM. How do you represent digital using analog? modem. can cover circuit switching if desired. Emphasize bandwidth. If desired, cover carrier and its encoding. Explain this as mechanism for most DSL.
There is a great deal of history on non-contemporary computer architecture. I skip it and jump ahead to the concept of gates. I like to emphasize that a gate can be implemented with very simple switches. Progress through innovations to speed switching; relays, tubes, transistors.
Revisit logic and introduce NAND, NOR and then describe half-adder circuit. Make tie between logic and arithmetic explicit. Motivate need for speed by discussion of military uses; munitions that could fire beyond horizon making visual correction impossible, the element of surprise that is lost if first shell does not land on target. the widespread use of "computers" (people) to do many complex algebraic computations. This leads to the rush to create a machine to perform the theoretical calculations needed to create the A-bomb and later the H-bomb.
The red scare and the race for space spurred new innovations like the integrated circuit. Moore's law.
privacy (anonymity) versus secrecy
**********************************
Addendum. I am reconsidering this approach in that more math must be introduced earlier. I still believe that it is better to introduce language and its various representations before math, it should still be introduced almost immediately in the form of numeric representation. I think the leap from addition and subtraction to multiplication and division would be good, particularly at the community college level since long division offers a good introductory algorithm that is not beyond their mathematical maturity. This ties in nicely with the transition from clocks to calculators as they grappled with these operations using gears.
Structuring Software Engineering Case Studies to Cover Multiple Perspectives
This post is my riff on a paper titled Structuring Software Engineering Case Studies to Cover Multiple Perspectives by Emil Boerjesson and Rober Feldt from Chalmers Univ. The paper offers suggestions on how multiple perspectives can be ensured by using a 6 step process. In their case study, they wanted to ensure they looked at the V&V process using four different perspectives; Business, Architecture, Process and Organization (BAPO) as well as from three distinct temporal perspectives; past, present, future (PCF).
The paper does not have any deep contribution to the case study approach to software engineering research; however it does provide an easy paper for the start of understanding how case studies can be used in the research of software engineering.
They call a case study:
The paper does not have any deep contribution to the case study approach to software engineering research; however it does provide an easy paper for the start of understanding how case studies can be used in the research of software engineering.
They call a case study:
- an observational research method,
- a way to investigate a phenomenon in its context,
- applicable when there is no clear distinction between the phenomena and its context,
- have guidelines recently published by Runeson and Hoest [1]
Their six-step methodology is:
- Get Knowledge about the Domain
- Develop focus Questions/Areas
- Choice of Detailed Research Methods
- Data collection
- Data analysis and Alignment
- Valuation Discussion
[1] P. Runeson and M. Hoest, "Guidelines for conducting and reporting case study research in software engineering," Empirical software Engineering, vol. 14, no. 2, pp. 131-164, 2009.
The Accretion of Structure in Large, Dynamic Software Systems: A Socio-Technical View
On the outside chance there is really anyone following this blog, apologies. If you acknowledge reading this I will be more inclined to post more often. But this blog serves as my sounding board for my developing research thoughts. The title of this post could potentially be a dissertation but it is too ambitious to be mine. Yet it does indicate the direction my thoughts are taking.
Large software systems that reach any great level of popularity do not fall from the sky fully formed. They may have germinated from the seed of some idea that one individual had or they may have been created to solve some problem. Either way, that is only the origin story of the product. To reach its mature form, required the efforts of many people over some period of time and we classically refer to this as a project. A project has the creation of the product as its end goal. Once that goal is achieved the classical view is that some organization, an organization that may have been created coincident to the creation of the product, will take ownership of the product and use that asset for the betterment of the organization. If the single product is the sole asset of that organization, its fortune will be tied to the product life-cycle of that asset and will cease to exist with the retirement of that product.
Contemporary software engineering research owes a debt of gratitude to the open source movement. The benefit of the movement to research is the open nature of the work. Rather than guard the artifacts of software development behind the shroud of proprietary secrets, the open source community thrives on an atmosphere of complete transparency. Even better, it has a tradition of maintaining these records for posterity making longitudinal study possible in a way that is unthinkable with for-profit corporate development. The oldest and best known of these efforts is the Apache web server and the organization it spawned. It is this organization and the many products that can be tied to this organization that has been my latest object of research.
The history of the Apache Software Foundation is well known. It has matured as an organization over the years and epitomizes a form of software creation and stewardship that is neither completely altruistic and selfless nor constrained by the commercial marketplace for software. As such, it may, or may not, result in software that is qualitatively different over the product life-cycle than the products from such well known software houses as Microsoft and Oracle. But whether they are different or not, it is possible to study the inception, growth, decay and retirement of these software products in ways that are impossible for the commercial products. It is the forces of this evolution that I am drawn to and am looking very closely at in the various Apache projects. (Note that unlike a classic project, an Apache project is really an organization that is responsible for both the creation, maintenance and general stewardship of the software product until its retirement.)
A thesis I have is that program correctness is not really the most appropriate aspect of the dynamic code maintenance that most of my colleagues think it is. Rather I believe that it is the change in the non-functional behavior of the product that drives more decisions, and ultimately predicts the ultimate failure of the product. The froth that is seen around the correctness of the product is certainly important. But a product that fails to deliver in performance, scalability, maintainability, adaptability or any of dozens of other qualities will either find a niche or will need to be re-engineered to meet these new challenges.
I say re-engineered in the sense that the small focus of most enhancement requests or bug reports do not allow for a scope that is sufficient to address the refactoring that is most often needed to achieve these ends. In many cases the skills gained by the creation of this product result in a functional team that are motivated to either significantly enhance the product to give it those qualities or to leave the product as is and create a new one via fork or greenfield development that will improve upon the prior product in these key qualities. Often the relationships between these distinct products is overlooked and the debt one product owes to a prior product lost in the mist of time.
The history of the Apache Software Foundation is celebrated. But every day there are projects that choose to put their products into retirement because of lack of interest. If other projects were spawned by the project, they are sporadically documented, sometimes in the project archives and communications, or sometimes through the press which covers open source development. What I have lately come to realize is that there is no interest in documenting this history and as web links rot or repositories taken off line, history is being lost every day. It is perhaps Quixotic to concern myself with trying to prevent this complete loss but I do. As such, I am trying to document as many origin stories for Apache projects as I can in the belief that if I do not, some of this information will eventually become unattainable. What is harder is to justify this effort in terms of my own research.
No major software product exists that did not require thousands of decisions, some big, most small, made by the team members over time. Software developers are notoriously averse to documentation so these decisions are as often inferred as observed. This is where Big Data and the statistical methods of empirical software engineering are most helpful. But where the data is not available in a form usable by these techniques, the techniques are useless. Since the gathering of this data and putting it into a form that is suitable for quantitative analysis is exceedingly tedious, it is usually not done. In this reticence to tackle difficult data gathering tasks, I see an opportunity. I see this as an opportunity to both do the deep dive into more interesting decisions made during software development, their relationship to the form and structure of the software system and also make a significant contribution to the preservation of some important history that may have value for researchers in the future. Perhaps I am suffering from a touch of hubris in this but it helps my motivation to feel that my contribution may surpass my own prosaic goals of satisfying institutional requirements for a degree or getting some papers published.
I'll end my post here since the work is ongoing and quite fluid. But this post gives me a short statement that I can share with others who may take an interest in my current direction.
Large software systems that reach any great level of popularity do not fall from the sky fully formed. They may have germinated from the seed of some idea that one individual had or they may have been created to solve some problem. Either way, that is only the origin story of the product. To reach its mature form, required the efforts of many people over some period of time and we classically refer to this as a project. A project has the creation of the product as its end goal. Once that goal is achieved the classical view is that some organization, an organization that may have been created coincident to the creation of the product, will take ownership of the product and use that asset for the betterment of the organization. If the single product is the sole asset of that organization, its fortune will be tied to the product life-cycle of that asset and will cease to exist with the retirement of that product.
Contemporary software engineering research owes a debt of gratitude to the open source movement. The benefit of the movement to research is the open nature of the work. Rather than guard the artifacts of software development behind the shroud of proprietary secrets, the open source community thrives on an atmosphere of complete transparency. Even better, it has a tradition of maintaining these records for posterity making longitudinal study possible in a way that is unthinkable with for-profit corporate development. The oldest and best known of these efforts is the Apache web server and the organization it spawned. It is this organization and the many products that can be tied to this organization that has been my latest object of research.
The history of the Apache Software Foundation is well known. It has matured as an organization over the years and epitomizes a form of software creation and stewardship that is neither completely altruistic and selfless nor constrained by the commercial marketplace for software. As such, it may, or may not, result in software that is qualitatively different over the product life-cycle than the products from such well known software houses as Microsoft and Oracle. But whether they are different or not, it is possible to study the inception, growth, decay and retirement of these software products in ways that are impossible for the commercial products. It is the forces of this evolution that I am drawn to and am looking very closely at in the various Apache projects. (Note that unlike a classic project, an Apache project is really an organization that is responsible for both the creation, maintenance and general stewardship of the software product until its retirement.)
A thesis I have is that program correctness is not really the most appropriate aspect of the dynamic code maintenance that most of my colleagues think it is. Rather I believe that it is the change in the non-functional behavior of the product that drives more decisions, and ultimately predicts the ultimate failure of the product. The froth that is seen around the correctness of the product is certainly important. But a product that fails to deliver in performance, scalability, maintainability, adaptability or any of dozens of other qualities will either find a niche or will need to be re-engineered to meet these new challenges.
I say re-engineered in the sense that the small focus of most enhancement requests or bug reports do not allow for a scope that is sufficient to address the refactoring that is most often needed to achieve these ends. In many cases the skills gained by the creation of this product result in a functional team that are motivated to either significantly enhance the product to give it those qualities or to leave the product as is and create a new one via fork or greenfield development that will improve upon the prior product in these key qualities. Often the relationships between these distinct products is overlooked and the debt one product owes to a prior product lost in the mist of time.
The history of the Apache Software Foundation is celebrated. But every day there are projects that choose to put their products into retirement because of lack of interest. If other projects were spawned by the project, they are sporadically documented, sometimes in the project archives and communications, or sometimes through the press which covers open source development. What I have lately come to realize is that there is no interest in documenting this history and as web links rot or repositories taken off line, history is being lost every day. It is perhaps Quixotic to concern myself with trying to prevent this complete loss but I do. As such, I am trying to document as many origin stories for Apache projects as I can in the belief that if I do not, some of this information will eventually become unattainable. What is harder is to justify this effort in terms of my own research.
No major software product exists that did not require thousands of decisions, some big, most small, made by the team members over time. Software developers are notoriously averse to documentation so these decisions are as often inferred as observed. This is where Big Data and the statistical methods of empirical software engineering are most helpful. But where the data is not available in a form usable by these techniques, the techniques are useless. Since the gathering of this data and putting it into a form that is suitable for quantitative analysis is exceedingly tedious, it is usually not done. In this reticence to tackle difficult data gathering tasks, I see an opportunity. I see this as an opportunity to both do the deep dive into more interesting decisions made during software development, their relationship to the form and structure of the software system and also make a significant contribution to the preservation of some important history that may have value for researchers in the future. Perhaps I am suffering from a touch of hubris in this but it helps my motivation to feel that my contribution may surpass my own prosaic goals of satisfying institutional requirements for a degree or getting some papers published.
I'll end my post here since the work is ongoing and quite fluid. But this post gives me a short statement that I can share with others who may take an interest in my current direction.
Subscribe to:
Posts (Atom)