I had an interesting discussion with Kelly Looney today regarding positioning. Based on his experience, (as I interpret it )positioning starts with identifying and sharing a world-view and then describing what you do (of benefit), in the context of that world-view. For me, it seems an interesting pattern to use to compose a simple pitch of an idea (e.g. for a startup). So, here's some attempts to try that pattern out:
A great audio program on experiential computing (IT Conversations: Ramesh Jain - Experimental Computing) and Ramesh’s related blog (Ramesh Jain’s Blog » Blog Archive » Events and paradigms) gives me some inspiration to on two important points: Patterns in Oggidigaw - using the notion of events with their attributes of who, what, where (spatial), when (temporal) and how (causal) - as a type of data model for representing patterns. What’s beyond objects: the notion of object-orientation has some strong limitations, one of which is the representation of time.
Some of the assumptions that drive shared information and the shared concepts that underly them: There exists cognitive patterns (also called processes, structures, templates, metaphorical structures, relationships, frames, cognitive models, etc.) that are repeatedly used across across a variety of contexts, i.e. disciplines, domains or fields. That there is no single body of knowledge that explicitly captures and specifies these patterns and their related contexts, and by implication there is no discipline which owns them.
Some ramblings on software development A useful perspective on software devleopment is as an ‘integrated discipline’, i.e. a perspective that recognizes that software development is actually composed of three domains: Business - this is the domain of the problem Technology People - all the people involved, e.g. development team, customers, users, support staff, marketing, product management, etc. Nothing here is new, e.g. Weinberg, Catalysis, Scrum, etc. all include some notion of these domains in their models.
With experience, I have come to realize that is not sufficient to gather a diverse group of people to solve problems, no more so than a pile of sticks is sufficient for a fire. In part, I think there is a “common language” missing that represents the shared patterns, processes, structures, templates, metaphorical structures, relationships, etc. across a variety of disciplines and domains. As with any language, agents are required to bring the language alive.
I think it’s pretty easy to convince ourselves that in many contexts, especially work, we are becoming more specialized, moving away from being generalists. As an evolutionary process, it allows us to better fill more niches. However, with this specialization, the complexity of communicating across contexts is increased. With a decrease in communication, the opportunities for leverage are similarly decreased. For as long as I remember, I’ve been convinced that the only way to solve the “really big problems” is with multi-disciplinary teams.
As I interpret it, the agile versus formal debate is generally treated as an either or question. For instance, in any given software development situation there may be an assessment that it would have worked better if only an agile approach was used or for a project like this, you must use a formal approach. Only rarely does there seem to be an advocate that suggests integrating aspects of both approaches.
As with many computerized things, I’ve been frustrated with the commercial state of the art for software to manage information, especially personal information for quite some time. Let me provide some context to better explain. While I’m often challenged to explain what I do, I can say it involves doing all sorts of actions on information (e.g. creating, manipluating, reasoning with, etc.). Much of my effort is in support of goals in the domains of software engineering or psychology.
How to reconcile formal, agile & no processes in a software development environment? Previously in conflict, considered by some as irreconcilible Integrated using a model that accounts for development stages/levels. Fundamental pattern: learn the form to become formless