Papers referenced below should become available on IEEE Xplore.
Why is it that on the academic publication scale journals trump conferences and conferences trump workshops and yet the most interesting interactions with colleagues and opportunities for creative insights occur at workshops? I think it is an unintended consequence of the drive to publish.
The event was held at the Sheraton Society Hill on Philadelphia's Dock Street. It is a perfect location for visitors. It is close to the historic district, home to the Liberty Bell and Independence Hall. The City Tavern, founded in 1773, is just around the corner. I particularly recommend the sweet potato and pecan biscuits, reportedly a favorite of Thomas Jefferson.
Commodore George Dewey's flagship USS Olympia lies on the Delaware River, just two blocks from the hotel. It was an easy walk, so I toured her during the lunch break. I have often used the Spanish-American War of 1898 as an analogy for the current war in Iraq (in that it was a war of choice, opened unilaterally by the US president for bogus reasons and resulted in decades of unwanted and expensive American entanglements overseas). It was thus fascinating to stand on the bridge of Olympia, from which Commodore Dewey said, "You may fire when ready, Gridley.", defeated the Spanish at Manila and established an American territory over the objection of the Philippine resistance government. Olympia is a fascinatingly transitional example of naval architecture. She bristled with guns, has a steel hull and was the first warship fitted with a water cooler. She had refrigeration, based on expansion of compressed air (not freon). Her copper coffee boiler was thoughtfully lined with lead (!) to prevent copper poisoning. She is a wonder of space, except in the crew's quarters, which still had hammocks and co-located mess tables. Her officers staterooms were each private and furnished with heavy wooden bureaus, wardrobes and desks, much nicer accommodation than on modern warships. On the other hand, the beautiful glass-and-wood skylight above her officers' country could have been lifted from a wooden ship of the line. She carries two steel masts used for auxiliary sail (a good idea when burning 20 tons of coal per hour when at top speed) and a metal-componented "rope" ladder to her forward lookout station. The battleship New Jersey, huge, imposing and arguably an icon of the military dominance of the United States during the twentieth century, was visible at her museum berth across the river at Camden, New Jersey. The Olympia was there when the US became a military superpower and the New Jersey helped to assure its dominance for nearly a half century.
Bob Laddaga from BBN Technologies gave the workshop's keynote on self-adaptive software. Unfortunately, he, like many older geeks, insisted upon applying control theory to large-scale, non-linear systems. I understand the temptation - I learned control theory when I was young, too. That doesn't make it a good idea. He admitted that the available mathematics were insufficient to the task, but apparently didn't have a better approach. We really need to break out of industrial modes of thinking to address these problems.
Christopher Nehaniv from the University of Hertfordshire spoke on "What Software Evolution and Biological Evolution Don't Have in Common". I was predisposed to enjoy this talk because he started off by mentioning that evolutionary approaches could equally apply to memetics. He used the design of spoons over time as an example. The paper was an attempt to rigorously define the differences between the natural and software domains. They defined the term genotype as inheritable information and phenotype as everything else (non-inheritable information). We could all argue that for a while.
The workshop chair, Paul Wernick (also of the University of Hertfordshire), asked whether certain software metrics, such as loose coupling between modules or high cohesion within modules had been proven to be correct. Nobody in the room knew the answer, but they all suspected not, at least not rigorously. I really need to track down the answer to that.
I wonder if whether the problem with applying evolutionary algorithms to software will suffer the same fate as control theory as applied to software. We are desperately searching for the right analogy, but having trouble defining what a genotype, or a phenotype or evolution in general are in relation to software. Which one is more complicated, software or biological species? Humans would seem to have roughly 30,000 (rather complicated) genes, and some pine trees have roughly 45,000 much simpler genes. Are the "genes" in software systems simple or complex? In short, applying Darwinian concepts may not make sense in that software does not ncessarily have a population of discrete peers, and so population genetics may not apply directly. Software evolution may need a new theory, developed from the beginning. Taqi Jaffri of Microsoft had the same thought. We talked during a break and he suggested that software evolvability may be the more general case that the biological evolution may be the smaller special case. I tend to think of it more like the figure below:
Interestingly, Nehaniv suggested that the software lifecycle concept should be considered harmful. The reason is that the lifecycle treats a software system in isolation from the system's deployed environment and its developers' intentions. Of course, that seems to be a direct analogy to Darwinian evolution ;)
One of the participants shouted out that one may control for result, or for process, but not for both. Reference?
Chris Landauer from the Aerospace Corporation spoke on "Wrapping Architectures for Long-Term Sustainability". He noted that the three aspects of a sustainable system are functionality, the expected environment and the expected styles of use. People focus on the first, to the exclusion of the other two. That three-prong model was a theme of the workshop.
Nicely, Chris quoted a colleque as calling software the "intellectual caulking material" of our constructed complex systems. I think that applies increasingly to our society as a whole. Consider our kitchens. The refrigerator in mind contains a control board which implements a control system to minimize energy usage. That board has an EEPROM on it, which is embedded software. The designers could certainly have created a purely analog control board, or an electronic one without an EEPROM, but they didn't. They used software as a caulking material.
Wen Jun Meng from Concordia University spoke on "A Context-Driven Software Comprehension Process Model". Her team took a workflow process to enhance software comprehension. They used an OWL-DL ontology and the Racer reasoner. The system is story-based and implemented as an Eclipse plug-in.
Markus Reitz of the University of Kaiserslautern spoke on "Software Evolvability by Component-Orientation - A Loosely Coupled Component Model Inspired by Biology". This is one of the first times I have seen a model of software components based on an ant colony analogy. It looks interesting. However, there are already so many software component models in existence. This one will have to prove that it is useful and that existing ones couldn't serve. Markus claims that his model was necessary. I will have to read the paper.
Bob Dickerson's thoughtful paper on the poor state of the computer industry was read in absentia by Paul Wernick. He had a cute take on software development methodologies, calling them "like tying an elephant to a knitting needle to keep it from rampaging on". I like it. Obviously, one needs a thicker needle.
I did have to correct Paul on one point in Bob's paper. Tim Berners-Lee did not invent the hyperlink (Ted Nelson did). TBL invented the URI.
Bob has decided that procedural programming, the major means of coding and a direct result of Van Neumann's original and still-used computer architecture, is a failure. He criticized the results of procedural programming strongly. However, I tend to support Fred Brooke's view that the problem is not the encoding of ideas, it is the mapping of intent to code. I think that most problems that we have with software development are directly relatable to a failure to understand what we wanted to do.
I presented a paper on my ongoing research, entitled "Toward a Software Maintenance Methodology using Semantic Web Techniques". I added quite a bit of REST orientation to my slides, since my thoughts on the REST architectural style are newer than the paper accepted at this workshop. It was well received. I think I am finally wrapping my head around the subtlety that is REST. It will be interesting to complete the implementation and get to the user studies. I need to prove that these ideas make some positive impact.
Slinger Jansen (Utrecht University) said that my work reminded him of Anthony Finklestein at University College London. He and his students apparently developed a tool called XLinkIt. I need to see the papers.
Huzefa Kagdi of Kent State University talked about "Software-Change Prediction: Estimated+Actual". His literature review included a nice summary of approaches to mining software repositories. He noted that software change detection tends to look at a very low level of the code (within the class/function level). His tool for this work is srcML, which I would like to look at.
Per Jönsson of the Blekinge Institute of Technology spoke on "The Anatomy - An Instrument for Managing Software Evolution and Evolvability". Ericsson in Sweden has a tool known as The Anatomy. Per hopes to reverse engineer the reasons that The Anatomy helps developers and generalize the results into a software engineering style. He wanted to know if the research project made sense. I guess so, since that is basically what Roy Fielding did with the Web and REST.
Paul Wernick (yes, again) presented a paper on his ideas regarding software evolution as an Actor-Network. Actor-Network Theory (ANT) treats society as an intertwined collection of networks of interacting people, things, ideas, etc. Besides actors, the network may include mediators. Actors are constrained by their connections, as well as being free to communicate via them. Complex (in the academic sense) behavior arises. He suggests that people (both individually and as organizations) and software as peers. He thinks that treating them as separate entities might be interfering with the search for the atomic elements of software evolution. He notes that a software system is evolved consciously, it doesn't "just happen". The system influences the users, who demand changes, which creates change requests, which causes developers to change the code... An initial conclusion is that an ANT approach results in a very complex model (surprise!) and is thus difficult to understand. However, ANT could help answer "soft" questions, such as, what happens if the project sponsor loses interest?
Bob Laddaga (BBN) commented that the ANT approach might be too friendly. He sees software evolvability as more of a competition. Paul and Kirstie Bellman (Aerospace Corporation) think that there is room for both friends and enemies in ANT.
Where do requirements fit into such a model? Requirements are a dream, or illusion, shared between the actors.
Ilia Heitlager of the University of Utrecht presented "Understanding the Dynamics of Product Software Development Using the Concept of Co-Evolution". He had an interesting thought that we only use a project management philosophy to create software and that projects have to end. Compare this to product software goals: Exponential growth. Ilia is a former software startup CTO and I was amused at his observations, which sounded familiar ("real data is dirty", "Hegel's Second Law bit us").
Ilia's team implemented their own XML-based pipe description language for their Web-based product. How much easier it would have been for them to have used NetKernel and DPML/BeanShell! This highlights a real problem in the software industry. We still tend to convince ourselves that we just must reinvent the wheel. Of course, licensing is often an issue.
Ilia pointed out the Abernathy and Utterback model for product manufacturing. It relates innovation to transition time. See Figure 4 in their paper. The model was defined in 1975, but has not been picked up by the software development community for some reason. His team is interested in determining whether the Abernathy and Utterback model is applicable to software. That sounds like a really great idea.
The workshop closed with a panel discussion. There a general consensus by the end of the panel that evolution in general transcends biological evolution and that software evolution may be quite different than "decent with modification".
Kirstie Bellman: "We do our students a disservice when we tell them that Computer Science has something to do with computers. It has more to do with our own cognition." This is a good point and a nice way to say it.
Paul doesn't like the term "maintenance". We don't really maintain a software release, we really continuously add features.
Interesting observations on what was a stimulating workshop. Of course the same issues keep cropping up. And thanks for the nice quote from the panel.
ReplyDeleteThe colleague Chris Landauer was quoting was also me. I first used the idea of software as the "intellectual caulking material" of our times in order to point out that software engineering deficiencies are actually often system engineering deficiencies where software was being used to compensate for ill-defined interfaces, new requirements or uses and so forth.
Regards,
Kirstie Bellman