making
- 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.
- Conventional: formal or heavy approaches, e.g. Rational Unified Process (RUP), CMM, etc.
- Non-Conventional: anything other than conventional.
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)
Formal Versus Agile? You've Got It All Wrong!
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.
Inevitably, this has resulted in religious arguments about which approach is better, and religious arguments are usually from an absolutist’s perspective.
A funny thing happened on the way to resolving this issue; some folks with poor practices attempt to partake of any legitimacy that the agile approach offers by reinterpreting their practices as agile. Their approach is to elevate any poor practice they have as really being agile. Equally confused, other folks have taken genuine successes from the agile approach and reinterpreted them as luck, hacking, or some other variant of happenstance. Their approach is to reduce any agile success to at best the results of wishful thinking.
What do these two different groups of people, the elevationists and the reductionists, have in common? Both of these groups have a perspective that only allows for two levels of software development: lets call them conventional and non-conventional.
In addition, this re-interpretation can be shown to be an instance of a concept identified by Ken Wilber and named the ¿pre/trans fallacy¿. While this think piece is about software development processes, the subject area that the pre/trans fallacy originally referred to is much more universal and significant, that of human consciousness (e.g. Ken Wilber Online: Introduction to Volume 1 of The Collected Works). The pre/trans fallacy is part of a larger model called the Integral Model [need citation].
A Better Tool?
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. Given that software engineering by necessity deals with well structured sets of information, (e.g. programming code, design models, architectural models) it’s a natural place to look for mature information managment tools. In addition, there’s a healthy industry around supporting software engineering. Yet despite this, the level of tools for managing informaiton specific to software engieneering is very immature. If you look more broadly, the commercial state-of-the-art for information management is even worse.
How is information management immature? Usign the following scenario, let’s look at some gaps.
Bob is responsible for capturing informal natural language information (e.g. the beginning of the a set of software requirments) and over time hea nd others will transform it into formal models that for use by different types of audiences (e.g. users, customers, software designers, user interface designers).
What are some of the actions Bob and others will want to do with this information? Consider the following:
Refine something, i.e. take a whole and identify it’s parts. This process is very At any point, he’d like to understand relationships b There’s an interesting process that (it’s theorized) we go through when categorizing something. As I model it, it includes the notion of distinctions: e.g. how many Essentially, the boundary of categorization is crossed when we begin to recognize distinctions. An oft used example is snow - while someone from the southern United States may have one word for (and implicitly no distinctions for) snow, an