Chicken and Egg

In all this dry and serious technical world, the call for human aspects gains more and more attention. If it is really the case that human beeings have to create all these products born out from mathematics, logic and rationality then for sure we have to look at the poor human beeings in this process. How will they feel, will they like what they do, will they be happy ?

Lets switch to a chicken farm. The fate of the chicken is to produce eggs, a thing which seems naturally for them. Chicken dump eggs. So it may be that the chicken is happy about every egg because it is the sense of its life, and it sees this sense of life. And if the egg is there the chicken bothers about the egg, until this tiny little white thing changes to a young yellow chicken. Reached that, the chicken feels good, yes ?

Now, in the nasty modern chicken farms, where the chicken are doomed to sit very close together, nearly impossible to move or to see anything other then steel and other chickens, it is hard to imagine that the chicken will be happy. It cannot see its egg, because in the moment it is released from the body the egg is taken away. The chicken has no contact with its sense of life, and there are not the conditions to produce high class eggs: different food, fresh air, sunlight, movement and normal interaction with all other chickens.

The creative mind may have the idea to produce the best eggs ever by the most luckiest chicken ever. What lucky chicken, they can walk in an english garden, the earth worms are hand selected and at least 5 inches long, room temperature is very convenient, like a warm sunny day in spring about tea time. Also the chicken has not to lay any egg if it chooses to do so. In this lucky fate any egg which we get must be the best egg ever, nor ?

What I want to say is this: the key word is balance. Is all about the product, but also about the humans and the processes (including technology) to build that product. But no factor is more important than the other. Sometimes, I have the impression that in some discussions the human factor is overstressed. All factors are interwoven with the processes and laws, which have to be considered. Neither is software development to set up like a chicken factory, nor like the paradise for self fulfillment of software developers. The balance has to be hold.

Hello, Siri

Apples Siri is from my point of view the most underestimated thing at iPhone4s. It fact, it could be the start of another change touching everything. Although a good working speech recognition has still some fascination, we are got used to this the last years. Automatic call center and the speech command in my car are well known examples.

There are two other properties of Siri, which are special: using knowledge and using context. You have no longer talk some isolated commands like "Radio" "on". You can talk like you would do with a person - a beginner or child - but a person. And to the second, this "person" has knowledge and context awareness. By using data from location services, database, documents etc. it is possible to provide interpretation of what the user said. It is a first step in a much bigger world, the artificial understanding. When speech recognition is our planet, than artificial understanding is like offering the milky way to us.

For me its not the matter if Siri work exactly like described above or if there are many problems with it. It is the start of a new way to work with artificial intelligence. It is a hypotheses of mine that the universe works probabilistic. I belief that the physics we use today - with solutions of algebraic equations - is just the recognition of an average or of limits. In Quantum Theory and statistical thermodynamics the probabilistic nature is directly observable. And my strong belief is that the brain is - as far it relates to knowledge processing and control - and statistic engine, were one brick of it is association and pattern recognition.

Collecting and correlating knowledge pieces - which we can call documents - and building knowledge from it is the thing which really impresses me on the IBM Watson project. And for this judgement, it is irrelevant that Watson is built on brute force and a collection or hand-made optimizations for special problems. We come closer to a theory describing this all with time.

The important thing is this: Siri (I think) and Watson are knowledge processors in the sense above, and move our view to the probabilistic nature of the universe, also shifting our paradigm what computers can be good for, maybe even the paradigm how to use this huge knowledge and database called Internet.

This is like all things begin: small and decent ;)

Tell me a story

Today, I've read architectural documents as preparation for a functional safety analysis. Such an analysis is performed to come to an assessment if the given system and its architectural elements fulfill the safety-related requirements. As you might imagine, for doing this work it is helpful to understand the effect chains and the overall operation of the architecture.

So, sitting there and trying to collect the facts spawning out of the pages into my brain, hoping to puzzle together an picture (the picture of software), one thought flashed in my mind: can architecture documents tell stories - and even should they ? (For those who read my last post, lets assume the Constructible Hypothesis is true).

Technical Systems are built from human beings (Well, at least at the moment) Because humans evolve day by day with growing experience causing shifting look at things and moving attitudes these technical systems have history. Humans learn about problems, learn about solutions and in consequence learn to evolve methods and tools.

But not only the creator has history, also the environment = the source of the problems is non-static. Customers have new wishes, technical or environmental constrains change. All this together make it undeniable that a technical product has history. For example, many things on modern ships have their roots in the old wooden sailers. The instrumentation of the airplanes are frozen history of aviation construction.

There is a move citation (I think it was "Big Trouble in Little China" with Kurt Russel): "Thats like all things begin: small and decent". Yes ! This is the power of knowing history: the first versions of things are often simple, not elegant or efficient, but small enough to not covering the basic idea behind a solution. Or better: in the beginning of technical things the intention of the architectural elements will be visible. Going back in history means going to the core part of a technical mechanism, the will of the creator. Going back means to get insight into the basic idea of things.

But there is more. We said technical things evolve. But they evolve not without reason. If technical properties or functions being added, that should be done because of a changed requirements ! So history should tell you a story about sound decisions, why this function or this effect added to the system, and why the old system was not good enough. Again, evolutionary steps have an intention behind them (hopefully !). This is far from trivial, so many team members don't know why software module x or parameter y were added. Look how many things are introduced and killed later on because the knowledge of their introduction got lost.

Now, knowing the history of a technical product seems good. But the question is now can an architectural documentation tell the history ?

Please don't think at the huge version trees of such tools like CVS or Subversion etc. It is not practical to write down a full history log, of course not. But if you see an technical product as a chain of design decisions, controlled by intentions, it might be more clear how to document:

show the basic problem and the basic idea, and show the most important intentions from the historic sequence of intentions shaping the architecture as it is today.

Showing intentions is not necessarily complicated: well chosen names and wording can suggest what the basic idea or problem was. Also, arranging the document along an level of detail gradient can have the effect to present the reader a time trip. AND: show the associated problems !

But my statement is this: just nailing down an architecture as it is in front of you is often not enough. Such documentation may be useful for rebuilding technical things only (schematics for example), but not to understand them. Or to say it much easier: show the human factor in the architecture.

I know, this is no precise plan how to write documents. This may be part of a later post :)