I have spent considerable amounts of time thinking about the concept of information and how to convey it in software. Some years ago I came to the conclusion that I want to present information in context, e.g not present crude extracts from databases, but adapt it to the presentation context, with the user in mind.
Some useful contexts could be "location" or "social networks" - the context should be varied depending on the type of information context - e.g information about abstract concepts have no use of location information. The use of context should increase the likelihood of the information being conveyed to the user in a understandable manner.
When I observe users, I rarely see one user that uses only one tool to achieve her goal. Information gathering is usually done using a variety of sources - so a good system design principle could be to know where the system should stop - and how to present the information in a such a manner that supplemental or related information can be retrieved from another system.
So , to me, presenting information in context is also about presenting the least amount of "friction" in the system. Here I consider any obstacles hindering information flow in and out of the system as "friction". By minimizing the "friction" we make it easier to present information in context by connecting data between systems.
This has lead me to think that good system design should focus on how information is shared between users via connected systems. Turning the attention to how information is shared between users via connected systems, then we obtain a understanding what the data is (since we need to be able to share it).
When talking to people about BDD and my lame example using Paris Hilton, then I got the question "it was really interesting reading about Paris Hiliton .. but what is BDD really about?.
The central insight of BDD is that TDD is really computer aided specifications of the executable behaviour of your system. BDD tries to express this using a Domain Specific language.
Back in 2006 , Dave Astels described how to ascend from the focus on 1-1 testing of production code to use the test proces as a way to describe the way you want your system to behave.
In the video Dave makes the valid point that "The words you use shape how you think". So we should go away from thinking about "testing" constantly to think about describing how you want your system to work.
So to me - BDD sounds like a kickstart to be productive in TDD - and do it well from the start. So if you are starting out on TDD , you should really start out doing BDD.
Recently, I have been giving Behaviour Driven Development some thought.
Let's take a an example of how to develop and test a music video search and storage system. A traditional way of developing this would require formulating a object oriented system architecture, thinking about streaming and metadata enabled search. The system architecture could consist of a well chosen database server, a streaming server and a metadata enabled search engine - combining these technologies with a modern UI and encapsulating theme in carefully designed object oriented structures. During all these important choices , and all during development we would make sure to write tests before we write a single line of code.
All these things put together would lead to a well thought out system architecture , but all the effort put into the system architecture can be in vain - if we don't have a solid business understanding of what a video storage system should do. What will the users expect?
While browsing on facebook this other day I found the "The Paris Hilton & Jacques Derrida Appreciation Society" - this group explores the connections between the works of Paris Hilton and Jacques Derrida. When we deconstruct the "pretty blonde" facade of Paris Hilton, then you can actually find some deep insights. Take "Nothing in this world" for instance:
Take the phrase "when you are with somebody else, that's me in your eye". There is the obvious interpretation of the sentence . But thinking about that sentence also let's you reflect on the real meaning . When you look at Paris Hilton in this video, what do you see? Do you see the pretty blonde or the millionaire , hard working young girl . In this video I am seeing the image of the pretty blonde - but I am also thinking about the millions of dollars she is earning portraying herself in this way. So in a sense - I am reading the original message out of context. I am admiring what Paris Hilton in some other way than she intended - the original meaning of the words seem to have disappeared - but my understanding of the sentence is more useful to me. I wish I could do what Paris Hilton does - but in a way that would make sense in my world .
The producers of the "Nothing in this world" video are not likely to convey information about the business empire of Paris Hilton in the metadata supplied for the video. So a system formulated as a "video storage system" would not let me exploit the information I found in the facebook group.
BDD introduces the use of a Domain Specific language to express the users expectations in a manner more directly focused on the behavioural aspects of the system. This lifts the clouds from the system aspects and focuses on intent.
A better way to formulate my expectations for the system would be:
Describe the music video storage system:
I should be able to search for videos using metadata
it should play videos in my browser
I should be able to query facebook for information about it
If I had those expectations formulated to me , then I would choose to implement this system as a mashup between youtube and facebook as a facebook application. This would be a radically different system architecture than the one describe above.
Furthermore , by leveraging one of the several BDD test frameworks available, then the expectations could be formulated in way that can be used as tests.
Listed as one of the of five deep questions in computing , this questions stands out to me as the one question we have to answer before we can answer questions like "what is computable" and "(how) can we build complex systems simply".
To me the concept of "information" only makes sense if it can be extracted or related using wellknown techniques. In this sense "information" is put in the context of a "subject" and a "object" , e.g. the information identifies facts about the "object" in a manner that is understandable for the "subject". When information allways should occur "in context", then it should be clear that the information should be codified in a manner that is understandable by the "subject".
This "codification process" is successfull when the information about the "object" is conveyed to the "subject" in a manner that is easily understood - so in my interpretation "information" can be expressed in many ways , and still be intended as the same information about the the same "object".
In most concrete circumstances involving human communication "codification" will mean "telling" somebody "else". E.g saying "I am hungry" .. or "do you mind passing me the water". Information is revealed through use of language in a sentence and placed in the context of the situation where the sentence is spoken.
In most traditional computing software information is stored to examine facts about phenomena or physical items. The wealth of information in context has been lost in the process of gathering these facts. Take a traditional supply store. It is not very common for the desk clerk to capture the facial expression of the customers while entering the items bought in the cash register. So in this way, the information from the facial expression is available to the desk clerk but not the store manager.
In our current computing systems, then it is not easy to compute "the mood of the customers" - but if we understand the wealth of information lost in the "codification process" then we can exploit this for a better understand of the market siutation . But we will still not be able the compute the "mood of the customers".
So - to me information can only be understood as "information in context". I will try to design complex systems from this where it makes sense.