
Why did we do this? - fogus
http://www.johndcook.com/blog/2011/11/25/institutional-memory/
======
eftpotrm
Which brings to mind....

 _Five monkeys are caged together and there are some bananas hanging from the
top of the cage. Some scientists attach an automated device for sensing if the
bananas are moved; once a monkey tries to get any, an electric shock travels
through the cage so that all monkeys get shocked. In the beginning, a single
monkey climbs up to the bananas, touches them and every monkey gets shocked.
So he doesn’t try anymore, but the other four monkeys try the same thing and
the result comes to be the same. Therefore, the monkeys learn something in
common: that is, do not get the bananas! You’ll get a painful electric shock!
The scientists then replace one of the original monkeys with a new one. This
new monkey sees the bananas and wants to get them right away, but the other
four monkeys beat it when they see its actions. Since these original four
monkeys think the new monkey will make them get shocked, they stop the new
monkey from getting the bananas. This monkey tries a few times and the others
beat it every time without it ever getting the bananas. Of course, all five
monkeys don’t get shocked. The scientists then replace another of the original
monkeys with a new one. This second new monkey sees the bananas and you bet it
wants to get them immediately. But, sadly, the others beat it and the first
new monkey beats the newest one even harder then the others (for the newest
one is the rookie and has the lowest social status). Just like before, the
newest monkey tries several times to get the bananas and is stopped by the
others when they attack him. The scientists continue to replace all the
original monkeys until no monkeys who actually felt the electric shock remain.
Now none of the five new monkeys dare to touch the bananas yet none of them
know why. They only know whomever wants to get the bananas will be beaten._

An interesting thought; has anyone else tried to implement it fully rather
than piecemeal? Certainly it sounds a good idea and one to try on my next
project.

~~~
cperciva
If you come into FreeBSD and commit non-style(9)-compliant changes, people
will yell at you. Most of the time people don't know why style(9) says what it
says, but still zealously insist on it being followed.

There's one, maybe two FreeBSD developers who know the reasons behind most of
style(9), and that's because they have been working on FreeBSD for 30 years --
since long before it was called FreeBSD. The rest of us have simply learned to
follow it.

~~~
Confusion
I'm not sure whether you are defending or criticizing this state of affairs. I
wouldn't understand the former and expect action in case of the latter. Why
does this state of affairs persist?

~~~
cperciva
This state persists because there _are_ good reasons for everything in
style(9), even if most people don't know what most of them are.

------
jdietrich
You want to see the most perfect example of how to document process? Get hold
of a copy the McDonalds franchise operations manual. It is a genuinely
beautiful artefact. There is literally no aspect of running a burger
restaurant that isn't in the ops manual; How the parking lot should be
managed, how employees should wash their hands, how a hand-cart should be
unloaded. Almost every sentence speaks of a lesson learned the hard way, ten
thousand little edits because of a lawsuit or a process bottleneck or a QA
problem. It's an incredible example of what happens when you take something
simple and spend several decades optimising it.

~~~
nodata
Is this available somewhere as a pdf?

~~~
squirrel
Not quite the same, but this fifty-page document is what they use every six
months to check up on every franchise.

Fun fact: if you fail this, your franchise fee to McDonald's Inc goes up. If
you keep failing, your fee keeps rising and eventually gets high enough to
make your business fail. At that point home office takes over and runs it by
the book or sells it on to someone who will.

[http://www.google.com/url?sa=t&rct=j&q=mcdonalds%20f...](http://www.google.com/url?sa=t&rct=j&q=mcdonalds%20full%20operations%20review&source=web&cd=4&ved=0CDAQFjAD&url=http%3A%2F%2Fdcclee.info%2Fweb_documents%2Fbw_ver.full_operations_review.section4.pdf&ei=hxbQTsKZKund4QSRqtzhDg&usg=AFQjCNE5qfXHdMcsGIEt1cas1RR-
MLzCoA&cad=rja)

~~~
meric
Nice to know. What if you pass the review with flying colours after you failed
last year? Will you be able to reverse the franchise fee rise?

Fun fact: When a McDonald's is closing each day the staff has to pack up all
the sauces, meats, bread, etc. When I worked there, to get home early, in the
last hour I pour the tomato sauce and some of the mustard from the containers
(which needs to be emptied and washed), mix them into a cup and put them on
burgers with a plastic spoon.

By doing this the containers could be washed earlier.

~~~
squirrel
I expect they reverse the rise if you are doing well. After all, they don't
_want_ to take over your McDonald's - they want you to run it right. But I
don't know this for certain.

------
jemka
Business answer: With everything, including this, there needs to be a balance.
The ROI on documenting every single inch of progress as accurately possible is
extremely low in most cases. Additionally every case (industry, business,
project) is different and one size doesn't fit all.

Personal answer: Because we are lazy.

~~~
johndcook
I agree that there has to be a balance to how much an organization documents.
But I'm more concerned with how little organizations _read_ than how little
they _write_. If they wrote a little less, they might read more.

Maybe instead of voluminous meeting minutes, organizations should have a
little notebook labeled "Why we decided what we did."

~~~
gvb
A couple of observations:

1) If the record is not electronic, there is no way to share it and typically
no way to discover it. Manual search of paper documentation sucks.

Before Al Gore invented the interwebs, I kept lots of notes in notebooks. I
almost never shared the notes and almost never referred to them after the
development phase of the project ended.

I now use a wiki and "issues" in a tracking system (e.g. Redmine) to keep my
"engineering notebooks". This has proven invaluable time and again.

2) The importance of decisions is mostly discovered in retrospect. :-( I find
many holes in my notes when I do something a second time, even when I _think_
I'm keeping good notes the first time. The good news is that my notes are
pretty good after the second pass.

3) I don't know if it is laziness, inconvenience, or otherwise, but my
experience is similar to the OP in that I tend to take fewer notes that I
should and I have a hard time getting my coworkers to take half as many notes
as I take. :-( Again, I find an electronic notebook open in a web browser on
the desktop you are doing the work on is much more effective than paper and
pen.

Cut'n'paste >> pen >> sword.

~~~
re_todd
I started using Tomboy notes (and recently Gnote) to write short notes. They
have a good, quick search built in to lookup old notes. They are easy to
backup as well (copy .tomboy/ or .gnote/ subdirectory from home diretory).

------
ableal
Snack for thought: <http://en.wikipedia.org/wiki/Bureau_of_Sabotage>

------
allertonm
Capturing this kind of knowledge - especially from ad-hoc decision making -
for future reference is an explicit goal of SAP's Streamwork product. It is of
course open to question whether that goal is achieved, but certainly SAP (as
an organization very focused on the way businesses are run) are very aware of
this problem and actively trying to provide a solution.

(Disclaimer: I was the lead architect for the initial release of Streamwork,
but have since left SAP.)

------
6ren
It's difficult to document all the factors that go into a decision because
some are common context (and tedious to document _all_ such assumptions). Over
time, context changes.

In addition, decisions that turned out to not work are abandoned; decisions
that work are kept... showing that the reasons for making the decision may not
be the reason it works.

The article assumes we know what we're doing, top-down rather than agile/lean.

------
jfno67
The problem often becomes that even if it is written, the documentation is
rarely or never read. People then wonder if they should write more or less and
why it is this way. I think one of the problem is we think we are finished
after we write it. I would like to see a place where someone went over the
documentation and rewrite it to extract the cultural references instead of the
specifics of one situation. The documentation would be more about how to react
than what to do exactly.

------
shasta
How does this guy's low quality blog repeatedly make it to the front page?

~~~
zafka
Seriously, how do you determine that his blog is low quality?

Disregarding your insult, your question is an interesting one. If someone
could bottle the answer, they would have all the freedom they needed.

~~~
shasta
I'm not interested in insulting the author, who's probably a nice guy. But
I've been conditioned to expect very little content when I click on a link and
his picture pops up, so I'm just wondering what the deal is.

