Sunday, March 30, 2008

Software Doesn't Rot, But What If It Could?

Code is not magical, rather when you have no clue what is going on 'under the covers' it can seem that way. For example, use any google product, and stuff just works. Functions correlate with intuition such that you are totally task focused (find x, email y, blog z) rather than sidelining your task to deal with the particulars of an esoteric perspective of a process. In particular I feel that the decoupled nature of 'software' and 'activity' when I used to play a computer game, or more recently why I'm observing the real-time sampling behaviour of a stochastic optimisation algorithm. The game environment becomes my temporary reality, or I treat a complex process as an entity independent of the code I have been slaving over for weeks. Even with an acknowledgment of computability theory, it is easy to forget the fine grained design determinism of the software we are using, and focus on its capability to facilitate communication and automated computation.

Problems regarding the maintainability of software are referred to as software rot, which basically describes the mismatch of a software system to its use. It is an emotive analogy from software engineering, and like Software Evolution, it provides a useful context for aggregating related concerns, although can cause problems when pushed too far. For example, I recently had a discussion with a colleague who was interested in investigating software development and release cycles as an evolutionary process, an idea I quickly dissuaded him of pursuing. Likewise, software rot can be pushed to far when people start using terms like software getting 'worn out' to describe software maintenance problems. Although software is automated logic execution, it is not mechanical (although the mechanical perspective is another attractive perspective), it does not wear in the physical sense. I was reading about the inherent lack of value of discrete logic in software when I was reminded of a notion I had a number of months ago: what if you create a system in which everyday software can evolve and can be worn out.

Naturally you may jump to notions of evolutionary algorithms, specifically Genetic Programming which is a nice automated inductive logic generating process, although scales poorly with regard to complexity. I'm sure that all the smart kids that are hooked on GP hace a similar dream for software, at least initially. This was not the first place I went, instead I was thinking more generally. Irrespective of the technology used to achieve the effect, the problem is that of 'automatically' (using computation) rather than 'explicitly' (via human designed and coded updates) refining the adaptive fit of a software system to its application. The problem, as is usually the case with interesting problems of adaptation, comes down to that of credit assignment. Specifically: how to identify and measure the adaptive fit of the software system? For example, is it the features used or logic executed that is important? I suspect that the problem is domain dependent, and also that it is possible to devise a general 'good enough' method. I believe that there are a lot of indicators that could be exploited, although selecting 'useful measurements' is by and far the hardest part of the problem.

Wear can be a good thing in physical systems, especially mechanical systems made of metal. It can help find the sweet spot, although tends to need lubrication and eventual replacement. Evolution also has its benefits such as ruthlessly although slowly adapting species to a (typically changing) ecological niche.

Two important influences on my thinking are both web based (the Internet is an everyday application right?): distributed generative art, and real-time interactive art. Specifically, I am referring to the use of automated inductive processes (like genetic algorithms) that exploit feedback signals from multiple users (computers), such as Picbreeder, Electric Sheep, and others. Regarding real-time interactive art, I am referring to web pages that allow many users to work together on some product like The Broth, Beauty in Chaos, drawball, and others (I posted in '07 about these technologies [pdf]). I like these examples because the art focus makes the underlying idea of collaborative product adaptation far more transferable. The examples also highlight that the collaboration can be explicit or implicit, the latter of which is likely the most powerful (less intrusive).

Forget the method for now, assume we can measure well and do all our induction and reasoning reliably. I have a fast computer that typically does nothing, so lets further assume that the computation for such adaptation is local for both local and distributed applications, although likely reasoned from an aggregated corpus of collected information. This provides a platform to begin reasoning about the behaviour and effects of such software systems.

Notions of developing a browser or similar complex logic from scratch is preposterous, although consider a browser augmented with such capability. Beyond smart menus, consider a population of browsers (entire user base) refining themselves to their users, likely streamlining away all those menu options that are never clicked and logic never executed. Think bigger, such as biases on the network connections that can be made (only visiting US sites, or reddit on Friday afternoon), or even the mechanisms by which URL's are perceived and manipulated. The adaptation of fit is not constrained to adding and removing features, but rather the more subtle influence over the interaction of the user with their application process based on individual or aggregate behavior. A raw HCI task focus of interactions provides a powerful optimising lens with which to automate the refinement of software.

Away from science fiction for a second and back to the web. As highlighted by the AI Effect, and acknowledge by any software engineer who has had to write user interface validation logic, there is a disparity between perceived system behavior and perceived underlying complexity. Good software is easy to use and it is hard to make, although does it have to be a human that makes it? When I visit a web page for the n'th time, I want it to recognise me, remind me of all the good times we have had together, and suggest a relevant current offering of information to digest. I want the process of reading news to be like an old friend telling me gossip that he will think I'm interested in hearing. Instead pages are generally static, dynamically generated for the masses or 'people like me', not for me. I never want my emails listed only by order of arrival, I want they prioritised by maximum pay-off of me responding to them. I think putting up with software rot (more likely maladaptations) is worth the expected gains of such primitive improvements.

2 comments:

Joe said...

> I want the process of reading news to be like an old friend telling me gossip that he will think I'm interested in hearing.

That's exactly what we are building at jaanix. Have you seen it?

nomemoryspace said...

I learned the hard way the most important thing in UX (it's a bit counterintuitive at first sight) : when a group of people have to interact they must share the same UX.

if you start customizing UX individually, you start isolating users and losing interaction. people learn from each other.