patterns that connect
- 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.
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:
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.
Specialists and generalists
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. Like most things, my conception and understanding of the “really big problems” has evolved as I’ve changed. Over time, they’ve included the academic (how to access enough knowledge to be a true generalist, not a specialist), the serious (how to resolve conflict between radically different cultures) to the silly (how can I fly away from home with my own personal space plane).
No doubt influenced by some optimistic science fiction, the way I saw it as a child is, at it’s essence, the way I see it today: that a group of people from different, diverse backgrounds and interests will solve problems no one else can and will do things others say can¿t be done. Sometimes intentionally (and sometimes not) I continue to return time and again to act on that conviction.
As part of that conviction it seemed obvious to me that there must be a discipline which represents the common foundation underlying the many other domains, i.e. a “common language.” However, I¿ve never found a discipline which quite seemed right, i.e. no university program which teaches quite what I’m thinking of. While some disciplines had a piece which I was interested in, certainly some aspects of the humanities & liberal arts speak to this, other pieces were missing and I could never imagine specializing in that discipline - the results seemed too narrow.
Independent of situation, the interest and conviction has remained. Today it manifests in my education and profession, I have ample experience in the specifics, yet a passion for the general that spans the boundaries of many disciplines.