@InProceedings{Teig07,
  title =        "{H}igh {C}ohesion and {L}ow {C}oupling: the {O}ffice {M}apping {F}actor",
  author=        "Teig,  Øyvind",
  editor=        "McEwan,  Alistair A. and Schneider,  Steve and Ifill,  Wilson and Welch, Peter H.",
  pages =        "313--322",
  booktitle=     "{C}ommunicating {P}rocess {A}rchitectures 2007",
  isbn=          "978-1-58603-767-3",
  year=          "2007",
  month=         "jul",
  abstract=      "This case observation describes how an embedded industrial
     software
architecture was \&\#8220;mapped\&\#8221;
     onto an office layout. It describes a particular type of
     program architecture that does this mapping rather well. The
     more a programmer
knows what to do, and so may withdraw to
     his office and do it, the higher the
cohesion or
     completeness. The less s/he has to know about what is going
     on in other offices, the lower the coupling or disturbance.
     The project, which made us aware of this, was an embedded
     system built on the well-known process
     data-flow
architecture. All interprocess communication that
     carried data was on synchronous, blocking channels. In this
     programming paradigm, it is possible for a process to refuse
     to \&\#8220;listen\&\#8221; on a channel while it is
     busy doing other things. We think that this in a way
     corresponds to closing the door to an office. When another
     process needs to communicate with such a process, it will
     simply be blocked (and descheduled). No queuing is done. The
     process, or the programmer, need not worry about holding up
     others. The net result seems to be good isolation of work
     and easier implementation. The isolation also enables faster
     pinpointing of where an error may be and, hence, in fixing
     the error in one place only. Even before the product was
     shipped, it was possible to keep the system with close to
     zero known errors. The paradigm described here has become a
     valuable tool in our toolbox. However, when this paradigm is
     used, one must also pay attention should complexity start to
     grow beyond expectations, as it may be a sign of too high
     cohesion or too little coupling."
}