what's next?

Archive for the ‘Product Development’ Category

An Integrated Perspective on Software Development

In Product Development on April 19, 2005 at 9:56 am

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. However, what’s confusing for me is how rarely this is recognized on all the different projects I’ve been involved. I don’t think this is just a function of how I choose a project – as I hear this from others as well. Typically, the recognition of this varies depending on who I’m talking with – e.g. developers recognize technology and business, but rarely the people; product owners recognize the business and technology, but rarely the people.

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)

Advertisements

Formal Versus Agile? You’ve Got It All Wrong!

In Product Development on January 13, 2003 at 9:05 am

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.

  • Conventional: formal or heavy approaches, e.g. Rational Unified Process (RUP), CMM, etc.
  • Non-Conventional: anything other than conventional.

My argument is that one significant limitation to resolving this issue is the two-level model, and that by reinterpreting the evidence using a three- (or more) level model, a path towards resolution becomes visible.

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].

Reconciling Formal, Agile & No Processes

In Product Development on May 22, 2002 at 11:43 pm

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

What’s Next In Modeling Tools?

In Product Development on May 20, 2002 at 11:41 pm

Based on the current state of the art with modeling tools today, there are a lot of potential improvements. What follows are a set of wishes or possibilities, completely based on my own biases and experience. All of these possibilities have are based on common themes of matching the way people think about and do their work, enabling more degrees of freedom in modeling languages and proceses both of which generally support the goal of making these tools more relevant and usable in many domains.

Based on the current state of the art with modeling tools today, there are a lot of potential improvements. What follows are a set of wishes or possibilities, completely based on my own biases and experience. All of these possibilities have are based on common themes of matching the way people think about and do their work, enabling more degrees of freedom in modeling languages and proceses both of which generally support the goal of making these tools more relevant and usable in many domains.

What are The Current Weaknesses?

In the field of software, system and business process modeling tools, what are some of the weaknesses and what are some of the opportunities?

Informal Content
Questions such as why can’t I choose to use informal content when I need it? and why isn’t it possible to specify what degree of formality I need the tool to enforce at any point in time or with any particular information? In addition, because there is no notion of informal content, there is no notion of transformation from informal to formal information. This refinement process is frequently a time of rich discovery.
Levels of Abstraction
This is typified by the question why can’t I mark information to be at a level of abstraction and relate across levels of abstraction? and we reason using levels of abstraction, why isn’t this a primitive in our tools?
In the development of models, the information at hand may be from multiple different levels of abstraction. Current tools have an implicit notion of level of abstraction by seperating out various aspects of the model into seperate tools (e.g. requirements in one tool and a process description in a second) or alternate representations (e.g. different symbols). As a result, there is no integrated management of views through varying levels of abstraction.
Progressive Refinement
This is typified by questions such as
we don’t know the rules of our modeling system yet, why can’t we start and refine those rules over time? and
I want to develop a model of some domain, prior to understanding the rules. Over time, I want to refine the rules which will cause the content in the model to evolve as well. and
why can’t I use the tool to manage the transformation from informal to formal?
Multiple Representations of the Same Thing
This is typified by questions like sometimes we work in picture, sometimes in text, sometimes in both – why can’t one tool integrate the different representations of the same things?
Views on the content that include alternate representations, such as text.

Potentials

Based on the current state of the art with modeling tools today, there are a lot of potential improvements. What follows are a set of wishes or possibilities, completely based on my own biases and experience. All of these possibilities have are based on common themes of matching the way people think about and do their work, enabling more degrees of freedom in modeling languages and proceses both of which generally support the goal of making these tools more relevant and usable in many domains.

  • Supporting variable amounts of precision (a.k.a. formality) of the content.
  • Supporting abstraction and refinement as both a process and relationship.
  • Representing content in multiple modalities.
  • Configure for alternate syntax, semantics and processes.
  • Support progressive refinement, both of content and meta-model

To understand this weakness, it’s useful to understand the context – the creative process. During different phases of the createive process, there are different types of information processed in different ways. One key distinction is the degree of formality of the information. Current modeling tools are optimized for the formal expression of information, which makes them irrelevant for much of the creative process. As a result, users may compensate by abandoning the tools.

Incorporate Degrees of Precision or Formality of Content

Most tools do not provide for less-formal or precise content, the expectation is that the content will conform to the syntax and semantics of the ? immediately when entered. The expectation that the content will spring to life completely well-defined is unreasonable and does not match how people actually work. Realistically, content with varying degrees of precision/formality are used simeltaneously. It is only once they have been evaluated and refined that they may be conformant with the syntax and semantics. The tool must support varying degrees of precision in content, as well as their transformation as they become refined or altered.
Current tools are optimized to handle formal/conformant information and linear processes and therefore are relevant only to a subset of the creative process.

Certainly there are ways to compsenate for this, e.g.

  • Abandon modeling tools in exchange for more flexible mediums, e.g. whiteboards, paper, etc., for all phases.
  • Abandon modeling tools for the phases when informality is needed.
  • Compensate for the tool by transforming information immediately to be formal. To accomplish this, the user will likely have to modify their cognitive processes and focus, i.e. from brainstorming to critiquing.

At best, information is lost about the transformation from informal to formal, at worst information from major phases of creativity is lost.

There is no support for informal information, i.e. correct, but not conforming to a formal specification.
It is reasonable to expect that in a creative process that involves modeling, the tools would be capbable of accepting information in varying degrees of formality, i.e. to accomodate the needs of different phases of the creative process.

For the sake of discussion, consider the creative process to be composed of multiple phases (e.g. the Disney Creativity Strategy): dreamer, critic and realist. One distinction between these different phases is the degree of formality of the information during that phase:

dreamer
During this phase, a.k.a. brainstorming, the degree of formality information may be low, i.e. non-conformant to some pre-defined specification. The information may be gathered to trigger additional ideas as well as for later critiques.
critic
During this phase, the degree of formality may be raised, i.e. the critical judgement is applied to the information, resulting in both a reduction of the total pieces of information and in a refinement of the remaining information to become more, but not completely, conformant to some specification.
realist
In yet another phase, the information may be refined into a more formal expression, i.e. conformant to some specification, and used to perform analysis of cost, complexity, etc.

In addition, the phases are not linear, they (re)cycle (see Wicked Problem solving).

Explicit Support for Abstraction & Refinement

For instance, in requirments elicitation a usability requirment may be at a very abstract level and a process description may be at a low level of abstraction. Yet, both of these pieces of information are aspects of the same model, each completing a seperate piece of the whole picture – and related to each other in some way. Without having tool , e.g. conformance and therefore no ability to navigate varying levels of abstraction.

Incorporate Multiple Modalities for the Content

Most modeling tools have a notion of providing multiple views of the same content. Unfortunately, the different views typically are composed of the same representations of the underlying content. There is the need to provide multiple representations, or modalities, of the same content. For instance when specifying classes and their relationships in a software modeling tool, the common representation modality is visual. There are many instances when it’s useful to present the same information textually, i.e. descriptions of the associations and the classes.
e.g. text & visual for modeling something

Configurable

Configurable wrt: syntax, semantics, representations per: modality (e.g. icon types, text strings, etc.); standard UML-type s.w. design is just a customization of a more general tool; allow for specification of unique model types, e.g. Ron Bennett’s own business use-case -> architectural scenario -> message interface to be represented

Progressive Customization & Specification of Language, Processes, etc.

Regardless of how unified and comprehensive a single modeling language and process intends to be, there will always be customization as well as creation of new languages and processes. As a result, modeling tools need to be configurable over the life of their use. The expectation that a language or process will spring to life completely well-defined is unreasonable. Realistically, these will be identified, used and refined over their lifetime. The tool must support varying degrees of precision in their definition, as well as their transformation as they become refined or altered.

More General Than Software & BPR

How can Model Driven Architecture Be Successful?

In Product Development on April 19, 2002 at 11:59 pm

How can model driven architecture (MDA) be successful (or any approach where higher levels of abstraction are necessary) when software engineers are not yet settled in real OOD?