Managing a densely or complicated set of links. The note in ZootSoftware talks about this in one way. I have a different take on the matter, based on the observation:
So I used the GoodAtLookingAround principle (some of you will recognize HeapSort in this use of the principle). By each name, I simply put the first letter of why I know that person: S for swimming, squash, switzerland, sweden, salt lake city, and Sean's friends; I for IBM, Italy, etc. Low cost for maintenance. Just a couple of letters by each name. Then, in the first page of the S section, I write little lists around the page, the last names of people I marked for Switzerland, another little list for squash, for swimming, for Sean's friends. When I put a new name in my book, I make two entries, their name and address, and the list they initially belong to. Still relatively low maintenance.
This was super when I wanted a surprise party for Deanna - no way I could remember all her friends from art school. But under D was a list of her friends, so I looked them all up. I found people to play tennis with I had forgotten played tennis. etc.
Example 2: Traceability in software products
We tried keeping interaction diagrams up to date as the design changed. Ugh :-( !! One person was spending easily a third of his time on this silly exercise. So we applied GoodAtLookingAround and collapsed sets of use cases together into UseCaseCategories? and collected classes together into ClassCategories?, then made a simple matrix of UCC vs. CC and put a tick mark if any use case in the use case category used anything of any class in the class category. Actually very stable over a lot of design changes.
Coarse grained? you bet. But guess what, people are GoodAtLookingAround, and that is what maintenance people do for a living, looking at other people's code. They are happy to have a starting place, and a little common sense in looking plus the same in coding makes for a good guess where to start looking.
--- AlistairCockburn