I am interested in the idea of the Meme, because it appears to behave in a manner very similar to a Class. A meme is a container that may contain any amount of meme inside of it. A meme as a knowledge unit suggests a discrete action that it accounts for. A meme may have properties.
A Meme, as a transferable knowledge unit, would consist of at least one noun and one verb. This would correlate to properties and methods in OOP.
It would appear to transfer well as a method of capturing work-flow into an object oriented class structure.
Wednesday, June 18, 2008
Sunday, June 15, 2008
Memes = Knowledge Units
In business, knowledge units are routinely passed from person to person as people shift and change positions. Many people in an organization have knowledge about the functions that a person performs in a position, from the specific to the general. Most often position specific information is passed from position occupant to position occupant. During the 1970’s the study of the actions of a group of business people was called “System’s Analysis.” Today much of a IT group’s understanding of a business knowledge is gained through “Use Cases" or "User Stories."
The User Stories are have more to do with the desired solution, then with what is currently happening, so that the shape of “System’s Analysis,” which was the documentation of current procedures has changed somewhat over time. As now we collaborate more on what we want to happen, then on what happens.
A partial understanding of what is currently happening could be gained using the sociological tools of memetics. Memetics is the study of transmittable pieces of knowledge replicated primarily through imitation. Lots of work flow analysis may benefit from capturing the information that is transmitted from position holder to position holder as natural turnover happens in the enterprise.
A meme is a unit of knowledge that can be transferred between people, usually through imitation. Transfer of knowledge units happens with replication and propagation. Knowledge transfer through an organization has a transformation vector. Knowledge vectors have a tendency to cluster and happen together or "herd", this is memetic association.
A knowledge unit can morph between propagations, not unlike a game of telephone, this is reflected in memetic drift or the meme's copying-fidelity. A meme is thought to have memetic inertia if its characteristics are manifested in the same manner, regardless of who receives or transmits the meme.
A knowledge unit may not always be health and helpful, this is reflected in the Meme's Fitness. A knowledge unit that does not allow another specfic meme to exist is an Allomeme, a mutually exclusive cultural trait.
A meme's rate of replication and therefore its spread is the meme's fecundity. The longer any instance of the replicating pattern survives, the more copies can be made of it, this is the Meme's longevity.
A cluster of meme's is known as a memeplex. A collection of memeplexes is know as a Deme.
As a software developer a portion of my job is to capture the processes in an organization. There are most likely great tools out there to do this, I just don't know about them. So I spend time wondering about how knowledge is transferred around the office, so that I can take my butterfly net and capture it for study so that I can turn it into "machine Instructions."
The User Stories are have more to do with the desired solution, then with what is currently happening, so that the shape of “System’s Analysis,” which was the documentation of current procedures has changed somewhat over time. As now we collaborate more on what we want to happen, then on what happens.
A partial understanding of what is currently happening could be gained using the sociological tools of memetics. Memetics is the study of transmittable pieces of knowledge replicated primarily through imitation. Lots of work flow analysis may benefit from capturing the information that is transmitted from position holder to position holder as natural turnover happens in the enterprise.
A meme is a unit of knowledge that can be transferred between people, usually through imitation. Transfer of knowledge units happens with replication and propagation. Knowledge transfer through an organization has a transformation vector. Knowledge vectors have a tendency to cluster and happen together or "herd", this is memetic association.
A knowledge unit can morph between propagations, not unlike a game of telephone, this is reflected in memetic drift or the meme's copying-fidelity. A meme is thought to have memetic inertia if its characteristics are manifested in the same manner, regardless of who receives or transmits the meme.
A knowledge unit may not always be health and helpful, this is reflected in the Meme's Fitness. A knowledge unit that does not allow another specfic meme to exist is an Allomeme, a mutually exclusive cultural trait.
A meme's rate of replication and therefore its spread is the meme's fecundity. The longer any instance of the replicating pattern survives, the more copies can be made of it, this is the Meme's longevity.
A cluster of meme's is known as a memeplex. A collection of memeplexes is know as a Deme.
As a software developer a portion of my job is to capture the processes in an organization. There are most likely great tools out there to do this, I just don't know about them. So I spend time wondering about how knowledge is transferred around the office, so that I can take my butterfly net and capture it for study so that I can turn it into "machine Instructions."
User Stories are great, but they don't get deep enough sometimes in the processes of knowledge. So I use "User Stories" but think about the propagation of knowledge in the enterprise.
Class-Responsibility-Collaboration hierarchies in databases
Database Structure is the rules of how an organization's data interacts together. This may seem obvious, but if you look at designs of databases and development, you see that the obvious is often ignored when in context. The database structure is the Meta Data, the data that explains data.
An organization, from where I sit in the back office “virtually” consists of a network skeleton that reaches across to nodes, and or satellites. A backbone of heavy iron churns that data and runs the processes, launched by request from workstations.
Usually an organization will have one or many databases that act as the repository of information in an organization. The purpose of this data is to monetize the information or processes for profit.
The way to think about the database is not to view it as a dog-pile of stuff, but to think of knowledge units. Many knowledge units are contained in the database and linked through processes and/or relationships.
Knowledge units are first understood through the analysis of existing (or new) business practices. This often is done through “Use Case” scenarios. These knowledge units are transformed (part of the problem?) into “machine Instructions†” by a programmer.
Knowledge Unit storage in the database, is the combination of data and the applied rules to the data in conjunction with the relationships that data has with other data (a variety of rule).
Yet, what so often happens in production of a database design, is too much of the design is set up because, “I need to store this somewhere,” and a table of codes is created. The structure reflects the needs of the designer at design time, but does not take into account that what needs to be stored are things from the real world. These knowledge units are digital depictions of a real world objects or processes. The real world intrudes on the digital with Class-Responsibility-Collaboration hierarchies, but too often the immediate needs of a program result in structures being created on the fly that are nonsense.
So what I am saying is that when we are storing data into a database, we are storing the digital representation of a real thing, a classification or series of actions. To miscellaneously toss this willy-nilly into a hierarchical structure risks moving the whole structure into a game of “Silly-Buggers.”
†Usage for me is anything set of instructions a computer can use to render results, i.e. Table relationships, SQL statements for data extraction, script or compiled code, ect.
An organization, from where I sit in the back office “virtually” consists of a network skeleton that reaches across to nodes, and or satellites. A backbone of heavy iron churns that data and runs the processes, launched by request from workstations.
Usually an organization will have one or many databases that act as the repository of information in an organization. The purpose of this data is to monetize the information or processes for profit.
The way to think about the database is not to view it as a dog-pile of stuff, but to think of knowledge units. Many knowledge units are contained in the database and linked through processes and/or relationships.
Knowledge units are first understood through the analysis of existing (or new) business practices. This often is done through “Use Case” scenarios. These knowledge units are transformed (part of the problem?) into “machine Instructions†” by a programmer.
Knowledge Unit storage in the database, is the combination of data and the applied rules to the data in conjunction with the relationships that data has with other data (a variety of rule).
Yet, what so often happens in production of a database design, is too much of the design is set up because, “I need to store this somewhere,” and a table of codes is created. The structure reflects the needs of the designer at design time, but does not take into account that what needs to be stored are things from the real world. These knowledge units are digital depictions of a real world objects or processes. The real world intrudes on the digital with Class-Responsibility-Collaboration hierarchies, but too often the immediate needs of a program result in structures being created on the fly that are nonsense.
So what I am saying is that when we are storing data into a database, we are storing the digital representation of a real thing, a classification or series of actions. To miscellaneously toss this willy-nilly into a hierarchical structure risks moving the whole structure into a game of “Silly-Buggers.”
†Usage for me is anything set of instructions a computer can use to render results, i.e. Table relationships, SQL statements for data extraction, script or compiled code, ect.
Code as "Story-Telling" Introduction
Computer code is a language of expression. The core purposes of a programming language are to articulate rules and actions. This expression of the rules is done by people, who have the purpose of sending instruction sets to the computer in such a way as to get the computer to execute a series of tasks that achieve a desired and mostly likely testable result.
But the life cycle of programs goes beyond the extent of the first publication. Some computer code exists in a modified state for over 30 years. This life expectancy of code impacts how the written instructions should be targeted. It is not just enough for a program to be designed so that it does exactly what was desired, another aspect of a programs is its human maintainability over its full life-cycle.
When developing code, the business processes are laid out in documents, these documents amount to the intention of what a program should do. The industry is getting better at producing these documents and putting together scope. The problem with the scope is when a change request is applied to the original scope the request amounts to an errata of the scope. Over the life of development of an item the original intention of the software is greatly modified, and you get errata, of errata, of errata and so forth. The issue comes into play that not even the documentation of the business process adequately defines what the true in production business process actually is.
I sometimes view software through the conceit of the software being the real story of a business and that reading a businesses’ software is an exercise in exploring an enterprises’ set of practices. This story telling view of software, when I am reading someone else’s programs or writing the software myself helps me to get into a mind frame while I am developing to know that there will be (most likely) many other people who will work on a piece of software before it’s useful life expires.
This view, as it has achieved fullness has led me to be slightly discouraged with the state of enterprise software that I have worked with. On the web, the software instruction set is usually just dog-pile. In-line code directives (line by line processed very similar to an old BASIC program) piled into pages that are not even organized well into directories, without even the use of basic programming plumbing like methods. In all the organizations I have worked at these code repository’s code could be best summed up by naming them “Silly Buggers.”
A large part of the software writing community strives only to get the exact desired result from software. If the desired result is achieved then software is deemed to be successful. This can be summed up best by programmers who are asked about their software and they reply in its defense with “It Works,” which somehow absolves the software from any necessity of organization, well-craftedness, or maintainability.
If software is the one true repository of the business processes of an enterprise, I wonder how a business can afford to have its’ processes stored in a manner that other human beings are not able to readily understand, or replicate. Additionally if the usage of code goes beyond just getting the correct result, but includes that code has a status as both a rules repository and a dynamic living document, then perhaps the way that the code itself is written should be looked at.
But the life cycle of programs goes beyond the extent of the first publication. Some computer code exists in a modified state for over 30 years. This life expectancy of code impacts how the written instructions should be targeted. It is not just enough for a program to be designed so that it does exactly what was desired, another aspect of a programs is its human maintainability over its full life-cycle.
When developing code, the business processes are laid out in documents, these documents amount to the intention of what a program should do. The industry is getting better at producing these documents and putting together scope. The problem with the scope is when a change request is applied to the original scope the request amounts to an errata of the scope. Over the life of development of an item the original intention of the software is greatly modified, and you get errata, of errata, of errata and so forth. The issue comes into play that not even the documentation of the business process adequately defines what the true in production business process actually is.
I sometimes view software through the conceit of the software being the real story of a business and that reading a businesses’ software is an exercise in exploring an enterprises’ set of practices. This story telling view of software, when I am reading someone else’s programs or writing the software myself helps me to get into a mind frame while I am developing to know that there will be (most likely) many other people who will work on a piece of software before it’s useful life expires.
This view, as it has achieved fullness has led me to be slightly discouraged with the state of enterprise software that I have worked with. On the web, the software instruction set is usually just dog-pile. In-line code directives (line by line processed very similar to an old BASIC program) piled into pages that are not even organized well into directories, without even the use of basic programming plumbing like methods. In all the organizations I have worked at these code repository’s code could be best summed up by naming them “Silly Buggers.”
A large part of the software writing community strives only to get the exact desired result from software. If the desired result is achieved then software is deemed to be successful. This can be summed up best by programmers who are asked about their software and they reply in its defense with “It Works,” which somehow absolves the software from any necessity of organization, well-craftedness, or maintainability.
If software is the one true repository of the business processes of an enterprise, I wonder how a business can afford to have its’ processes stored in a manner that other human beings are not able to readily understand, or replicate. Additionally if the usage of code goes beyond just getting the correct result, but includes that code has a status as both a rules repository and a dynamic living document, then perhaps the way that the code itself is written should be looked at.
Wednesday, June 11, 2008
My History
My name is Gareth Dirlam, I was raised in San Diego County and was a teenager (relatively) next to the hot spot of technology. My father was a computer salesman, and I learned about business system programing and database systems at the age of twelve. I worked in financial departments starting in 1989 when I was 19, doing budgeting forecasts. Until now, I have worked mostly in the insurance and medical industries, besides maybe a year or two.
As a programmer (A name that in my thoughts becomes me best) I moved from script hacking to object oriented design in 1999 with the assistance and mentoring of some excellent engineers. I now write almost exclusively in C# and VB.net when I am on the server side.
As a engineer and system's architect who cares about tiers, I have done a lot of work with databases, and think that the database is a fine place to be. I work in database systems as a database designer, and believe strongly in them. I work primarily in SQL Server.
I am currently employed as an IT director in the real estate industry.
I am mostly a web programmer, preferring that platform for ease of deployment and also comfort with a tool set I have worked with for a long time. I know HTML/XML, CSS, XSLT and Javascript, and use them to improve the overall experience of the web applications I develop.
As a programmer (A name that in my thoughts becomes me best) I moved from script hacking to object oriented design in 1999 with the assistance and mentoring of some excellent engineers. I now write almost exclusively in C# and VB.net when I am on the server side.
As a engineer and system's architect who cares about tiers, I have done a lot of work with databases, and think that the database is a fine place to be. I work in database systems as a database designer, and believe strongly in them. I work primarily in SQL Server.
I am mostly a web programmer, preferring that platform for ease of deployment and also comfort with a tool set I have worked with for a long time. I know HTML/XML, CSS, XSLT and Javascript, and use them to improve the overall experience of the web applications I develop.
New Blog
I felt that I needed someplace to start putting some ideas to paper (so to speak) and so I have started a blog.
I will post here about my thoughts on programing, coordination of programing efforts, industry trends (past, present and future) and any aspects of the collaboration game that come to mind.
I will post here about my thoughts on programing, coordination of programing efforts, industry trends (past, present and future) and any aspects of the collaboration game that come to mind.
Subscribe to:
Posts (Atom)