And even the one-off reports represent the ability to do coding in tiny increments, precisely tuned to the demand. You can find some report from months ago and just open it up and add to it.

And as you're adding features, you instantly see the results; even as you type if you use the formula builder.

If you're working on any kind of software tooling, watching how people work with Excel is incredibly insightful.

Anybody being able to quickly make a significant change has its ups and downs, though... On more than one occasion I've caught word of some fancy spreadsheet a different team in a company has been using to draw insights for months, only to have nontrivial critiques of the source data or interpretation of the data that caused big changes in the results - stuff we would have ideally caught in a dev team's code review or QA workflow, but those processes are entirely bypassed when someone on the marketing team makes a spreadhsheet on their computer and dumps audience data from an advertising platform to seed it.

Spreadsheets are nontechnical users' version of "move fast and break things". Often times that can be useful, even essential, but there are many more cases where the primary utility of working that way is also the major flaw. Its faster than traditional report development because it skips any kind of review or QA.

> I would theoretically be possible to write some software/reporting solution for every use of Excel but it wouldn't be an efficient use of resources.

One company I know which did this was called "Actuate"; that was years ago, a quick googling shows they were bought, now called "OpenText" (?) - also had something to do with MongoDB and something called BIRT (Business Intelligence and Reporting Tools)...

Last I had any involvement with them for a company I worked for, it was with their reporting suite of tools; the company I worked for became a VAR for them, so anytime the tool had a bug, we could quickly get them in an IRC chat (told you it was a while back) and get a patch within a few hours to a day or so, depending on the issue.

The reporting system was fairly unique for the time; a basic WYSIWYG drag and drop editor, ala VB - and for more complex designs, a VB-like object-oriented "reporting design" language. It was essentially what VB6 should have been on the OOP side of things, but geared entirely toward reporting.

Reports could pull data from any number of different sources, from flat ascii files, to excel documents, to database engines, ODBC, etc.

One of the last things I heard from them, at a seminar they put on that my company sent me to in Santa Monica, was this idea of reforming people using Excel spreadsheets. They called the whole sharing and copying of such spreadsheets, such that there was no one single authoritative source - a "spreadmart". So they wanted to do something about it.

They came up with some kind of Java-based solution with a custom front-end that looked exactly like Excel of the time, worked just like it - pivot tables, whole nine yards. But it interfaced to a backend using these "business logic" modules. The idea was all instances of the "spreadsheet" could see the same data via those modules, and those modules would be created by an IT staff (or DBA or something), and anything interacting with them in a company would have to go thru them - reports, gui, excel spreadsheets, etc. The idea was to present one cohesive view of the data for all users.

I don't know where it ended up - if they launched the product or not (we were being given a sneak peek at it at the seminar - it was a pretty nice demo, overall for the time).

A couple of weeks after coming back from the seminar, the company let me go (I'd worked for them for about 8 years - missed the whole "dot-com" thing because I believed in this company so much - lived and learned).