Software Development Has Diseconomies of Scale

Some domains where software is used to yield a tremendous economic impact are so complex that even with all complexity-management approaches at our disposal, the cost of creating them still grows super-linearly with their size.

If there are n abstract features to the system, all dependent on almost all others, you have an order of n^2 interactions. Whether you make every function its own simple communicating process, or bundle a few of them together (shifting complexity into a process) the abstract complexity of the system is still n^2.

complexity is a function of interactions. multiple processes won't do much for you if every one communicates with everybody else.

If there are n abstract features to the system, all dependent on almost all others [...].

the discussion has been about using process separation as an aid in preventing accidental complexity arising from improper coupling introduced as a shortcut so this looks a little disingenuous. my response is that if you separate every function into its own simple process, a misbehaving function need not take down the whole group.

on the improper-coupling-reduction front, process separation is apparently paramount to success, see eg. sendmail vs postfix.

From a business perspective, price discrimination probably has more to do with accounting, support, and long-term sustainability.

A transaction that includes 1000 seats requires 1 account to manage them and will likely have in-house support staff to help solve with technical issues.

A 1000 transactions for 1 seat requires 1000 accounts to manage and 1000 potential points of contact that need to be supported when things go wrong.

In addition, companies that have the resources to buy a lot of seats up front are more likely to be more 'stable'. Those are the customers who will standardize their internal processes to use your software, thereby guaranteeing consistent payment over the long term, and higher likelihood of return sales in the future.

That's probably why a lot of SaaS sites offer free accounts for individual/small-team usage. Early adopters tend to be more technically inclined, will evangelize the product if they like it, will be more sympathetic when minor bugs are encountered, and the 'free' aspect means there's no guarantee of support. They're essentially buying a community of QA testers with free seats.

The 1000 seat customers cover the bills (ie CAPEX+Fixed-Costs). The lesser customers cover the rest (ie OPEX+Variable Costs). The latter keeps things in motion, the former signals it's safe to scale up.

To remain profitable it's important to minimize CAPES+Fixed-Costs as much as physically possible because when feast turns to famine they're the hardest to reduce.

In accounting terms, favoring financial liquidity means favoring flexibility to adjust to changes in the market. This is a key deciding factor behind companies shifting to 'the cloud'. Even if the upfront costs are higher than maintaining bare metal servers, it takes little/no effort to ditch redundant infrastructure when it comes time to reduce costs.

Publicly accessible microservices are becoming more and more common over time and some of them are being used to create integrations.

Have you heard of Zapier? https://zapier.com/how-it-works/

Slack bots also interact with other services: https://slack.com/apps/category/At0EFT67V3-new-noteworthy

There's also the Huggin project: https://github.com/cantino/huginn

Instead of breaking applications apart into distinct services they devs of corporate apps prefer to use OOP to create complex inter-dependent monolithic architectures. APIs for such apps are usually exposed by using a library, so a lot of emphasis is placed on access privileges at the language level (ie private/internal/public) instead of at the interface level (ie pipes/REST).

The problem isn't that the capability doesn't exist, it's that corporations are either unaware or unwilling to experiment with alternative approaches.

For example, one employee could spend half their time collecting data in Excel files from multiple members of a team, organizing it in a presentation-ready format, and emailing it up the chain.

Alternatively, the team members could each have a Google Spreadsheet where they input the data and a timed trigger fires off a bot that processes the data, saves it to a new file, and emails the link up the chain.

Both accomplish the same result. The second is a lot less prone to error/bias, and is also a lot more cost effective. But, to get an organization to adopt the latter approach requires convincing the organization to give up Excel as their canonical tool for organizing data.

I have fought that battle and it's a lost cause. Even when adequate proof of cost/time savings are presented in a business-friendly format, inertia trumps reason.

A company could theoretically hire a developer to deploy a digital assistant to streamline/automate the mundane and repetitive business processes. Except, devs are expensive, in short supply, and it's a really hard sell business leaders on the idea of adopting processes/tools that they don't fully understand.