That's because spreadsheets are an excellent tool for prototyping, and developers have shitty tools for building robust products from a prototype.
If developers had a quick way to create properly engineered applications from a working workflow involving a spreadsheet, it would be easy to define most company processes on Excel or Google Docs and turn them into solid software.
But building an application that is functionally equal to the spreadsheet, just with robust engineering practices, typically involves several-months-long projects with many developers and managers, which is expensive.
I once reverse engineered a spreadsheet that had cost the best part of a million pounds to develop - I made the relevant manager very unhappy by pointing out that significant chunks of the beast did absolutely nothing.
I did come to really like the "Trace Dependents" and "Trace Precedents" features in Excel! :-)
Yeah... the worst part of spreadsheet is that it's hard to document their structure and purpose. You may try to explain it with cell comments and blocks of color, but there's no easy way to signal the entry point or see an overview of how the different parts work together.
At least they are functional reactive, so it's easy to trace the evaluation of expressions.
Quickbase is the usual suspect for workflow via a spreadsheet, with functionality that's broader than say Airtable.
Google's "app maker" looks like their attempt to do something similar. https://developers.google.com/appmaker/ Though they seem to have left out the 'start from a spreadsheet' part.
>But building an application that is functionally equal to the spreadsheet
can you explain this to me? i've never used spreadsheets extensively so i'm clearly ignorant but my impression was that the only thing you could really (i know you can bend the rules etc.) is data transformation. when you say application is what you mean? i.e an ETL app or do you mean more than that?
Excel can pretty much do anything you'd want in an application, though not in a particularly maintainable way. GUIs? Yes. Data updates triggered by GUI actions or cell entry changes? Yes. Interacting with external resources? Yes, that too. It can do a lot more than data transformation (except in the sense that all computation can be modelled as data transformation between inputs and outputs, in which case, yes, that's all Excel can do but all any other app does, too.)
The more that's been done in Excel, the more pain it will be to maintain it in Excel or port it to a non-Excel platform, because Excel is seductive for write-once, but horrible for maintenance, and the people in an org who have it as their main tool are unlikely to be either cognizant of the problem or devoted to spending effort mitigating it.
Excel in business / finance is a great mish-mash of ETL, modelling (from simple statistics to pretty advanced optimization), graphics and dashboarding. With too little structure and documentation to be good for you. A big plus is that every step is (at least without VBA) user transparent. From Excel to application would mean specs by non-sexually writers and continuous exceptions on specs when thereto unknown use cases of pretty much the same spreadsheet are found. (Since you don't exist unless you run your own spreadsheet, users often branche from the sheets of others.)
If developers had a quick way to create properly engineered applications from a working workflow involving a spreadsheet, it would be easy to define most company processes on Excel or Google Docs and turn them into solid software.
But building an application that is functionally equal to the spreadsheet, just with robust engineering practices, typically involves several-months-long projects with many developers and managers, which is expensive.