Life Isa Big Messy Graph

In the real world:

The relationships between many things are a big messy graph (network), not a tree or any other "hierarchical" structure.
- Yes but some things that look messy (chaotic?) do have order. See SmallWorld theory; many things, from relations between proteins in cells to synchronization of crickets chirping in a field to patterns of electron firing to the connectivity of the internet, have this structure.
- But often such "natural order" suffers from the "90-10 rule" (see below). The patterns are imperfect such that dealing with the exceptions to the pattern is still a messy graph.
The granularity of change can be small. Thus any "chunk" (module, routine, method, etc.) is going to prove too large a granularity from time to time.
Anything can potentially link to any other "thing", and links between anything may need to removed or deactivated to deal with changes.
Any and all "modeling" techniques are a UsefulLie at best. Some links (current or future) are ignored in order to simplify the system by creating a higher order abstraction.
Printed out, the full graph would probably be too sprawling and messy to use as is. Thus, in practice one usually needs to filter the result somehow to study one or fewer aspects at a time.
We have to use UsefulLies in order to manage things as humans, not because a UsefulLie is THE "right" answer. AllAbstractionsLie. For example, trees are usually easier to grok than graphs. But trees may not provide enough power to fully represent what we want at least not without making the tree messier than a graph in order to keep it a tree.
Most of software engineering revolves around which UsefulLie is the most useful, not which is perfect, because none are.
We have to partition things into rather hard-walled "chunks" to be able to deal with and manage things as humans beings even if our partitioning factor is not the only division candidate factor, a somewhat arbitrary factor, or just another UsefulLie. The chunks should not be viewed as the "proper" model for all division needs, but rather a necessary evil to bring about DivideAndConquer one way or another so that our feeble mortal minds can track and comprehend something small enough to focus on and work with.
There is no "magic structure" or "magic theory" that fully removes the messiness inherent in the world. Type theory, set theory, relational theory etc. are never going to be the ideal abstraction that simplifies everything into neat little formulas, patterns, templates, packets, or patterns. In the end, AddingEpicycles will be needed to some extent to handle those situations which don't fit the simplified abstraction.
At best we can hope for an 90-10 percent mix fit or 80-20 fit where our abstraction fits most of the target. But, most code will probably be devoted to the 10% to 20% exceptions anyhow. (See EightyTwentyRule)
A LegoToy-block approach to software will always remain elusive because you can't blockatize a graph. The human brain has "sections" that have specializations, but its real power comes from all the links between and among sections. "Sections" are simply groups where the interfaces between them have merely lots of connections between them instead of gazillions.
Ways to measure how useful a UsefulLie is include:
- Measuring the impact of change on it over time
- Ease of understanding
- Assists OnceAndOnlyOnce
- Ease of application
- Predictive value
- Personal comfort
- Simplicity (see OccamsRazor)
- Adherence to dogmatic principles defined by some designated authority

Some suggest that disciplines that involve math, geometry, and physics are immune from the above rules because they are precisely known or based on rigid base theory. Whether this is true or not is open to debate (see GoedelsIncompletenessTheorem). Nevertheless, the problems faced by those of us dealing with "fuzzy" domains (biz, law, gov't) versus those dealing with precisely-defined domains like math may be different.

Exercise: draw 2 "folders" - one for personal, one for work (or school or both making 3 packages). Make them fairly large - 1/3 to 1/2 the page. Draw a stick person in the middle of each one. Now draw ellipses for common UseCases you partake in with lines between them and you. Now draw a sequence diagram for each ellipse (other side of the paper). Voila you have the first draft of UML depicting how your LifeIsaBigMessyGraph. Next step: the ClassDiagram...

UseCase: I call a friend of mine on my cellphone who also happens to be a cooworker. 1/3 the conversation is about work, 1/3 about personal stuff, and another 1/3 that is hard to classify, such as rumors about the boss's marriage to another manager. Some would say that such is work related because it affects office politics, which affects one's job.

And when the CFO is going through your expenses and asks what the 10 minute call to Spain was about, remember to say just that.

Perhaps it is a choice between the right answer or the short answer. JustMakeItRight

[Also the right assumptions and simplifications. In Italy, they built impressive Duomos and Campaniles that have stood for hundreds of years, without advanced mathematics and engineering (though the one in Venice collapsed and the one in Pisa is leaning a bit. The one in Florence seems to have done ok, touch wood). Even to pack your backpack or car trunk is really a complex problem but we do it in minutes - see http://www.edm2.com/0601/backpack.html. To tidy your house - put away books, dishes, take out garbage, hang up clothes, file away papers. To do it in the fastest manner from where you are standing isn't that a variation of the TravellingSalespersonProblem??]

This is incorrect, there was in fact advanced math and engineering behind those Duomos and Campaniles.

Relative to the time, but how would you compare it to the analysis that would go into developing similar structures today? They certainly did not have DifferentialEquations and used much simpler models than we do today, yet created enduring towers. By the way the Venice campanile collapsed (1902) because of errors in turn of the (19th-20th) century repairs; it likely would have continued to stand otherwise. It was rebuilt (re-opened 1912) in case you are wondering what that is towering in St Mark's Square.

[Interesting; yes, I did wonder. But as to the rest, that's all irrelevant. You could as easily say that structures built in 1920 didn't use advanced math and engineering, because they are not as advanced as today. Where would you ever draw the line? The point is that most of the surviving Duomos were built using relatively advanced math and engineering. They were only made possible by then-new developments.]

(Another way to look at successful historical structures (of which buildings are the most relevant example here) is that the ones that survive are, by definition, the better engineered. Those that didn't stay up aren't here any more; a form of natural selection, if you like that sort of analogy. Thus the techniques that built them were advanced even though the builders may not have realized it. -- BenLast)

It is relevant to this page, to point out that though the RealWorld is messy, as is modelling it both for personal and work related domains, you have to live with the knowledge you have. You do have to draw the line but just because you don't have 100% understanding doesn't mean you can't build robust solutions or live effectively.

We satisfice, rather than find the global optimum, when packing our trunks, cleaning our houses, or routing our fedex vans.

Except FedEx satisfices a lot more mathematically with million dollar software, rfid, wireless door signing, realtime web tracking and armies of industrial engineers

Sorry, I was trying to cutely refer to the packing problem.

(Some people plan carefully when packing. They assemble what needs to be packed, assess the available space, try out different ways to fill the containers. That's the computational approach. Some (i.e., me) work differently; at any stage, we take what seems to be the best way forward. We may choose to back up, but only when it looks impossible. There's no overall plan - you just take the next step. Much of the Real World/Life is based around this one-size-fits-all meta-algorithm, hence many misalignments between the relatively ordered models that live in software and the Real World. :) -- BenLast)

Not planning is fine for small one off jobs, but speaking from experience running a shipping company, planning your boxes is much better and will save you thousands of dollars per year than if you just wing it each time. You can save thousands by planning what the best and cheapest packing materials are (for example making your own foam with chemicals, or shredding your own newspaper with machines). Just winging it each time simply doesn't work on a large scale. Winging it works for small scale (hobby ebay shippers for example.. one package every few months).

I have an algorithm for that:

  1. If contents don't fit, ask wife for help
  2. Add new contents forgotten before
  3. If contents still don't fit, goto 1.

SecondLife (http://www.secondlife.com/) literally is a big messy virtual graph although the mess is constrained within a server farm somewhere (apparently 1500 of them). Like Myst, but where users themselves build out the world.