Hands-on CXX. 30+ year entrepreneur and technologist, blend of consumer and enterprise experience; deep passion for engaging directly with customers and building businesses that solve for multiple bottom-lines (financial, human, social, natural), with a special focus on products, customers, and systemic change; a key role in four exits (Rhithm,
Food on the Table,
Five Runs,
Sapling Learning); work featured in Lean Startup by Eric Ries, Running Lean by Ash Maurya.
Manage Shared Information and Their Shared Concepts
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.
- That more often than not, we are unaware that these patterns exist and that we use them.
- And most importantly: that there is some (as yet unrealized) benefit to the intentional reuse of these patterns, and their relationships to contexts.
An Integrated Perspective on Software Development
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.
Why is this important? Primariliy because problems often creep in from the unrecognized (or recognized but less important) domain.
I’ve noticed that in the many organizations I’ve talked with, I’ve never really found any job titles that consistently appear to acknowledge this perspective. Occasionally, encounter some positions can described that way (e.g. architect, senior management, CTO), but there doesn’t appear to be a ready made & well recognized title.
Perhaps it’s a result of the perceived complexity of each domain, where the approach is to ‘divide and conquer’ the work into seperate roles. Personally I believe that this is an incomplete answer. The ‘divide and conquer’ approach works well for specialists that need to become strongly fluent in the extensive details in each domain. In this case, the differences are important - i.e. the patterns of action and subjects of action are unique within that domain. However, I believe that spanning all the domains there are patterns of action that are common, and that the unique aspects of the subjects of action are less important. Put another way - there are common patterns of doing things that can be usefully applied across multiple domains.
One concrete example of where this shows up is the role of architect. In software development, this is an overloaded term. For some, an architect (e.g. a J2EE Architect) is someone fluent with the unique aspects of J2EE. For others, an architect is soomeone fluent with the common very high-level design patterns and priniciples, which can be applied to different technologies as well as to businesses.
As a personal frustration, I often encounter the two being mixed up, e.g. in conversation expecting that they need an architect that spans multiple technologies and possibly business as well - and the conversation turns to how-to questions for a language specific library.
All the different levels are important, however I believe we need to revisit how we’ve ‘sliced the pie’. Specicically, I beleive we need more emphasis on the common aspects that span technologies as one ‘bundle’ of patterns; the common aspects that span technologies, business and people as another ‘bundle’, etc. The increased emphasis on these patterns willl create opportunities for greater breadth the roles (i.e. not tied to one technology)
Next Steps Towards a "Common Language"
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. In the case of a “common language,” I think the effort to practically capture and utilize is too high without the support of tools to assist. Just as spreadsheets such as Excel and tools such as Mathematica augment reasoning with various forms of math, a “common language” will need supporting tools as well.
To create an organization that intends to reason across disciplines, the language and tools must exist. Without them, it’s unlikely that such an organization could emerge.