For known and mature domains, serialize the steps


Development stages should be independent to reduce coupling and promote autonomy of teams and developers.  For known and mature domains, serialize the steps.


Decouple Stages


There are strong contra-indications to this pattern, see below.  However, various aspects of the idea are good in general, and some aspects are very good in specific and limited circumstances.


Handoffs between steps should take place via well-defined interfaces. This makes it possible to automate one or more of the steps, or to create a pattern that lets inexpert staff carry out the step.  You can afford to do this in high-context, mature areas because the patterns of work are repeatable and rarely bring surprises.  That means that each stage can be carried out independently. That means less communication between stages, which may mean better efficiency.  One can further raise the efficiency by building on specializations and domain knowledge pertinent to individual stages.  Example domains include database administration (with steps such as database modeling, normalization, and query optimization), packaging, delivery and installation, and many administrative functions like bug tracking or the high-level business processes supporting field error report resolution.


There is considerable advantage to be gained by having a ‘logical’ handover between steps in the process because this clarifies the mind of the developer as to what is involved in each step of the process.  However, this advantage can be gained without any actual handover occurring, without incurring the expense of communication to support the handover.  It may be the case that the increased cost of formalizing the handover can be recouped by automating one or more steps in the development process.  For almost all development efforts, using third generation programming languages instead of machine code does this.  For a few development efforts, using Translation Engines on formal models of the specifications does this.  There are intermediate approaches.  A good rule of thumb is to formalize fully only at one point in the development process.


The mindless partitioning of development into serial processes, such as analysis followed by design followed by coding, where all these processes are manual, and particularly when there is a rigid, detailed written document containing the hand-over information, makes for one of the highest cost of communications one could achieve.  There are numerous other bad aspects, in particular the delayed or missing feedback into the prior stage of processing.  IterativeDevelopment to some degree ameliorates this latter aspect, but is not a perfect solution.  Modern approaches have ameliorated the risk of not getting it right first time; this risk was traditionally the main argument for decoupling stages into serial processes.  The argument that less need for communication (i.e. no dialogue) between the stages means better efficiency is fallacious where this communication must occur by expensive means.  A more interactive approach to handover would allow cheaper means of communication.  Eliminating the handover altogether would eliminate the need for any communication.