Re: SERIOUS: Formal vs. informal organizations

[Ben Kovitz <apteryx -at- CHISP -dot- NET>]

Andrew Plato wrote:

[A very stimulating message about formality in organizations,
including this interesting point about "proactivity":]

> Nevertheless, It may be argued that when an organization hits a
> certain size or market saturation point, bureaucracy is
> inevitable.  I disagree.  Consider the Internet.  It is a massive
> bureaucracy, with thousands of layers of communication, routers,
> and ISPs.  Yet, the control and command of the Internet is
> largely passive.  As long as the communications work, nobody
> sticks their nose in your business.  Has your ISP ever called you
> up to say ìstop looking at those inappropriate web sites?î The
> only time the command of the Internet springs into action is when
> there is already a problem, such as bad connections or fraud from
> sleazy spammers.
> . . .
> Yet many organization and people preach the gospel of proactivity
> as a defense of bureaucracy and excessive planning: ìwe have to
> be proactive in our approach to ensure we are properly using our
> resources.î The tyranny of ìproactivityî has turned people into
> analysis-paralyzed drones.  In the race to account for
> everything, they accomplish nothing.

There's an interesting fellow named Pete McBreen who sometimes
posts on comp.software-eng.  A particularly insightful principle
that I picked up from him is:

   Don't write "just in case" documentation.

I was once on a project where one fellow was terrified that we
weren't documenting enough about the procedures that we went
through to design the product.  His reason: we're not an ISO-9000
company now, but we might be someday, and if so, we might be
audited, and if that happens, we might get in trouble.

This fellow was famous for writing requirements documents of 100
pages or more, which no one ever read and that no one but he
could understand, but which followed numerous "rules" to the
letter.  I'd suggest removing useless sections from a document,
and he'd express great fear of disobeying the official company
template.  "There might be a reason they need that section filled
in."  Everything he did was an attempt to prevent some sort of
imaginary catastrophe or to satisfy some imaginary "they".
Anything that he could imagine going wrong, like someone reading
individual words of the document out of the context of the rest
of the sentence, he had to try to prevent--always by adding more,
more, more to the document.

That is the danger of "just in case" documentation: continually
trying to head off imaginary or trivial disasters led to enormous
waste, delays, and generally poor products in the few cases when
the project wasn't canceled because we didn't strike when the
iron was hot.

The "just in case" attitude is an exact reversal of economic
sense: addressing the merely imaginary or non-existent before the
real, known, and actual.


Generalizing a bit from software design documentation, I would
say that McBreen's Principle applies to bureaucracy in this way:
invent rules and procedures only to solve known problems, not to
prevent any imaginable thing from going wrong.  If you know that
a certain disaster is likely to happen if you don't take a
certain preventive measure, then take that preventive measure.
But if not, then wait until a problem starts, fix it, and *then*
add this to your list of preventive measures if and only if the
preventive measures are cheaper than the risk of waiting for the
problem to happen and then fixing it.  To put it another way,
vaccinate only against known diseases.

> I am curious about your thoughts on this "informal vs formal"
> concept.  Mostly, can anyone think up solid, tangible benefits to
> a super-formal environment?

I think of formality--that is, strict rules that an organization
imposes upon its members--as a type of collective knowledge
derived from a long, slow, collective learning process about a
specific type of recurring problem.  The learning process
consists of two main activities: a "positive" activity,
consisting of refining ways to achieve a known type of result;
and a "negative" activity, consisting of investigating disasters
when they occur and thinking up ways to prevent them, as
described above.

As I see it, formality is a mechanism for helping newcomers make
use of the most refined ways to achieve a known result without
having to go through the long process of refinement all over
again, and to avoid previously identified types of disasters
without having to suffer the disasters all over again.

A couple key concepts there are "known result" and "recurring
problem".  In more detail, formality can only address what is
common to many problems, not what is unique in a given problem.
Formality becomes a disaster when people use it to address the
unique aspects of problems or at least different categories of
problems than gave feedback to that collective learning process.

Manufacturing is a field that, for the most part, solves
recognizable, recurring problems: make a million plastic things
having a certain category of shape; allow no more than N% of the
items from the production line to vary more than M% from the
spec; etc.

While we have a number of these recognizable problem types in
software and technical writing, both types of product tend to be
very heavily weighted toward unique elements.  I'll stay focused
on technical writing.

The most important, fundamental element of any technical document
is its *content*.  Deciding what the document's content should be
is the vast majority of the work.  And content varies enormously
from project to project.  For example, *one* user's manual that
you produce in your entire life might need to explain the basics
of trigonometry, in order to enable the average user to make use
of the software.  (I'm thinking in particular of one of the
manuals that comes with Visio, which *should* explain this but
doesn't.)  *One* requirements document that a system analyst ever
writes might need to describe the instruction set of an
imaginary CPU.  *One* interface design document that you make in
your entire career might need a special section about the sizes
of different people's hands.

There are a lot of common elements (I call them "commensurable
elements") that apply across many technical documents, but I've
never written a document where the unique ("incommensurable")
elements were not of critical importance.  Leave out that
once-in-a-lifetime information and the document may well be
useless.  I once had to draw a picture of a laser range-finder
to illustrate the concept of 'azimuth', and to include an
instruction saying not to take measurements while standing in the
street.  If the document didn't have that information, its users
would have been utterly baffled by the buttons on the front
panel, and they may have held up traffic or been hit by a car.
But I doubt that I will ever write another manual with that kind
of information.  It would be formality misapplied to invent a
rule that all manuals from now on shall include a diagram showing
the product in order to teach a concept of geography.

This is why I see ISO 9000 and its ilk as extreme pathologies
except for companies that do essentially the same thing over and
over again.  Many, many times now I have seen people look to
*document templates* as the way to ensure quality in software
requirements--even though software requirements is the most
amorphous part of the whole job, the part where the unique
aspects of the problem tend to dominate.  Looking to document
templates as the solution to the unpredictableness the earliest
phases of software design is perhaps the ultimate
misunderstanding of the value of formality.

I don't think this addresses all of the tangible benefits and
dangers of super-formal organizations, but I think it covers
some.  I hope it's at least a good start.  (And the rest of your
message is great food for thought about the rest!)

 From ??? -at- ??? Sun Jan 00 00:00:00 0000