''Excerpt from a rant recently posted to the FitDev mailing list ...''

Computer programmers are familiar with and skilled at symbolic
abstraction and the information hiding that goes with it. That is our
bread and butter. But,

Business analysts (and graphic designers) are skilled at what I'll call
"positional abstraction" which builds on alignment, not naming, as its
fundamental abstraction mechanism. A well organized table can present a
huge amount of information, both in the numbers, and their
relationships. Edward Tufte understands this and rails against
information designs that hide the facts.

When we ask business analysts to participate in factoring our
abstractions, we have to allow them to use all of their skills as we
use all of ours. Most business analyst's tool of choice is the
spreadsheet. Spreadsheets get large through the same piece-meal growth
that we advocate for software. Excel has dozens of features that
directly support "refactoring" of positionally abstracted information.
Consider the behavior preserving transformation that happens on
insert-column, where all formulas must be examined and some rewritten
to account for the change in the address space. An even more complex
automatic-refactoring happens when a block of cells is cut and pasted
into a new location and formulas are rewritten taking into
consideration contained, in-bound, out-bound and external references.
These are sophisticated tools that support a sophisticated thought
process that we need not extinguish. -- WardCunningham

Good points. Also note the strong relationship with CollectionOrientedProgramming; your observations seem to me to mesh well with the explanations APL fans have given for why they like to use APL for business apps and financial analysis, and why it still has at least a small niche on Wall Street to this day.

There's a difference between ideal information hiding, which is about implementation domain details, versus information display of problem domain data, but unfortunately that line is often not respected. -- DougMerritt

''That is the topic of SeparateMeaningFromPresentation. A description of spreadsheet-based programming can be found at http://www.geocities.com/tablizer/science.htm#spread''

Yes, and it's worth noting that this is a side of the world that supports the weaker versions of Top's claims for TableOrientedProgramming, although there remain problems with tables/databases globally exposing not just problem-domain data, but also implementation-domain data, which should remain hidden. FirstClass no-holds-barred views would help with that.

''Related: DatabaseNotMoreGlobalThanClasses''

I believe Ward's quote is using spreadsheets as an example, though, not as a statement that they are some ultimate way to go  (although they are pragmatically very handy, and a lot of business people do "programming" exclusively via spreadsheets, for better or for worse). -- DougMerritt