Data, Information and Knowledge

For my purposes, I define:

  • Data is the “in flight” potential to induce informational change; more specifically, data is a signal or energy (boson)
  • Information is a particular state of matter (fermion)
  • Knowledge is information encoded in the mind and available to our self-aware cognitive processes (consciousness)
    • Information encoded into the nervous system but not available to self-aware cognitive processes I will continue to associate with the more inert moniker of “information”
    • Wisdom is another matter entirely!

I like these definitions because they seem to help to clarify concepts in common with both information theory and physics.

Advertisements

Do Corporations Have “Goals”?

Does a corporation possess goals?  What is a goal?

http://en.wikipedia.org/wiki/Goal

From the Wikipedia definition of “goal”,

A goal or objective is a desired result a person or a system envisions, plans and commits to achieve—a personal or organizational desired end-point in some sort of assumed development…

The error in this definition is the inclusion of the idea that a non-conscious system could possess a goal.  This is an example of fallacy of reification I described a few days ago.  Systems, including companies, do not possess goals, people do.

In corporate settings various charters, such as project or program charters, describe sets of goals the activity is associated with.  It is frequent that participants in these activities then associate these goals with the activity itself, as if the activity was a conscious animal of some kind.  I believe the fallacy of reification is strongly associated with the phenomenon of failing to question these goals when real life data comes in conflict with them.

It is expedient to think that the activity “lives” in some say.  Each human can only hold so much information in their heads at any one time.  The human social capacity has known limits famously described by Robin Dunbar,

http://en.wikipedia.org/wiki/Dunbar%2527s_number

Perhaps it is easier to believe that the activity is a single person, perhaps a person who must be obeyed, than to continue to track all of the people who contributed to the identification of any one goal or another.  When reality conflicts with these goal, how many people bother to draw together the participants necessary to reexamine these goals?  What do people do with conflicting goals of very long-lived activities, perhaps with such goals as those written into a corporate charter by people who might even be long dead?

Reification can serve as a convenient mental proxy for the myriad other players involved in the initial identification of goals and other elements of human value in complex collaborative situations.  It is easy to forget that reification is an energy saving convenience.  The epistemological worldview that results from reification however does not reflect metaphysical reality.  Written goals are associated with people, fallible people who should never lose sight of objective reality.  If a goal conflicts with reality, one must muster the energy to seek the collaborators necessary to adjust the conflicted goals.

Reification, Computers, Companies, Countries and Charters

To reify a concept is to reduce an abstraction to concrete, or objective form.  Reification always occurs within a context,

Constitutions and articles of association are specific examples of the more generic concept of a charter, which is a type of agreement (arguably, a type of contract) which is used to reify any collaborative system, from countries to corporate departments to professional organizations.

Software Process, Like “Method” in Science, is Bunk

My response to James Turner’s article, Process Kills Developer Passion,

http://radar.oreilly.com/2011/05/process-kills-developer-passion.html

…you’re spending a lot of your time on process, and less and less actually coding the applications… The underlying feedback loop making this progressively worse is that passionate programmers write great code, but process kills passion. Disaffected programmers write poor code, and poor code makes management add more process in an attempt to “make” their programmers write good code. That just makes morale worse, and so on.

Software process, like “method” in science, is bunk!  I finally understood what the philosopher Paul Feyerabend was trying to say.  What is important is the data, or the stuff of reality, otherwise known as results.  Experiment (software tests), deduction and induction are all very important but no two people are going to arrive at their conclusions in the same way.  That is, no two people process data and leverage their capacity for deduction and induction in the same way.  One person’s process (method) is another person’s confusion.

If you want to de-motivate a creative scientist or software developer, force them to think like someone else who isn’t them.

Process is no substitute for knowledge.