For the applications that I designed so far, that meant that I always made room for intentional loopholes like free-form comments or ways to override hardcoded processes. It is not 100% perfect and foolproof, but it made using these applications a lot less painful in practice.
A wholesale return to paper is like trying to put the genie back into the bottle. It is really about how rigid a process can become without becoming a barrier or burden.
And then there is Mannheim, a city with no street names. This was originally a planned city where the city center has rectangular blocks numbered in a letter-number scheme. So there is e.g. a block L5. This refers to one side of the 4 adjacent streets. The other side of these streets is addreseed with L3, L5, etc... what his means is that you have addresss like O7 6 - a single letter and two numbers in a row. I bet that a lot if input validators for addresses trip over something like that.
I had to rediscover the "INSERT only, no UPDATEs" trick on my own. Changed from separate truth and historical tables to a single table which is groomed over time. Major simplification. A few extra benefits: like scaling, testing and auditing.
And my peers absolutely lost their minds. A senior VP rolled back my architecture the moment he could. (We were acquihired, so this meant major upheaval of systems which had be in use for over 3 years.) My solution was just too weird looking, too unorthodox.
So while there's lots of things we can do to mitigate databasization and buy ourselves some head room, we don't.
Square peg, round hole?
My radical (unoriginal) thought is the problem is the people, not the tools.
Real world is messy, evolving. Schemas and programming languages encourage rigidity, but can be more flexible. So while we can design and use adaptable systems, we don't.
An additional theory I have is that the people drawn to our type of work have rigid views and strive to make the world more ordered, through their systems, rather than accommodate the chaos. Aspirationally. Not in truth. Because I regard most of our efforts to be rather chaotic.
Fowler's Event Sourcing [2005] https://martinfowler.com/eaaDev/EventSourcing.html
Published after I stumbled onto my solution.
What's your definition?
"you also didn’t list any pros or cons of either."
Thank you. You're right; I should do that. Long overdue.
Alas, I don't know how to do that.
The best I can do, at this time, is list examples of digital, paper, and hybrids which succeeded and failed. Try to divine RCAs. Then see if there are patterns.
I do have some initial guesses about best use of paper.
1- Organizational boundaries.
Like mediating communication between entities. (It slays me that scripts and referrals are done by fax, which might as well be black boxes, because the communication can fail silently.)
2- Legal stuff.
IDs, cash, voting (ballots), titles (property).
3- Short lived communication (semaphores), coordination, collaboration.
Lo-fi tools for brain storming, designing. Visible tools, like resource planning white boards.
"what do i do with my daily receipts?"
You say that like it's obvious. Of course we should design (engineer) away data entry.
Yet SAP Concur is still a thing, with wide adoption.
JIRA, ServiceNow, PagerDuty are crimes against humanity. Bending the work towards computers, instead of empowering humans.
I've gotten so much shit (from the larger orgs) the times I've moved my teams from heavy weight, labor intensive, error prone tools to lightweight lo-fi tools.
One stupid example: For weekly triage, we'd just print the bug list, and everyone (everyone) could vote, then cc copies of the list as needed. Voila, instant priorities.
The majority of push back is the style documented by Neil Postman's Technopoly. Some people can't wrap their heads around not using computers for everything. It's like the debate between ontologies and folksonomies. People who can't accept ambiguity vs people who can accept "good enough". (Just one over simplification of the psychology. I did pre-caveat by admitting my thinking is muddy.)
###
I've long dreamed of a technical solution.
Some kind of hybrid of HyperCard & wikis backed by version control.
New instances of a CRUD form (both UI and backing data) would just be cloned, a la prototype based classes. Every instance can be customized, a la live editing. Imprint both schemas and forms with a version token, so the system can support multiple variations, so that orgs and evolve processes incrementally (instead of outright cut-overs).
I recently made some progress on bridging the gap between persistence and UIs. I'm trying to reorient my life to resume work.
--
I've been struggling to articulate a thesis, for way too long. But here it goes.
Complexity catastrophe occurs when cost of change outweighs benefit. Or simply can't be done in time to make a difference.
Whereas databasization makes processes inflexible, humans are relatively more flexible. Like being able to make notes on forms, or quickly modify a form and make more copies to use.
--
I'm heavily influenced by process and methodology ideas. Deming, Drucker, TPS, etc.
As well as their critics. Postman, Norman, etc, and most recently David Graeber.
Graeber's notions about bullshit jobs and bureaucracy have articulated many of my misgivings as well as made me feel stupid for my hubris.
--
Both database and paper mediated systems have pros and cons. In defense of younger self, we were not fully aware of the costs and limitations of databases, so couldn't properly weigh the options. Worse, my entire career, I tried to mitigate, engineer workarounds to databases, not willing to accept the problems are intrinsic and not just artifacts of suboptimal implementations. Basically, clap louder and Tinkerbell will fly. Embarrassing.
--
My notion of "complexity catastrophe" comes from Design Rules: The Power of Modularity.
I may have just coined "databasization". I've long accepted the difference between digitization and automation. Moving processes from paper to computer mediated vs removing judgement (aka process reengineering). But have never found a succinct way to explain it. Maybe "databasizition" makes the distinction more clear.
--
Thanks for listening.