> executives want to believe in magic solutions that give them all the feelings of control with none of the actual work

Corollary: R&D wants to believe they can build magical solutions that solve all the problems--solutions that will scale better and cost less to keep up than off-the-shelf ones made by people with extensive domain expertise--in a week or two, promise.

As with most things, the problem is complicated, deeply human, and answers lie somewhere in the middle.

I agree with this wholly. I very much doubt that many people are building tools in bad faith to consume money. It’s just that in the end, “solve everything” means implementing 10:1 weird hacks for edge cases vs actual features that companies all have in common.

That works both ways. 70% of features are common with other businesses, but the feature set is pretty diverse. My experience is that internal folk with a good understanding of the business hit 90-95% of the requirements without implementing the 200% of non-relevant broader industry requirements. YMMV.

The off the shelf solutions are designed to fit everyone, while bespoke solutions are designed just for you. A lot of the complexity in off the shelf software is that generality that might never be needed.

So true but very rarely expressed.

And often the features you need are much easier to implement than you might have expected and, due to the generalisation complexity, hacking on the off-the-shelf product often much more difficult.

Maybe we'd all do better de-digitizing our processes. Return to paper.

--

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.

One of the first things I got told about databases is that you may build the most beautiful database schema for the domain, but it will never be able to be complete.

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.

I really like the idea of intentional loopholes. It is a great way ton conceptualize what I have been doing for a long time. In my opinion there is a certain feeling of satisfcation when feeling like the domain is modeled completely. Uncertainty or loopholes leave an itch to scratch. That's why people insist on modelling addresses. Adresses which are a fundamentally easy thing, should be easy to model. Like what, a house is on a street, has a number a city a state and a postcode. All of them are obviously required. And then you get into actual addresses. People who live in a village without a street. Some countries have no states. Some names can be extremely long. For example my condo adresss is 62 characters alone. I think the only thing you can rely on for addresses is postcode, city and the rest is free form. But that feels so unsatisfactory.

Addresses are hard. Off the top of my head: I live in Germany. Germany has states, but they are not part of postal addresses. A lot of US sites keep insisting on entering a state wven though that is wrong. There are tiny villages without street names. The name of the village substitutes for the street name. Maybe there are single house settlements with house numbers - I am not sure.

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.

Superior strategies like this are like hidden lore. Why is that? I'm certain there are dozens or hundreds of these hard won lessons.

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.

Sorry, this is example of my muddled thinking. Here's another shot:

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.

"INSERT only, no UPDATEs" - sounds like event sourcing?

Or an append only log. Either way, not things unheard of in software engineering.

Obvious in hind sight.

Fowler's Event Sourcing [2005] https://martinfowler.com/eaaDev/EventSourcing.html

Published after I stumbled onto my solution.

Your points are irrelevant because it's simply impossible to use paper anymore for any but the smallest local businesses. Paper is too slow. Customers and employees would quickly leave.

Complexity catastrophes must be suffered because paper mediated processes are impractical?

Complexity catastrophes are rare and seldom actually catastrophic. It's easier to deal with occasional catastrophes than with the delays and inconveniences imposed by paper processes.

I cited definition of complexity catastrophe for purposes of my thesis.

What's your definition?

you also didn’t list any pros or cons of either. from my perspective, which is weekly travel for a very large company, moving back to paper is a nightmare. what do i do with my daily receipts? how do i submit this and hope to get reimbursed this year? having to manage this all on paper seems excruciatingly inefficiency

TLDR: Maybe I'm just railing against bureaucracy. I share my techno perfect dream at the end.

"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.

It’s vendor lock-in pure and simple. In my org, I make sure there is data portability. Even if we have to write the plumbing between services, we understand and own the data and an interface to access it is available.

This argument applies to open and close sourced software alike (ever try to migrate from MantisBT to Jira?)

Some years ago, shortly before my manager asked me to join the company he was working for, they embarked on a mission to find an implementation partner to get their Salesforce system off th ground into a new level. So the business owners and him discussing how they'll pick the right consultancy. My manager says: we'll take those who will tell us that we talk nonsense instead of nodding head after every single word we say. I then joined the company and ended up in the meeting,where initial plans were discussed. My manager says: we want x,y,z,etc. The consultant says: OK, let's be realistic first: let's learn how to walk and then we may discuss whether you should be launching rockets to space. All these SAP, NetSuite and other corporate software get bad name because of poor implementations and not because the software itself is bad.

I dunno, every time I interact with anything SAP or Oracle I am reminded of the fact that the software itself is bad.

20+ years ago, same for Seibel