For something that needs to be editable and analyzed and shared among users that are highly proficient in financial tech (excel) but are not programmers, an app framework isn't going to work.
My work is often an input into the work of the finance folks where I'm at, and they have countless very complex excel docs. None of them are programmers, but all them (and anyone else moderately proficient in Excel) can look under the hood, see what's going on, and make their own additions/changes as needed.
And there may need to be new versions of all of these that have slight or major changes made on a monthly/quarterly/annual basis. No single build w/ a web-app framework is going to do this very well without a very large investment in developer costs, and that simply isn't necessary when there is already a perfectly good tool for their needs. Developer costs aside, it would also mean that these folks had a significant delay in their work: They could no longer clone last quarter's sheet and spend a morning making the necessary changes. They'd need to spend a few days going back & forth with a developer over the scope & specs of the changes, a little longer for the developer to write the code, do a bit of UAT, and assuming everything works as expected then get to the actual work and hope nothing new came up before next quarter that would stop their work for more dev time.
The types of systems that eliminate a little bit of this are part of industry-specific monolithic ERP systems, and even those may only cover the 60% of requirements that don't change often or are supported by contractually guaranteed TOS upgrades each quarter from the vendor.
Like when your main focus is array math, and you work with a uniquely different database on each of 5 worksheets and the deliverable output has to be in the form of another Excel spreadsheet anyway?
And it has nothing to do with the web or networking at all?
JK, I know you mean much lesser scale of complexity.
To explain why people build highly complex excel applications to get work done? That's more about industry standards, learning curve, portability, need for rapid modification of requirements by users...
I've certainly done a lot of work over the years eliminating the need to use Excel docs that require manual maintenance, but mainly for things where a) the underlying data structures don't change much and b) if they do change, the end user doesn't need to be the one to do it on the fly. (mostly this entails tapping into the underlying data sources-- or first building the tools to do so-- and then automating the transformations, analysis, and presentation using some combination of r/python along with a SQL database & BI platform.) I work with finance folks too though, and what they do with excel is generally not a candidate for this process.
These people were trained in excel I assume, it's cultural and then you also have this weird pivot point like C where excel has reactive semantics, data table, ad-hoc input / modeling .. it's a massive reactive data notebook on steroid that requires next to no fiddling to get working.
Now as you point, things are changing.. R/julia/numpy/notebooks, reactive web frameworks.. can all suck some use case from excel. I believe that future clearly lies in the middle. Microsoft should be wise to implement some presentation/component feature to match the web.
Microsoft should be wise to implement some presentation/component feature to match the web
Yep, they would be. Although I think they're trying push the whole Power Apps model. Which, I'll admit, is an interesting ecosystem, but something on the desktop to enhance excel power users that will never have their needs satisfied by Power Apps would be beneficial. But possibly also eat into the user base that might be enticed into Power Apps instead, and the steady stream of monthly revenue from Power Apps clouds resources usage is preferable ( to MS ) than the "buy once" model for Office.
My work is often an input into the work of the finance folks where I'm at, and they have countless very complex excel docs. None of them are programmers, but all them (and anyone else moderately proficient in Excel) can look under the hood, see what's going on, and make their own additions/changes as needed.
And there may need to be new versions of all of these that have slight or major changes made on a monthly/quarterly/annual basis. No single build w/ a web-app framework is going to do this very well without a very large investment in developer costs, and that simply isn't necessary when there is already a perfectly good tool for their needs. Developer costs aside, it would also mean that these folks had a significant delay in their work: They could no longer clone last quarter's sheet and spend a morning making the necessary changes. They'd need to spend a few days going back & forth with a developer over the scope & specs of the changes, a little longer for the developer to write the code, do a bit of UAT, and assuming everything works as expected then get to the actual work and hope nothing new came up before next quarter that would stop their work for more dev time.
The types of systems that eliminate a little bit of this are part of industry-specific monolithic ERP systems, and even those may only cover the 60% of requirements that don't change often or are supported by contractually guaranteed TOS upgrades each quarter from the vendor.