Positional Abstraction

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