Simplicity

I found an interesting comment suggesting Lego blocks as an example of how simplicity could make software better. The poster argues there are "no complicated things" in the universe, but that things often merely seem complicated, an illusion our perception of the phenomena, and that if we just look closely enough (reduce it to parts---reductionism) a simple, linear, non-paradoxical design emerges. "Just look closer" the argument goes and you will see the simple, discrete, isolated building blocks of the seemingly complex system.

This is the reductionist argument.

The poster says this of Lego:

Let's take LEGO. Do you need to test LEGO package? Ofcoz, not. Do you need to test EACH (of hundreds) piece? No.
You have:
1. Global design.
2. Common interface to connect bricks (piece) to each other.
3. Pieces specification.

The problem with this analysis is it ignores that in real complex systems, wholes are sometimes parts and parts are sometimes wholes. Object oriented programming, tries to encapsulate each piece of information or action in a single "Lego block" isolated from all other software components, connected through standard interfaces like the pegs on a Lego piece. It is wrong to apply a mechanistic solution like that of the Lego blocks to information. Software is essentially information, and pieces of information can relate to each other in paradoxical ways, just as numbers and theorems in mathematics can. It's difficult for a Lego block to be a part and a whole, although each block is a whole that can be a part, but there is less chance for paradox and feedback in the Lego block system than say in the atmosphere or the soil.

In the soil, we have a physical system, but the "parts" that are interacting are not "real" but emergent, such as "fertility" that cannot be located in any one place. Thoughts in the brain cannot be located at anyone one place or time either.

One of the major problems I see with the building block approach to software, the object oriented approach, is that it tries to sever the very feedback loops that make a complex system interesting and useful. It fights against complexity until it creates more confusion or rigidity than it is sometimes worth. There is an entire field of study in computer science centered around the "object relational mismatch," which is just a fancy term for the reality that applications are constructed using inflexible objects and relational database systems store information in ways that can be retrieved paradoxically.

In a relational database, parts can be wholes and wholes can be parts, yet there is no system I know of that can capture this kind of complexity, no application or computing framework that can take advantage of the capacity for paradox and feedback in the database. No, the application must have its rigid, isolated objects, where an address book entry is always an address book entry and its parts are its own business and cannot be part of another entity.

In a database, some entities do not even exist until a question is asked. A new unnamed entity is created by the answer to a question the designers of the database never considered and could not foresee. Very likely "expert system" approaches will one day resolve this problem, applications being developed using coding techniques that are capable of handling paradoxical relationships.

So, I do not believe enforced simplicity and borrowing design principles from mechanistic systems like Lego blocks are effective. Complexity exists, we can't put our heads in the sand, plug our ears and continue pretending it doesn't exist, some day the object oriented paradigm will crash and burn and some new one that takes complexity into consideration will emerge.

Social File Sharing

I recently received an email from a well known supplier of enterprise level file sharing systems. In the enterprise, one solution is called "Wide Area File Services." There are other ad hoc solutions. I am not very familiar with the details of these systems, but understand some of the problems they are trying to solve. A corporation wants fast, simple access to files from any location (anywhere their employees are) while ensuring users access a single version of the file. The are also concerned about the cost of bandwidth (which ensuring a single file helps, since users normally waste resources copying and forwarding a file or video by email, since they are really not aware of the consequences and generally do not understand they can just forward a link).

Although these issues are important, I think this perspective misunderstands the most important need today. Corporations are always concerned about meeting requirements, being defensive, controlling their population of employees more than they are about doing something new or finding new and better ways to do something. They are blinded to solving the problems of how to do more things better by the need to clean up the messes their productivity and growth creates. This is why they are so often blindsided by innovation.

What we really need is social file sharing. What good is sharing a file, a digital photo, video or spreadsheet without knowing who it came from and what group it belongs to? It starts with a simple idea:

Every piece of information should be accompanied by the identity of persons or group to which it belongs wherever it goes.

I've given this issue some thought before, but the email reminded me of it. By "belongs" I mean to include both the individual or the group to which the file is associated with in a given social network. For example, we already see an example of social content sharing through sites like Facebook. Of course, YouTube is also a kind of platform for social sharing of content, but there the concept of "file" or a package of information anyone can take with them and carry it onto their PC or laptop or cell phone or save on a CD is missing. And no, YouTube is not good enough. What we need is a way to retain a media object's social connections as it is transferred from system to system. To do otherwise would imprison files on their respective platforms.

When I upload an image to flickr, any social connections formed around the image is contained within the flickr ecosystem. If I download the image and then share it with someone, the social connections are lost. If I share the original image with someone by email, it lacks the social connections the version on flickr acquired. Why can't all these versions of the image somehow carry social connections the same way EXIF data carries meta data about the production and authorship of the image?

Maybe someone is working on this right now, perhaps a modification of existing RSS standards to allow social network information along with an attachment, creating a kind of "podcast" that could bring social data along with the file. Maybe Google's open social network framework is looking at this. But whoever does it, it is important that it gets done.

Open Flash Charts

I recently discovered a wonderful new open source project for creating Flash charts. It is open source, non-proprietary and best of all for a non-profit on a tight budge, it is free. In the last week I deployed Open Flash Charts after integrating the package into our Folkstreams content management system. For users of our system (through their personalized area My Folkstreams), this will be a great improvement in the quality of charts. We make the statistics on visitors and video views available to filmmakers, and the Flash charts are simply beautiful compared to our old ones based on phplot.

You can download the code for OFC (Open Flash Charts) from their homepage. It is the work of John Glazebrook and he must be a designer, because the default charts in the tutorial are beautiful and take advantage of the interactive features of Flash. I discovered a few kinks that need working out, but overall, this is an excellent addition to the open source code making up the Folkstreams platform.