Architecture of the Problem 2

Architecture of the Problem is a term that was concocted to describe the nature of a problem and its formulation which enabled an effective architecture

The outline that was in this post has been subsumed by: Architecture of the Problem which discussess this topic.

Why One Process Can’t Work Everywhere

Software development processes are a lot more like business suits than they are like stretch socks.  Implementing a process that worked well in some other organization or industry is like wearing somebody else’s clothes.   Goldilocks nailed it on the head.  “These clothes are too big!  These clothes are too small…”

A dozen or more contextual factors determine how well a process will fit.  Some are cultural.  Some deal with project size and scope.  Others deal with team size or geographic dispersion.  Some deal with prior experience in the problem domain, and how static or dynamic the problem is.  Others deal with prior experience with solution technologies, and how rapidly they are changing,

If you are looking for a process to copy, a) find one that is working well and b) find one whose contextual factors are very much like yours.  Otherwise, examine your context closely, and use first principles to tailor a process to what you need.

The blog article at http://wp.me/PiW0e-5j discusses the contextual factors and presents two examples of how they apply.